Re: [PATCH v4] driver core: avoid klist_remove() on unattached knode_driver

[Danilo Krummrich]

On Mon Aug 24, 2026 at 6:47 AM CEST, Akihiko Kai wrote:
> On Fri, Aug 21, 2026 at 03:54:44AM +0200, Danilo Krummrich wrote:
>> usb_driver_claim_interface() is the only callsite in the kernel that
>> does set dev->driver without a subsequent device_bind_driver().
>
> Small correction, I think there are a few more. usb_port
> (drivers/usb/core/port.c:782) sets dev->driver before device_register(),
> and usb_port_driver has no ->match and no ->probe, so it depends entirely
> on the __device_attach() dev->driver path to get bound. ccwgroup
> (drivers/s390/cio/ccwgroup.c:385) and pata_parport
> (drivers/ata/pata_parport/pata_parport.c:515) do the same. So that path
> doesn't look USB-claim-specific, and if we ever want to remove it,
> usb_port would need a ->match() first.

Good catch, I think those should be fixed as well.

I had a brief look at the usb_port one and it should be exactly the same case as
w1, which I already fixed [1]. Actually, it is even simpler, usb_device_match()
can just handle the usb_port_device_type, as the USB core already does for other
device types. I can send a patch for this later on.

[1] https://lore.kernel.org/driver-core/20260820225430.1847356-1-dakr@xxxxxxxxxx/

> For the root cause, what about this: in usb_driver_claim_interface(),
> when the interface isn't registered yet, just don't set dev->driver --
> record the claim on struct usb_interface instead. Then, once the
> interface gets added in usb_set_configuration(), bind it explicitly with
> device_bind_driver(). That skips ->probe, which is exactly what
> usb_audio's claim-now-bind-later needs, and it also attaches
> knode_driver so teardown is safe. The __device_attach() path can stay
> for w1/ccwgroup/pata_parport.
>
> Does that sound reasonable?

I'd prefer to get rid of the dev->driver path in __device_attach(), I think
there's no reason not to use the common match() path instead.

So, for a fix that also goes into stable trees what you propose sounds
reasonable, but eventually we should use the match() infrastructure instead.