Re: [PATCH] cleanup: uintptr_t to unsigned long

On Thu, Mar 12, 2026 at 10:34:35PM -0300, Tomas Borquez wrote:

Linus has been explicit that uintptr_t should not be used in the kernel.

And it's all usually about new code. The shuffling _existing_ code is a churn.
This churn has to be agreed upfront. (That's what Jonathan's mail is, so
you need to have two links and proper message.)

The iio_chan_spec_ext_info struct uses uintptr_t for the private field
and in its read/write function pointer signatures. Jonathan Cameron noted
this should be cleaned up in one go across all users [1].

Update the struct definition in iio.h and backend.h, along with all
drivers implementing or using iio_chan_spec_ext_info callbacks.

No functional change intended.

[1] https://lore.kernel.org/linux-iio/20260111122034.174c754c@jic23-huawei/ (local)

This should be Link tag. And to the original email.

Suggested-by: Jonathan Cameron <jic23@kernel.org>

We don't accept wrongly prepared patches.
NAK.

...

 drivers/iio/adc/stm32-dfsdm-adc.c             |  4 ++--
 drivers/iio/afe/iio-rescale.c                 |  4 ++--
 drivers/iio/amplifiers/hmc425a.c              |  4 ++--
 drivers/iio/chemical/sunrise_co2.c            |  8 ++++----
 .../cros_ec_sensors/cros_ec_sensors_core.c    |  4 ++--
 drivers/iio/common/scmi_sensors/scmi_iio.c    |  2 +-
 drivers/iio/dac/ad3530r.c                     |  4 ++--

Besides that, it's much better to group them one per subfolder: adc, dac,
et cetera. Currently this even spams tons of people who do not want to
be spammed.

Take your time and become familiar with the process before sending a proper
version of this.

-- 
With Best Regards,
Andy Shevchenko