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

[Doug Anderson]

Hi,

On Sat, Mar 21, 2026 at 8:54 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> > > > I'd also note that the only actual symptom we're seeing is with
> > > > fw_devlink misbehaving (because dev->fwnode->dev wasn't set early
> > > > enough). fw_devlink is a "new" (ish) feature, is officially optional,
> > > > and isn't used on all hardware.
> > >
> > > That's true too, can we set that earlier?
> >
> > Yes, I can post a patch that _just_ moves the set of dev->fwnode->dev
> > earlier, and that will probably fix my symptoms (I'll need to test).
> > This patch already moves it a bit earlier, but if we don't break the
> > linking out as a separate step it would need to move even higher up in
> > the function.
> >
> > Originally, I was going to just propose that, but then I realized that
> > some of the other code in device_add() probably also ought to run
> > before we let the driver probe, and hence I ended up with this patch.
>
> This sounds like a more generic problem.  A bunch of things happen after
> bus_add_device() that should be completed before probing can start; the
> firmware node stuff is just one of them.
>
> Splitting bus_add_device() in two sounds reasonable, although I would
> rename the old routine to bus_link_device, since all it does it add some
> groups and symlinks.  The new routine can be called bus_add_device().

LOL, so basically you want them named exactly opposite I did? That's
OK with me, though maybe:

bus_prep_device()
bus_add_device()


> The real question is whether any of the other stuff that happens before
> bus_probe_device() needs to come after the device is added to the bus's
> list.  The bus_notify() and kobject_uevent() calls are good examples; I
> don't know what their requirements are.  Should they be moved down,
> between the new bus_add_device() and bus_probe_device()?

Yes, this is my question too. The question is, what's worse:

1. Potentially the device getting probed before the calls to
"bus_notify(dev, BUS_NOTIFY_ADD_DEVICE)" and
"kobject_uevent(&dev->kobj, KOBJ_ADD)"

2. Calling "bus_notify(dev, BUS_NOTIFY_ADD_DEVICE)" and
"kobject_uevent(&dev->kobj, KOBJ_ADD)" without first adding to the
subsystem's list of devices.

As it is, my patch says #2 is worse and thus allows for #1. ...but I
don't actually know the answer. The main reason I chose to allow for
#1 is that it makes the behavior less different than it was before my
patch, but that doesn't mean it's correct.

Reading  through a handful of "BUS_NOTIFY_ADD_DEVICE" calls, my guess
is that they expect to be called before probe... That would imply that
my patch made the wrong choice...


I think another option here might be to just add a new bitfield flag
to "struct device", like "ready_to_probe". Right before the call to
bus_probe_device(dev), we could do something like:

device_lock(dev);
dev->ready_to_probe = true;
device_unlcok(dev);

Then in __driver_attach() I can have:

device_lock(dev);
ready_to_probe = dev->ready_to_probe;
device_unlock(dev);
if (!ready_to_probe)
  return 0;

If I do that, I don't think I'll even need to re-order anything, and I
think it's all safe. Basically, it just the device hidden from the
__driver_attach() logic until probe is ready.

What do you think?

-Doug