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

[Dmitry Torokhov]

On Tuesday 04 April 2006 17:45, Greg KH wrote:
> On Tue, Apr 04, 2006 at 05:28:48PM -0400, Dmitry Torokhov wrote:
> > On 4/4/06, Greg KH <gregkh@xxxxxxx> 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?
> 

I don't think so because device creation did not fail. Otherwise how
would you as a caller of device_register() distinguish between the
following 2 scenarios:

 - you got -ENOMEM (or other error code) because device creation
   indeed failed;
 - you got -ENOMEM because some odd driver could not allocate 4MB
   of memory.

IOW you trying to propagate driver error to device creation code...

Also result of device_register() should not depend on whether
driver_register() was called earlier or not.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/