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

[Rene Herman <rene.herman@keyaccess.nl>]

Greg KH wrote:

>  - 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

> [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...

Is the "this" in "require this" referring to (-ENODEV or -ENXIO) or to 
-ENXIO alone and do you consider the -ENODEV behaviour correct?

ALSA wants platform_device_register_simple() to return an IS_ERR() on 
driver probe error and the submitted patch makes it do so for all the 
other errors but ALSA likes to propagate errors up as far as possible, 
and currently its probe() methods can return either...

To Dmitry, I see you saying "probe() failing is driver's problem. The 
device is still there and should still be presented in sysfs.". No, at 
least in the case of these platform drivers (or at least these old ISA 
cards using the platform driver interface), a -ENODEV return from the 
probe() method would mean the device is _not_ present (or not found at 
least). NODEV.

As said before, if the behaviour makes sense for other busses, maybe 
propagating errors up should be dependent on a flags value somewhere 
that a platform-driver sets?

If platform_device_register_simple() never returns an IS_ERR() when the 
device is not found that means it's not a useful interface for hardware 
that needs to be probed for at the very least. ALSA would need to do 
something like, just before returning a succesfull return from the 
probe() method, set a global flag that the platform_device that is about 
to be registered is actually representing something, and freeing all 
platform_devices for which the flag is _not_ set again after this.

Which ofcourse means this is not at all useful. It's just working around 
the driver model then...

Rene.