Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

[Ivo van Doorn <ivdoorn@gmail.com>]

On Friday 26 October 2007, Roland Dreier wrote:
>  > The function that is returning ENODEV is the driver probe function. According 
>  > to Documentation/DocBook/writing_usb_driver/ch03.html when that function is 
>  > called 
>  > 
>  > "The driver now needs to verify that this device is actually one that it can 
>  > accept. If so, it returns 0. If not, or if any error occurs during 
>  > initialization, an errorcode (such as -ENOMEM or -ENODEV) is returned from 
>  > the probe function."
>  > 
>  > It isn't a device the driver can accept so it returns -ENODEV
> 
> That's all true but irrelevant.  That error return isn't propagated
> back to userspace when it runs modprobe (and in fact it *can't* be
> sanely returned to userspace -- what do you do if the probe function
> succeeds for two devices and fails for a third?).  So there's not
> really any way for userspace to loop through a list of modules until
> one succeeds.

We are mixing 2 things up I think.

We have module loading, which is called when the module is loaded and
will register what PCI or USB devices it supports.
And we have hardware probing, which results in the kernel calling the probe()
function of the usb_driver or pci_driver structure.

The the return value of the module loading is not an issue, since indeed that is called
while the hardware might not be present.
The hardware probing _is_ called when the hardware is present, reason is simple,
hotplugging detects the new card and checks all registered USB/PCI ID's for a driver
that matches the device. If it matches the probe() function is called.
And that is where the ENODEV error could be checked, if the driver decides that the
plugged in device it was offere by the kernel is not a device it supports it needs
to tell that to the kernel. In turn the kernel can continue looking into the registered
USB/PCI ID lists to find a different driver that does support the hardware.

Ivo