[PATCH 0/3] driver core: generalize driver_override infrastructure

Danilo Krummrich posted 3 patches 1 month, 2 weeks ago
There is a newer version of this series
arch/sh/drivers/platform_early.c |  6 ++-
drivers/base/core.c              |  2 +
drivers/base/dd.c                | 60 +++++++++++++++++++++++
drivers/base/platform.c          | 35 ++------------
drivers/bus/simple-pm-bus.c      |  4 +-
drivers/clk/imx/clk-scu.c        |  3 +-
drivers/hwmon/axi-fan-control.c  |  2 +-
drivers/slimbus/qcom-ngd-ctrl.c  |  6 +--
include/linux/device.h           | 81 ++++++++++++++++++++++++++++++++
include/linux/platform_device.h  |  5 --
sound/soc/samsung/i2s.c          |  6 +--
11 files changed, 161 insertions(+), 49 deletions(-)
[PATCH 0/3] driver core: generalize driver_override infrastructure
Posted by Danilo Krummrich 1 month, 2 weeks ago
Currently, there are 12 busses (including platform and PCI) that duplicate the
driver_override logic for their individual devices.

All of them seem to be prone to the bug described in [1].

While this could be solved for every bus individually using a separate lock,
solving this in the driver-core generically results in less (and cleaner)
changes overall.

Thus, move driver_override to struct device, provide corresponding accessors for
busses and handle locking with a separate lock internally.

In particular, add device_set_driver_override(), device_has_driver_override(),
device_match_driver_override() and a helper, DEVICE_ATTR_DRIVER_OVERRIDE(), to
declare the corresponding sysfs store() and show() callbacks.

Until all busses have migrated, keep driver_set_override() in place.

Note that we can't use the device lock for the reasons described in [2].

This patch series includes the migration of the platform bus; patches for all
other affected busses still need to be extracted as a follow-up of the WIP
treewide patch in [3].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=220789
[2] https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/log/?h=driver_override

Danilo Krummrich (3):
  driver core: generalize driver_override in struct device
  hwmon: axi-fan: don't use driver_override as IRQ name
  driver core: platform: use generic driver_override infrastructure

 arch/sh/drivers/platform_early.c |  6 ++-
 drivers/base/core.c              |  2 +
 drivers/base/dd.c                | 60 +++++++++++++++++++++++
 drivers/base/platform.c          | 35 ++------------
 drivers/bus/simple-pm-bus.c      |  4 +-
 drivers/clk/imx/clk-scu.c        |  3 +-
 drivers/hwmon/axi-fan-control.c  |  2 +-
 drivers/slimbus/qcom-ngd-ctrl.c  |  6 +--
 include/linux/device.h           | 81 ++++++++++++++++++++++++++++++++
 include/linux/platform_device.h  |  5 --
 sound/soc/samsung/i2s.c          |  6 +--
 11 files changed, 161 insertions(+), 49 deletions(-)


base-commit: 78437ab3b769f80526416570f60173c89858dd84
-- 
2.53.0
Re: [PATCH 0/3] driver core: generalize driver_override infrastructure
Posted by Gui-Dong Han 1 month, 2 weeks ago
On Mon, Mar 2, 2026 at 8:27 AM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Currently, there are 12 busses (including platform and PCI) that duplicate the
> driver_override logic for their individual devices.
>
> All of them seem to be prone to the bug described in [1].
>
> While this could be solved for every bus individually using a separate lock,
> solving this in the driver-core generically results in less (and cleaner)
> changes overall.
>
> Thus, move driver_override to struct device, provide corresponding accessors for
> busses and handle locking with a separate lock internally.
>
> In particular, add device_set_driver_override(), device_has_driver_override(),
> device_match_driver_override() and a helper, DEVICE_ATTR_DRIVER_OVERRIDE(), to
> declare the corresponding sysfs store() and show() callbacks.
>
> Until all busses have migrated, keep driver_set_override() in place.
>
> Note that we can't use the device lock for the reasons described in [2].
>
> This patch series includes the migration of the platform bus; patches for all
> other affected busses still need to be extracted as a follow-up of the WIP
> treewide patch in [3].
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=220789
> [2] https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/log/?h=driver_override
>
> Danilo Krummrich (3):
>   driver core: generalize driver_override in struct device
>   hwmon: axi-fan: don't use driver_override as IRQ name
>   driver core: platform: use generic driver_override infrastructure

Hi Danilo,

It looks like some usages of platform_device->driver_override were
missed. I found them here:
- drivers/bus/simple-pm-bus.c
- drivers/clk/imx/clk-scu.c
- drivers/slimbus/qcom-ngd-ctrl.c
- sound/soc/samsung/i2s.c

The good news is these can be easily updated to use the new APIs. This
is required to avoid breaking the build, since the field is removed
from struct platform_device. The previous build likely passed because
these weren't enabled. I will use allyesconfig for testing going
forward.

I scanned for similar cases and most fit the new APIs perfectly. One
exception is drivers/xen/xen-pciback/pci_stub.c. It does
strcmp(dev->driver_override, PCISTUB_DRIVER_NAME) instead of using
drv->name. We might want to change device_match_driver_override() to
take a const char * instead to handle this.

Besides axi-fan, I didn't find any other drivers that need to read
driver_override. This is great, as it means we hopefully won't need to
expose a read API at all.

Thanks.

>
>  arch/sh/drivers/platform_early.c |  6 ++-
>  drivers/base/core.c              |  2 +
>  drivers/base/dd.c                | 60 +++++++++++++++++++++++
>  drivers/base/platform.c          | 35 ++------------
>  drivers/bus/simple-pm-bus.c      |  4 +-
>  drivers/clk/imx/clk-scu.c        |  3 +-
>  drivers/hwmon/axi-fan-control.c  |  2 +-
>  drivers/slimbus/qcom-ngd-ctrl.c  |  6 +--
>  include/linux/device.h           | 81 ++++++++++++++++++++++++++++++++
>  include/linux/platform_device.h  |  5 --
>  sound/soc/samsung/i2s.c          |  6 +--
>  11 files changed, 161 insertions(+), 49 deletions(-)
>
>
> base-commit: 78437ab3b769f80526416570f60173c89858dd84
> --
> 2.53.0
>
Re: [PATCH 0/3] driver core: generalize driver_override infrastructure
Posted by Danilo Krummrich 1 month, 2 weeks ago
On Mon Mar 2, 2026 at 10:41 AM CET, Gui-Dong Han wrote:
>> Danilo Krummrich (3):
>>   driver core: generalize driver_override in struct device
>>   hwmon: axi-fan: don't use driver_override as IRQ name
>>   driver core: platform: use generic driver_override infrastructure
>
> Hi Danilo,
>
> It looks like some usages of platform_device->driver_override were
> missed. I found them here:
> - drivers/bus/simple-pm-bus.c
> - drivers/clk/imx/clk-scu.c
> - drivers/slimbus/qcom-ngd-ctrl.c
> - sound/soc/samsung/i2s.c

They should all be covered by patch 3, no?

> The good news is these can be easily updated to use the new APIs. This
> is required to avoid breaking the build, since the field is removed
> from struct platform_device. The previous build likely passed because
> these weren't enabled. I will use allyesconfig for testing going
> forward.
>
> I scanned for similar cases and most fit the new APIs perfectly. One
> exception is drivers/xen/xen-pciback/pci_stub.c. It does
> strcmp(dev->driver_override, PCISTUB_DRIVER_NAME) instead of using
> drv->name. We might want to change device_match_driver_override() to
> take a const char * instead to handle this.

xen_pcibk_pci_driver should use the exact same define, so we can just convert
this to:

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index e4b27aecbf0591..301207b4a30dac 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -609,9 +609,9 @@ static int pcistub_probe(struct pci_dev *dev, const struct pci_device_id *id)

 	match = pcistub_match(dev);

-	if ((dev->driver_override &&
-	     !strcmp(dev->driver_override, PCISTUB_DRIVER_NAME)) ||
-	    match) {
+	if (device_match_driver_override(&dev->dev,
+					 &xen_pcibk_pci_driver.driver) > 0 ||
+					 match) {

 		if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL
 		    && dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {

I.e. no separate API needed.

> Besides axi-fan, I didn't find any other drivers that need to read
> driver_override. This is great, as it means we hopefully won't need to
> expose a read API at all.

Great, thanks for checking.
Re: [PATCH 0/3] driver core: generalize driver_override infrastructure
Posted by Gui-Dong Han 1 month, 2 weeks ago
On Mon, Mar 2, 2026 at 6:12 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Mon Mar 2, 2026 at 10:41 AM CET, Gui-Dong Han wrote:
> >> Danilo Krummrich (3):
> >>   driver core: generalize driver_override in struct device
> >>   hwmon: axi-fan: don't use driver_override as IRQ name
> >>   driver core: platform: use generic driver_override infrastructure
> >
> > Hi Danilo,
> >
> > It looks like some usages of platform_device->driver_override were
> > missed. I found them here:
> > - drivers/bus/simple-pm-bus.c
> > - drivers/clk/imx/clk-scu.c
> > - drivers/slimbus/qcom-ngd-ctrl.c
> > - sound/soc/samsung/i2s.c
>
> They should all be covered by patch 3, no?

My apologies, I got a bit confused here.

>
> > The good news is these can be easily updated to use the new APIs. This
> > is required to avoid breaking the build, since the field is removed
> > from struct platform_device. The previous build likely passed because
> > these weren't enabled. I will use allyesconfig for testing going
> > forward.
> >
> > I scanned for similar cases and most fit the new APIs perfectly. One
> > exception is drivers/xen/xen-pciback/pci_stub.c. It does
> > strcmp(dev->driver_override, PCISTUB_DRIVER_NAME) instead of using
> > drv->name. We might want to change device_match_driver_override() to
> > take a const char * instead to handle this.
>
> xen_pcibk_pci_driver should use the exact same define, so we can just convert
> this to:
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
> index e4b27aecbf0591..301207b4a30dac 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -609,9 +609,9 @@ static int pcistub_probe(struct pci_dev *dev, const struct pci_device_id *id)
>
>         match = pcistub_match(dev);
>
> -       if ((dev->driver_override &&
> -            !strcmp(dev->driver_override, PCISTUB_DRIVER_NAME)) ||
> -           match) {
> +       if (device_match_driver_override(&dev->dev,
> +                                        &xen_pcibk_pci_driver.driver) > 0 ||
> +                                        match) {
>
>                 if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL
>                     && dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
>
> I.e. no separate API needed.

Thanks for the explanation, you are absolutely right.

>
> > Besides axi-fan, I didn't find any other drivers that need to read
> > driver_override. This is great, as it means we hopefully won't need to
> > expose a read API at all.
>
> Great, thanks for checking.