Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree

[Greg KH <gregkh@suse.de>]

On Tue, Apr 04, 2006 at 05:28:48PM -0400, Dmitry Torokhov wrote:
> On 4/4/06, Greg KH <gregkh@suse.de> wrote:
> >
> > Hm, no, I unwound this mess, and found the following:
> >
> >  - bus_add_device() calls device_attach()
> >  - device_attach() calls bus_for_each_drv() for every driver on the bus
> >  - bus_for_each_drv() walks all drivers on the bus and calls
> >   __device_attach() for every individual driver
> >  - __device_attach() calls driver_probe_device() for that driver and device
> >  - driver_probe_device() calls down to the probe() function for the
> >   driver, passing it that driver, if match() for the bus matches this
> >   device.
> >  - if that probe() function returns -ENODEV or -ENXIO[1] then the error
> >   is ignored and 0 is returned, causing the loop to continue to try
> >   more drivers
> >  - if the probe() function returns any other error code, it is
> >   propagated up, all the way back to bus_add_device.
> 
> But why do we do that? probe() failing is driver's problem. The device
> is still there and should still be presented in sysfs. I don't think
> that we should stop if probe() fails - maybe next driver manages to
> bind itself.

The device is still there.

Ah, I see what you are saying now.  Yeah, we should still add the
default attributes for the bus and create the bus link even if some
random driver had problems.  But then, we should still propagate the
error back up, right?

If I changed the patch to do that, would it be acceptable to you?

thanks,

greg k-h