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 <[email protected]> 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 [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]
