On Tue, Apr 04, 2006 at 02:00:48PM -0700, Greg KH wrote:
> On Tue, Apr 04, 2006 at 04:23:43PM -0400, Dmitry Torokhov wrote:
> > On 4/4/06, [email protected] <[email protected]> wrote:
> > >
> > > --- gregkh-2.6.orig/drivers/base/bus.c
> > > +++ gregkh-2.6/drivers/base/bus.c
> > > @@ -372,14 +372,17 @@ int bus_add_device(struct device * dev)
> > >
> > > if (bus) {
> > > pr_debug("bus %s: add device %s\n", bus->name, dev->bus_id);
> > > - device_attach(dev);
> > > + error = device_attach(dev);
> > > + if (error < 0)
> > > + goto exit;
> >
> > I do not believe that this is correct. The fact that _some_ driver
> > failed to attach to a device does not necessarily mean that device
> > itself does not exist. While this assuption might work for platform
> > devices it won't work for other busses.
>
> 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.
> - 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.
>
> 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 :)
Yup, things still seem to work properly for me. The patch will show up
in the next -mm for others to beat on...
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
