Re: [PATCH] driver core: take parent lock on deferred probe

["Danilo Krummrich" <dakr@kernel.org>]

On Wed Oct 14, 2026 at 10:15 AM CEST, Johan Hovold wrote:
> On Tue, Oct 13, 2026 at 11:01:16PM +0200, Danilo Krummrich wrote:
>> The issue concerns a USB device and its parent hub's USB device.  (This makes me
>> wonder whether probing a USB device actually requires the parent USB HUB
>> device's lock to be held, or whether this is just a consequence of sharing the
>> same usb_bus_type?)
>
> Indeed. We could consider making this a device type attribute instead
> and move it to usb_if_device_type. May speed up USB enumeration for
> people using async probe too.

Great, that sounds like the better approach to me then.

>> In theory a USB device could also keep a reference count to its parent, but then
>> the driver core code would rely on an implementation detail of its users; I'd
>> prefer not to make driver core's access to dev->parent depend on references
>> maintained by individual subsystems.
>> 
>> I'd even go a step further any say that if subsystems try to keep this pointer
>> valid beyond what's guaranteed by the driver core, they should do this with a
>> separate bus specific pointer.  The reason is that otherwise the lifetime and
>> ownership definition of this pointer does not depend on API contracts, but on
>> individual implementation details, which is a very common source for all kinds
>> of bugs.
>
> But it's driver core that needs the extra reference. It seems
> reasonable to require that any subsystem that sets a new
> type->need_parent_lock also makes sure that any device of that type
> holds a reference to its parent. And importantly, it's already the case
> for the only user of this feature today (i.e. USB interfaces).

Exactly, it is the driver core that needs the extra reference count; for a field
that is owned by the driver core, and for which the driver core manages its
lifetime.  If it needs an additional reference count for async or deferred work
it should obtain the reference count for this scope explicitly.

USB interfaces already holding an additional reference makes the proposed
contract work for today's user, but I'd rather not make that prerequisite of the
API.  It would push a prerequisite for an implementation detail to the user.

Please, let's not add this API contract. Let's have the driver core deal with
this internally.