[PATCH 0/2] driver: core: Allow drivers to opt out of driver_override

[PATCH 0/2] driver: core: Allow drivers to opt out of driver_override

[Thierry Reding]

Overriding the driver to bind to may not make sense for some drivers.
One example of this is platform drivers that use device data obtained
through device ID matching (such as OF or ACPI) and they cannot work
without that device data.

Usually the device ID matching is the only way that such drivers can
match against a device, so drivers shouldn't need to check that their
device data is valid. For such drivers, driver_override is the only
corner case that can lead to a case where no device data is found.
Instead of requiring each and every driver to handle this case, move
handling into the core and let drivers opt out of this override
mechanism if it doesn't make any sense for them.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Thierry Reding (2):
      driver: core: Allow drivers to opt out of driver_override
      pwm: tegra: Opt out of driver_override

 drivers/pwm/pwm-tegra.c       |  1 +
 include/linux/device.h        | 12 +++++++++---
 include/linux/device/driver.h | 12 ++++++++++++
 3 files changed, 22 insertions(+), 3 deletions(-)
---
base-commit: 5c4d4169604b335c38bbc79bc1fc03042981fc6f
change-id: 20260922-driver-override-opt-out-470290f5d5c9

Best regards,
--  
Thierry Reding <treding@nvidia.com>

[PATCH 1/2] driver: core: Allow drivers to opt out of driver_override

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Some drivers rely on device data obtained through device ID matching and
will not work otherwise. Some such drivers don't check for the validity
of the device data because it is never NULL when the device is matched
against the device ID table.

However, Uwe recently pointed out that drivers always need to check this
device data because any device can be forced to bind against a driver if
their driver_override sysfs attribute is set and the driver rebound. Any
such device will now not have device data from a device ID match table
and may crash.

Add a flag that allows drivers to opt out of the override mechanism when
it doesn't make sense. This allows us to deal with these situations in
the core rather than sprinkle checks throughout all of these drivers to
check for validity of the device data.

Cc: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 include/linux/device.h        | 12 +++++++++---
 include/linux/device/driver.h | 12 ++++++++++++
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 90cdd77458bb..45c23cc5efa8 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -899,14 +899,20 @@ static inline bool device_has_driver_override(struct device *dev)
  *
  * Returns > 0 if a driver override is set and matches the given driver, 0 if a
  * driver override is set but does not match, or < 0 if a driver override is not
- * set at all.
+ * set at all or the driver opts out of the override mechanism.
  */
 static inline int device_match_driver_override(struct device *dev,
 					       const struct device_driver *drv)
 {
 	guard(spinlock)(&dev->driver_override.lock);
-	if (dev->driver_override.name)
-		return !strcmp(dev->driver_override.name, drv->name);
+	if (dev->driver_override.name) {
+		if (strcmp(dev->driver_override.name, drv->name) != 0)
+			return 0;
+
+		if (driver_allow_override(drv))
+			return 1;
+	}
+
 	return -1;
 }
 
diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index 29fbc01ef06f..c985622a67a5 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -57,6 +57,8 @@ enum probe_type {
  * @owner:	The module owner.
  * @mod_name:	Used for built-in modules.
  * @suppress_bind_attrs: Disables bind/unbind via sysfs.
+ * @disallow_override: Prevents the driver from being bound to a device via
+ *		driver_override.
  * @probe_type:	Type of the probe (synchronous or asynchronous) to use.
  * @of_match_table: The open firmware table.
  * @acpi_match_table: The ACPI match table.
@@ -105,6 +107,7 @@ struct device_driver {
 	const char		*mod_name;	/* used for built-in modules */
 
 	bool suppress_bind_attrs;	/* disables bind/unbind via sysfs */
+	bool disallow_override;
 	enum probe_type probe_type;
 
 	const struct of_device_id	*of_match_table;
@@ -249,6 +252,15 @@ void driver_deferred_probe_add(struct device *dev);
 int driver_deferred_probe_check_state(struct device *dev);
 void driver_init(void);
 
+static inline bool driver_allow_override(const struct device_driver *drv)
+{
+	if (drv->disallow_override)
+		pr_err("driver '%s' cannot be bound to via override\n",
+		       drv->name);
+
+	return !drv->disallow_override;
+}
+
 /**
  * module_driver() - Helper macro for drivers that don't do anything
  * special in module init/exit. This eliminates a lot of boilerplate.

-- 
2.55.0

[PATCH 2/2] pwm: tegra: Opt out of driver_override

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

The Tegra PWM driver heavily relies on device data obtained through
device ID matching and will not work if this data is missing. Opt out of
the driver_override mechanism to prevent the driver from accidentally
being bound to a device that doesn't match a DT device ID table entry.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/pwm/pwm-tegra.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index 5cdbe120ba2d..f92680a0f13b 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -486,6 +486,7 @@ static struct platform_driver tegra_pwm_driver = {
 		.name = "tegra-pwm",
 		.of_match_table = tegra_pwm_of_match,
 		.pm = &tegra_pwm_pm_ops,
+		.disallow_override = true,
 	},
 	.probe = tegra_pwm_probe,
 	.remove = tegra_pwm_remove,

-- 
2.55.0

Re: [PATCH 1/2] driver: core: Allow drivers to opt out of driver_override

[Greg Kroah-Hartman]

On Tue, Sep 22, 2026 at 01:38:28PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> Some drivers rely on device data obtained through device ID matching and
> will not work otherwise. Some such drivers don't check for the validity
> of the device data because it is never NULL when the device is matched
> against the device ID table.
> 
> However, Uwe recently pointed out that drivers always need to check this
> device data because any device can be forced to bind against a driver if
> their driver_override sysfs attribute is set and the driver rebound. Any
> such device will now not have device data from a device ID match table
> and may crash.
> 
> Add a flag that allows drivers to opt out of the override mechanism when
> it doesn't make sense. This allows us to deal with these situations in
> the core rather than sprinkle checks throughout all of these drivers to
> check for validity of the device data.
> 
> Cc: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  include/linux/device.h        | 12 +++++++++---
>  include/linux/device/driver.h | 12 ++++++++++++
>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 90cdd77458bb..45c23cc5efa8 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -899,14 +899,20 @@ static inline bool device_has_driver_override(struct device *dev)
>   *
>   * Returns > 0 if a driver override is set and matches the given driver, 0 if a
>   * driver override is set but does not match, or < 0 if a driver override is not
> - * set at all.
> + * set at all or the driver opts out of the override mechanism.

What's wrong with just not allowing bind/unbind at all?  Why would you
want that, but NOT the driver_override file?

thanks,

greg k-h

Re: [PATCH 1/2] driver: core: Allow drivers to opt out of driver_override

[Danilo Krummrich]

On Tue Sep 22, 2026 at 2:13 PM CEST, Greg Kroah-Hartman wrote:
> On Tue, Sep 22, 2026 at 01:38:28PM +0200, Thierry Reding wrote:
>> From: Thierry Reding <treding@nvidia.com>
> What's wrong with just not allowing bind/unbind at all?  Why would you
> want that, but NOT the driver_override file?

pwm-tegra is a platform driver, but for drivers on hot-pluggable buses we still
want bind/unbind for testing, even if we opt-out from driver_override.

Besides that, I think that even for buses that do not have hotplug, there are
cases where it can be useful to be able test whether a driver survives
bind/unbind (i.e. follows the device driver lifecycle rules). E.g. because the
same IP will later receive an implementation on a hot-pluggable bus that shares
driver code, or just to validate driver design in general.

Re: [PATCH 1/2] driver: core: Allow drivers to opt out of driver_override

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 3954 bytes --]

Hello Greg,

On Tue, Sep 22, 2026 at 02:13:58PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 22, 2026 at 01:38:28PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > Some drivers rely on device data obtained through device ID matching and
> > will not work otherwise. Some such drivers don't check for the validity
> > of the device data because it is never NULL when the device is matched
> > against the device ID table.
> > 
> > However, Uwe recently pointed out that drivers always need to check this
> > device data because any device can be forced to bind against a driver if
> > their driver_override sysfs attribute is set and the driver rebound. Any
> > such device will now not have device data from a device ID match table
> > and may crash.
> > 
> > Add a flag that allows drivers to opt out of the override mechanism when
> > it doesn't make sense. This allows us to deal with these situations in
> > the core rather than sprinkle checks throughout all of these drivers to
> > check for validity of the device data.
> > 
> > Cc: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> >  include/linux/device.h        | 12 +++++++++---
> >  include/linux/device/driver.h | 12 ++++++++++++
> >  2 files changed, 21 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 90cdd77458bb..45c23cc5efa8 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -899,14 +899,20 @@ static inline bool device_has_driver_override(struct device *dev)
> >   *
> >   * Returns > 0 if a driver override is set and matches the given driver, 0 if a
> >   * driver override is set but does not match, or < 0 if a driver override is not
> > - * set at all.
> > + * set at all or the driver opts out of the override mechanism.
> 
> What's wrong with just not allowing bind/unbind at all?  Why would you
> want that, but NOT the driver_override file?

bind/unbind and driver_override are two very different operations. The
first is something that should generally work and I consider it a safe
operation. The practical use includes reloading drivers that hang and
also switching operational devices on a devboard that cannot be used at
the same time due to pinctrl conflicts or different clk needs.

driver_override is a foot gun that allows to bind unsuspecting drivers
on foreign devices and thus make e.g. of_device_get_match_data() return
NULL for a driver that assumes that cannot happen because all
of_device_id entries have a non-NULL .driver_data yielding null pointer
exceptions.

See also the feedback you got on
https://lore.kernel.org/all/20260914-bind_taint-v4-0-eadf8a090903@linuxfoundation.org/
where (apart from me) Danilo Krummrich argued that unbind/bind should be
considered safe compared to driver_override and also our conversation in
#kernelnewbies where Richard Weinberger concurred to that.

Having said that I think there is only a handful of drivers that are
actually supposed to work when used in a driver override (vfio stuff,
spidev and i2c-dev come to mind), so I'd prefer that drivers opt-in
instead of opt-out. Otherwise we yet another flag that drivers should
set in general but don't because driver authors are not aware[1]. The
few drivers that rely on driver overriding should be identified quickly,
and if we miss one that doesn't result in a way to make the kernel oops.

Also note that setting .suppress_bind_attrs on a driver doesn't prevent
driver_overriding. After you point a device to a different driver you
might not make it bind via sysfs immediately, but that might happen at a
later point. (I'm not sure, but maybe it's enough to plug in a USB
thumbdrive?)

Best regards
Uwe

[1] Do you know about struct device_driver::probe_type =
    PROBE_PREFER_ASYNCHRONOUS?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] driver: core: Allow drivers to opt out of driver_override

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3956 bytes --]

On Tue, Sep 22, 2026 at 03:17:26PM +0200, Uwe Kleine-König wrote:
> Hello Greg,
> 
> On Tue, Sep 22, 2026 at 02:13:58PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Sep 22, 2026 at 01:38:28PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > > 
> > > Some drivers rely on device data obtained through device ID matching and
> > > will not work otherwise. Some such drivers don't check for the validity
> > > of the device data because it is never NULL when the device is matched
> > > against the device ID table.
> > > 
> > > However, Uwe recently pointed out that drivers always need to check this
> > > device data because any device can be forced to bind against a driver if
> > > their driver_override sysfs attribute is set and the driver rebound. Any
> > > such device will now not have device data from a device ID match table
> > > and may crash.
> > > 
> > > Add a flag that allows drivers to opt out of the override mechanism when
> > > it doesn't make sense. This allows us to deal with these situations in
> > > the core rather than sprinkle checks throughout all of these drivers to
> > > check for validity of the device data.
> > > 
> > > Cc: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > ---
> > >  include/linux/device.h        | 12 +++++++++---
> > >  include/linux/device/driver.h | 12 ++++++++++++
> > >  2 files changed, 21 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index 90cdd77458bb..45c23cc5efa8 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -899,14 +899,20 @@ static inline bool device_has_driver_override(struct device *dev)
> > >   *
> > >   * Returns > 0 if a driver override is set and matches the given driver, 0 if a
> > >   * driver override is set but does not match, or < 0 if a driver override is not
> > > - * set at all.
> > > + * set at all or the driver opts out of the override mechanism.
> > 
> > What's wrong with just not allowing bind/unbind at all?  Why would you
> > want that, but NOT the driver_override file?
> 
> bind/unbind and driver_override are two very different operations. The
> first is something that should generally work and I consider it a safe
> operation. The practical use includes reloading drivers that hang and
> also switching operational devices on a devboard that cannot be used at
> the same time due to pinctrl conflicts or different clk needs.
> 
> driver_override is a foot gun that allows to bind unsuspecting drivers
> on foreign devices and thus make e.g. of_device_get_match_data() return
> NULL for a driver that assumes that cannot happen because all
> of_device_id entries have a non-NULL .driver_data yielding null pointer
> exceptions.
> 
> See also the feedback you got on
> https://lore.kernel.org/all/20260914-bind_taint-v4-0-eadf8a090903@linuxfoundation.org/
> where (apart from me) Danilo Krummrich argued that unbind/bind should be
> considered safe compared to driver_override and also our conversation in
> #kernelnewbies where Richard Weinberger concurred to that.
> 
> Having said that I think there is only a handful of drivers that are
> actually supposed to work when used in a driver override (vfio stuff,
> spidev and i2c-dev come to mind), so I'd prefer that drivers opt-in
> instead of opt-out. Otherwise we yet another flag that drivers should
> set in general but don't because driver authors are not aware[1]. The
> few drivers that rely on driver overriding should be identified quickly,
> and if we miss one that doesn't result in a way to make the kernel oops.

We could easily invert the logic in this patch to make this opt-in, but
it might be difficult to know exactly which ones want to opt-in, given
it's been enabled by default for a really long time.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]