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

[Alan Stern]

On Thu, Mar 26, 2026 at 02:49:33PM -0700, Doug Anderson wrote:
> > > 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.)
> 
> In my proposed solution, I was returning 0 from __driver_attach(). The
> only place that's called from is driver_attach(), which calls it with
> bus_for_each_dev(). I don't think returning -EAGAIN is a good idea
> there since it stops bus_for_each_dev(). In general __driver_attach()
> always returns 0.
> 
> In general, the goal of my new proposed patch is to add the device to
> the subsystem's "klist_devices" exactly where we do it today for
> maximum compatibility. This means that if any code was relying on
> being able to find the device, they can still find it. The _only_
> exception is that I don't want to be able to find the device in
> driver_attach(). So my proposed solution just hides the device in that
> one case.

But why just in that one case?  That's what I don't understand.  If it's 
not okay to bind at this time on the driver-load path, why is it okay to 
bind on other pathways (such as bus.c:bind_store())?

> I believe this should be fine. Specifically, driver_attach() could
> have been called (in another thread) immediately before
> bus_add_device() and everything would have been fine. driver_attach()
> wouldn't have found the device (because it wasn't linked in) but the
> probe would still happen.

That's not in question.

> > 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.
> 
> I'm not completely sure I follow what you're suggesting here...

I'm saying that the BUS_NOTIFY_ADD_DEVICE message probably should go out 
after the device has been linked into the bus's list, as it does now.

> I still believe adding a flag that just hides the device from
> driver_attach() is a safe and correct approach. In general I don't
> want to fragment the discussoin, but I think it might be useful to
> send a v2 that shows what that looks like. Any objections?

I just would like an answer to the question above.

Alan Stern