Messages in this thread | | | Date | Tue, 4 Apr 2006 14:45:22 -0700 | From | Greg KH <> | Subject | Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |