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

[Alan Stern <stern@rowland.harvard.edu>]

On Fri, Mar 27, 2026 at 12:30:47PM -0700, Doug Anderson wrote:
> > 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())?
> 
> Ah, I see!
> 
> Yeah, OK. I spent more time, and I think I've a patch that will
> address things. I still like adding the "ready_to_probe" flag and
> setting it in device_add() right before bus_probe_device(). ...but
> I've changed where I'm testing this flag. Now I've got the test in
> __driver_probe_device(), where I simply do:
> 
>   /*
>    * In device_add(), the "struct device" gets linked into the subsystem's
>    * list of devices and broadcast to userspace (via uevent) before we're
>    * quite ready to probe. Those open pathways to driver probe before
>    * we've finished enough of device_add() to reliably support probe.
>    * Detect this and tell other pathways to try again later. device_add()
>    * itself will also try to probe immediately after setting
>    * "ready_to_probe".
>    */
>   if (!dev->ready_to_probe)
>     return dev_err_probe(dev, -EPROBE_DEFER, "Device not ready_to_probe");
> 
> I think that is more inline with your intuition that we should return
> some sort of "try again" code when we end up with this situation. This
> should also block _all_ probe paths safely by adding to the deferral
> list (just in case) or returning -EAGAIN (in the case of
> device_driver_attach()).
> 
> Does that sound like what you're looking for?

Yes, that's exactly what I was asking about.  Let's see the complete 
patch!

Alan Stern