Re: [PATCH v1 0/4] driver core, iio: suppress driver_override

[Jonathan Cameron <jic23@kernel.org>]

On Fri,  8 May 2026 11:42:38 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> Recently Sashiko started reporting the missed NULL check of
> spi_get_device_match_data() or device_get_match_data() in SPI drivers
> in IIO subsystem. It appears that the way to crash can be made by use
> of driver_override sysfs attribute. However, many drivers, that may be
> instantiate via ACPI, OF, or, in some cases, user space won't work
> without necessary driver data. These are, e.g., most of the drivers
> in IIO subsystem. Trying to override the driver for the device that
> has no matching entry makes no sense in such cases and might lead to
> a crash, when the driver is not prepared for that.  Instead of adding
> a NULL check for driver data pointer in each of that drivers, effectively
> meaning a dead code for normal functionality, introduce a special
> attribute in the struct device_driver to allow drivers just to hide
> the attribute for good.
> 
> The last two patches are the examples of use and code simplification
> at the same time.
> 
> I consider getting an Ack from Mark for SPI, and from Jonathan for IIO
> and route this via driver core, while providing an immutable branch/tag
> for the above mentioned stakeholders.

Works for me.

> 
> Note, this doesn't change the state of affairs for some busses that
> do not have driver_override flag set while using custom approach.
> On a brief look it's the s390 crypto case which may not ever need
> the above and hence left untouched.

Excellent!  To me this makes a lot of sense as removing an attribute
that never works for particular drivers is neat and tidy.  I suppose
there is a very small risk that some really strange scripts rely on
that attribute existing but not on it doing anything useful.
If that turns out to be the case we can just make it fail in the callbacks
but definitely not as neat.

One possible concern though based on a typical driver evolution:

1) Driver written - supports only one part, so to match_data involved
   and driver_override is fine.
2) Driver gains support for second device.  match_data added and now
   driver_override is not ok so we set the new flag.  Interface
   disappears and perhaps someone was using it.  Obviously that case
   is broken anyway.

I guess I can make an IIO wide rule that we always set the flag. That
leaves us with a gap though as we have a lot of drivers currently at
step 1 of above that might progress to step 2 over time. I guess we deal
with any reported regressions on a case by case basis.

Ah well - still a step in the right direction even with risks of
regressions.

For all patches
Reviewed-by: Jonathan Cameron <jic23@kernel.org>

Thanks for proposing this Andy

Jonathan

> 
> Andy Shevchenko (4):
>   driver core: allow certain drivers prohibit override via sysfs
>   spi: Support suppress_override_attrs flag
>   iio: imu: inv_mpu6050: Suppress driver_override sysfs attribute
>   iio: imu: inv_icm42600: Suppress driver_override sysfs attribute
> 
>  Documentation/driver-api/driver-model/binding.rst |  4 ++++
>  drivers/base/bus.c                                |  4 ++--
>  drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c   |  8 ++------
>  drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c         |  3 +--
>  drivers/spi/spi.c                                 | 11 +++++++++++
>  include/linux/device/driver.h                     |  2 ++
>  6 files changed, 22 insertions(+), 10 deletions(-)
>