The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Danilo Krummrich <dakr@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mark Brown <broonie@kernel.org>,
	driver-core@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-spi@vger.kernel.org
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Jean-Baptiste Maneyrol" <jean-baptiste.maneyrol@tdk.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>
Subject: [PATCH v1 0/4] driver core, iio: suppress driver_override
Date: Fri,  8 May 2026 11:42:38 +0200	[thread overview]
Message-ID: <20260508095224.1275645-1-andriy.shevchenko@linux.intel.com> (raw)

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.

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.

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(-)

-- 
2.50.1


             reply	other threads:[~2026-05-08  9:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08  9:42 Andy Shevchenko [this message]
2026-05-08  9:42 ` [PATCH v1 1/4] driver core: allow certain drivers prohibit override via sysfs Andy Shevchenko
2026-05-08 15:18   ` Danilo Krummrich
2026-05-08  9:42 ` [PATCH v1 2/4] spi: Support suppress_override_attrs flag Andy Shevchenko
2026-05-08 13:53   ` Mark Brown
2026-05-08 15:28   ` Danilo Krummrich
2026-05-08  9:42 ` [PATCH v1 3/4] iio: imu: inv_mpu6050: Suppress driver_override sysfs attribute Andy Shevchenko
2026-05-08  9:42 ` [PATCH v1 4/4] iio: imu: inv_icm42600: " Andy Shevchenko
2026-05-08 12:22 ` [PATCH v1 0/4] driver core, iio: suppress driver_override Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260508095224.1275645-1-andriy.shevchenko@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=andy@kernel.org \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dakr@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=jean-baptiste.maneyrol@tdk.com \
    --cc=jic23@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=rafael@kernel.org \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox