Re: [RFC PATCH] driver core: Don't link the device to the bus until we're ready to probe

[Alan Stern]

On Mon, Mar 23, 2026 at 03:24:52PM -0700, Doug Anderson wrote:
> > You know, I wrote this but I'm not so sure that it's accurate.  We've
> > gone many years with no big changes to this code; most likely it doesn't
> > need alterations now.
> 
> That's fair, but I'm really just worried that the Android parallel
> module loading code, which is only ~1 year old (and needs to be opted
> in for each device) is stressing things in a way that nobody else is.
> In most distros, I think modules are loaded "on-demand". A device gets
> added first, and then we figure out which module has the driver that's
> needed and load the module. Nice and sequential. Android seems to have
> a different approach. As far as I understand it just has a list of
> modules to load and slams through loading all of them even as devices
> are still being added.
> 
> I don't think that what Android is doing is technically "wrong", but
> it's certainly odd compared to all other distros.
> 
> Unless we say that what Android is doing is wrong (and decide what to
> do about it), it seems like we need to make sure it's robust.

Loading a bunch of modules as fast as possible should not be wrong.  The 
kernel certainly ought to be able to handle it.

> > Nothing wrong with those names.  But instead of making these fairly
> > intrusive changes it might be better just to move the firmware stuff to
> > a different place in the code (you mentioned this possibility in your
> > first email).  It would be a smaller change, that's for sure.
> 
> I'll do that if that's what everyone wants, but the more I think about
> it the more worried I am that we'll end up with a hidden / harder to
> debug problem where some driver gets unhappy when its probe is called
> before dpm_sysfs_add(), device_pm_add(), device_create_file(),
> device_create_sys_dev_entry(), BUS_NOTIFY_ADD_DEVICE, ...

It's hard to know for all of them.  However, it seems pretty clear that 
device_pm_add() should come before probing, since a probe routine will 
generally want to affect the device's runtime PM state.

> > There should not be any difference between probing caused by the device
> > being added to the bus, vs. caused by a new driver being registered, vs.
> > caused by anything else (such as sysfs).  None of these should be
> > allowed until all of them can be handled properly.
> 
> Right. ...and I think that's what my proposed "ready_to_probe" does.
> It really does seem like quite a safe change. It _just_ prevents the
> driver load path from initiating a probe too early.

Any such consideration should apply to all the probe paths, not just 
driver loading.  (Also, if it's too early to probe the device, perhaps 
the return code should be -EAGAIN instead of 0.)

I'm not at all sure whether the constraints we've got will need to force 
some events to happen after adding the device to the bus list and before 
allowing probing to start.

> > And linking the device into the bus's list of devices should be the
> > event that makes probing possible.
> 
> Sure, but moving the linking into the bus's list of devices all the
> way to the end is definitely a bigger change. If nothing else,
> "bus_for_each_dev()" starts to be able to find the device once it's
> linked into the list. If any of the ~50 drivers who register for
> BUS_NOTIFY_ADD_DEVICE are relying on the device to show up in
> "bus_for_each_dev()", it would be bad...

I don't know the answer to this.  That is, I don't know if there are any 
notification handlers depending on the device showing up in the bus's 
list.  The safest thing to do is issue the notification after adding the 
device to the list -- which may mean after probing has potentially 
started.  Is there any reason why that would be a problem?  I'm not 
aware of any.

The order constraints should be commented explicitly in device_add(), 
not just implicitly implied by the code.  Otherwise people won't know 
what changes are allowed and what changes are forbidden.

Alan Stern