On Sun, Sep 13, 2026, at 00:20, Jonathan Cameron wrote: > On Thu, 10 Sep 2026 20:14:15 +0200 "Arnd Bergmann" <[email protected]> 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/[email protected]/ 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
