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

From: Doug Anderson

Date: Mon Mar 30 2026 - 10:42:23 EST


Hi,

On Fri, Mar 27, 2026 at 6:35 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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!

Yay! Thank you for your patience / reviews / help. As always, it's
much appreciated!

I ran tests over the weekend and things look really good, so I've
posted v2 here:

https://lore.kernel.org/r/20260330072839.v2.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid

-Doug