Messages in this thread | | | Date | Tue, 4 Apr 2006 17:28:48 -0400 | From | "Dmitry Torokhov" <> | Subject | Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree |
| |
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.
> - if the probe() function returns 0, the device is bound to the driver, > and it returns 0. Hm, looks like we continue to loop here too, we > could probably stop now that we have bound a driver to the device. >
Could it be that logic is simply reversed?
> So, I'm pretty sure that this is safe and should work just fine. To be > sure, let me go reboot my box with this change on it after I finish this > email :) > > Does that help? > > thanks, > > greg k-h > > [1] - stupid agp drivers (or some other video drivers) require this. I > need to go fix them up so they don't do this, if they haven't been > fixed already... >
-- Dmitry - 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/
| |