From: "Danilo Krummrich" <dakr@kernel.org>
To: "Gui-Dong Han" <hanguidong02@gmail.com>
Cc: <gregkh@linuxfoundation.org>, <rafael@kernel.org>,
<ysato@users.sourceforge.jp>, <dalias@libc.org>,
<glaubitz@physik.fu-berlin.de>, <abelvesa@kernel.org>,
<srini@kernel.org>, <s.nawrocki@samsung.com>,
<nuno.sa@analog.com>, <driver-core@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, <imx@lists.linux.dev>,
<linux-hwmon@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<linux-sound@vger.kernel.org>, <linux-sh@vger.kernel.org>,
"Wang Jiayue" <akaieurus@gmail.com>
Subject: Re: [PATCH 0/3] driver core: generalize driver_override infrastructure
Date: Mon, 02 Mar 2026 11:12:43 +0100 [thread overview]
Message-ID: <DGS7SQHM3V5U.2DNQV68AMSITF@kernel.org> (raw)
In-Reply-To: <CALbr=LYYUH_yQL1PO7mXzK6Oubt0LvKb0714iZCx_eEXScVdyQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2026-03-02 10:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 0:25 [PATCH 0/3] driver core: generalize driver_override infrastructure Danilo Krummrich
2026-03-02 0:25 ` [PATCH 1/3] driver core: generalize driver_override in struct device Danilo Krummrich
2026-03-02 7:35 ` Gui-Dong Han
2026-03-02 8:36 ` Gui-Dong Han
2026-03-02 10:05 ` Danilo Krummrich
2026-03-02 11:04 ` Gui-Dong Han
2026-03-02 10:00 ` Geert Uytterhoeven
2026-03-02 10:26 ` Danilo Krummrich
2026-03-02 10:38 ` Geert Uytterhoeven
2026-03-02 11:03 ` Danilo Krummrich
2026-03-02 10:23 ` Armin Wolf
2026-03-02 16:28 ` Danilo Krummrich
2026-03-02 0:25 ` [PATCH 2/3] hwmon: axi-fan: don't use driver_override as IRQ name Danilo Krummrich
2026-03-02 0:51 ` Guenter Roeck
2026-03-02 10:00 ` Danilo Krummrich
2026-03-02 11:02 ` Nuno Sá
2026-03-02 0:25 ` [PATCH 3/3] driver core: platform: use generic driver_override infrastructure Danilo Krummrich
2026-03-02 8:55 ` Gui-Dong Han
2026-03-02 9:41 ` [PATCH 0/3] driver core: generalize " Gui-Dong Han
2026-03-02 10:12 ` Danilo Krummrich [this message]
2026-03-02 10:59 ` Gui-Dong Han
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=DGS7SQHM3V5U.2DNQV68AMSITF@kernel.org \
--to=dakr@kernel.org \
--cc=abelvesa@kernel.org \
--cc=akaieurus@gmail.com \
--cc=dalias@libc.org \
--cc=driver-core@lists.linux.dev \
--cc=glaubitz@physik.fu-berlin.de \
--cc=gregkh@linuxfoundation.org \
--cc=hanguidong02@gmail.com \
--cc=imx@lists.linux.dev \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=rafael@kernel.org \
--cc=s.nawrocki@samsung.com \
--cc=srini@kernel.org \
--cc=ysato@users.sourceforge.jp \
/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