Re: [PATCH 08/14] mfd: remove unused aat2870 driver

["Arnd Bergmann" <arnd@arndb.de>]

On Sun, Sep 13, 2026, at 00:20, Jonathan Cameron wrote:
> On Thu, 10 Sep 2026 20:14:15 +0200 "Arnd Bergmann" <arnd@arndb.de> wrote:
>> 
>> I tried to be careful about figuring out exactly which drivers are
>> unused, but I'm sure there are still a few false positive and false
>> negative ones in there. I've added the current list of driver files below,
>> let me know if you see something that shouldn't be there.
> Hi Arnd
>
> For I2C and SPI at least, there doesn't need to be explicit
> device tree support as long as they have defaults when platform
> data isn't there. Those two buses will happily bind based on
> a dt-compatible and their i2c_device_id or spi_device_id tables
> for example.
>
> So unless they fail to probe (some might?) we don't have
> a clear signal on whether they are in use via DT or not.
>
> For vast majority of IIO drivers we don't have an upstream
> DTS as there is no clear motivation for anyone to upstream
> the dts for a random industrial control board or similar.

Right, that was my general rule, if I had tried to remove
all drivers that could plausibly probe with an external dtb
but have no internal users, that would have easily doubled
the 300 patches I already did.

>> drivers/iio/adc/ad7266.c
> No to dropping this.
>
>
>> drivers/iio/adc/ad7791.c
> No to dropping this one.
>
>> drivers/iio/adc/ad7793.c
> Maybe. Analog devices ack needed.
>
> Production part but this one indeed fails to probe.  Analog
> folk, do you want to fix this one up?
>
>> drivers/iio/adc/ad7887.c
> No to dropping this.
>
> Production part - should work fine with defaults in driver.
> Could like the others drop the platform data handling.

This was one patch that I wasn't sure about myself (all four
drivers together) since it looks like even when they do probe
from dtb, the feature set would be limited without a DT
binding, and they have been in the tree for a rather long time
without users.

I've dropped the patch now. I looked at dropping the platform_data
handling, but I think that only makes sense if we get a
proper DT binding first.

>> drivers/iio/adc/lp8788_adc.c
> Probably
>
> Sub driver of an MFD.  I'm fine with that going if we know
> the mfd is no longer in use.

Ok, I posted that one as
https://lore.kernel.org/all/20260909132153.1596191-8-arnd@kernel.org/

and so far, everyone agreed on removing it.

>> drivers/iio/adc/lpc18xx_adc.c
>> drivers/iio/dac/lpc18xx_dac.c
> Probably
>
> Likewise these two.

Right, this one of course should follow the removal of
CONFIG_ARCH_LPC18XX in arch/arm/

>> drivers/iio/frequency/ad9523.c
> Maybe. Analog Devices ack needed.
>
> Fails to probe without platform data and marked not recomended
> for new designs. If we get an Ack from Analog devices folk
> I'm fine with this one going away.

This matches what I wrote in 
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?id=20c1515b0caec2769c0916d087326f640bfb8aab

I'll keep the patch in the series and we'll see what the
maintainers think when I post it.

Thanks a lot for taking a look!

I wonder if some of the older Analog drivers were only ever used
on Blackfin. My series still removes a few more drivers outside
of iio list that had platform_data in arch/blackfin/ until we
removed that in 2018. These all fail to probe without
platform_data, which means they also wouldn't work with the
downstream adsp-sc5xx/sc8xx port or any other upstream Arm
platform:

a4bdf847e0e1 backlight: remove unused adp8860/8870 drivers
c71829e110e9 Input: touchscreen: remove unused ad7877 driver
b4d4ca64500b Input: misc: remove unused ad714x driver
978426a3fe1a usb: remove unused sl811 driver
0860c9f297c3 mfd: remove unused adp5520 driver

       Arnd