I have a Belkin USB Wireless adapter with ID 050d:705a.
Both rt2500usb.c and rt73usb.c claim that they can drive the device with
this ID.
When using the distro kernel as well as custom 2.4.24-rc1 both rt73usb and
rt2500usb get loaded and fight for the register writes and fail. rt2500usb
is not able to drive my device. So I have to manually rmmod/modprobe or
delete rt2500usb.ko and depmod every time I get a new kernel.
If only rt73usb is loaded everything works well. To me it
sounds like rt2500usb should not be driving 050d:705a.
There is another ID 050d:7050 which is also claimed to be handled by both
rt3500usb and rt73usb. Assuming rt73usb can drive this as well (I have no
way to be sure as I don't have device with this ID) the following patch
makes sure only rt73usb claims the 2 devices.
Signed-off-by: Parag Warudkar <[email protected]>
--- linux-2.6-wk/drivers/net/wireless/rt2x00/rt2500usb.c.orig 2007-10-24 18:51:45.000000000 -0400
+++ linux-2.6-wk/drivers/net/wireless/rt2x00/rt2500usb.c 2007-10-24 18:52:31.000000000 -0400
@@ -1758,9 +1758,7 @@
{ USB_DEVICE(0x0b05, 0x1706), USB_DEVICE_DATA(&rt2500usb_ops) },
{ USB_DEVICE(0x0b05, 0x1707), USB_DEVICE_DATA(&rt2500usb_ops) },
/* Belkin */
- { USB_DEVICE(0x050d, 0x7050), USB_DEVICE_DATA(&rt2500usb_ops) },
{ USB_DEVICE(0x050d, 0x7051), USB_DEVICE_DATA(&rt2500usb_ops) },
- { USB_DEVICE(0x050d, 0x705a), USB_DEVICE_DATA(&rt2500usb_ops) },
/* Cisco Systems */
{ USB_DEVICE(0x13b1, 0x000d), USB_DEVICE_DATA(&rt2500usb_ops) },
{ USB_DEVICE(0x13b1, 0x0011), USB_DEVICE_DATA(&rt2500usb_ops) },
On Thursday 25 October 2007 00:22, Parag Warudkar wrote:
> I have a Belkin USB Wireless adapter with ID 050d:705a.
> Both rt2500usb.c and rt73usb.c claim that they can drive the device with
> this ID.
>
> When using the distro kernel as well as custom 2.4.24-rc1 both rt73usb and
> rt2500usb get loaded and fight for the register writes and fail. rt2500usb
> is not able to drive my device. So I have to manually rmmod/modprobe or
> delete rt2500usb.ko and depmod every time I get a new kernel.
>
> If only rt73usb is loaded everything works well. To me it
> sounds like rt2500usb should not be driving 050d:705a.
>
Unfortunately Belkin have sold both RT73 and RT2500 devices with
that USB ID. You don't say what distro you are runing or what version
of RT2x00 it ships with but last time I checked with the git version of
rt2x00 it tried to load both drivers but the rt2500 driver noticed it was the
wrong hardware and shut down.
My Belkin stick is busy right now but I'll test that still works later.
> There is another ID 050d:7050 which is also claimed to be handled by both
> rt3500usb and rt73usb. Assuming rt73usb can drive this as well (I have no
> way to be sure as I don't have device with this ID) the following patch
> makes sure only rt73usb claims the 2 devices.
>
There are a few such devices but they are all cases where there are reliable
reports of manufacturers shipping both device types with one USB ID. There
are some cases where the alternate chipset with the same USB ID isn't even a
ralink device but there isn't much we can do about those.
Hi,
> I have a Belkin USB Wireless adapter with ID 050d:705a.
> Both rt2500usb.c and rt73usb.c claim that they can drive the device with
> this ID.
>
> When using the distro kernel as well as custom 2.4.24-rc1 both rt73usb and
> rt2500usb get loaded and fight for the register writes and fail. rt2500usb
> is not able to drive my device. So I have to manually rmmod/modprobe or
> delete rt2500usb.ko and depmod every time I get a new kernel.
>
> If only rt73usb is loaded everything works well. To me it
> sounds like rt2500usb should not be driving 050d:705a.
>
> There is another ID 050d:7050 which is also claimed to be handled by both
> rt3500usb and rt73usb. Assuming rt73usb can drive this as well (I have no
> way to be sure as I don't have device with this ID) the following patch
> makes sure only rt73usb claims the 2 devices.
I awknowledge the problem, but the solution cannot be found in the USB ID's
listed in the driver. The bug is the manufacturer who changed chipset while
keeping the USB ID the same.
There are 2 possible ways around this: hacking the module loader so
it continues searching for a different driver when the first driver indicates
that it cannot control the device.
Or the easiest way, just blacklist rt2500usb if you are sure you need the rt73 driver.
Ivo
On Thu, 25 Oct 2007, Adam Baker wrote:
>
> Unfortunately Belkin have sold both RT73 and RT2500 devices with
> that USB ID. You don't say what distro you are runing or what version
> of RT2x00 it ships with but last time I checked with the git version of
> rt2x00 it tried to load both drivers but the rt2500 driver noticed it was the
> wrong hardware and shut down.
Like I said this did not work with 2.6.24-rc1 (latest git). My distro
(Ubuntu 7.10) kernel 2.6.22-10 also has the same behavior.
> There are a few such devices but they are all cases where there are reliable
> reports of manufacturers shipping both device types with one USB ID. There
> are some cases where the alternate chipset with the same USB ID isn't even a
> ralink device but there isn't much we can do about those.
>
Ok, I failed to imagine the hardware makers' stupidity :) - In the case
that you mentioned I agree that there is little that can be done based on
device IDs. I'll check out subsequent releases to see if it gets fixed
based on hardware characteristics (rt2500usb unloading and requesting the
right one in my case for example).
Thanks
Parag
Hi Ivo
On Thu, 25 Oct 2007, Ivo van Doorn wrote:
> I awknowledge the problem, but the solution cannot be found in the USB ID's
> listed in the driver. The bug is the manufacturer who changed chipset while
> keeping the USB ID the same.
> There are 2 possible ways around this: hacking the module loader so
> it continues searching for a different driver when the first driver indicates
> that it cannot control the device.
> Or the easiest way, just blacklist rt2500usb if you are sure you need the rt73 driver.
Thanks for the heads up - I think you have a good idea - there should be
an interface between the loader and module to specify conditions like this.
I will see if I can generate interest in that idea and hack up something
along the lines of your suggestion.
Parag
On Friday 26 October 2007, Parag Warudkar wrote:
>
> Hi Ivo
>
> On Thu, 25 Oct 2007, Ivo van Doorn wrote:
>
> > I awknowledge the problem, but the solution cannot be found in the USB ID's
> > listed in the driver. The bug is the manufacturer who changed chipset while
> > keeping the USB ID the same.
> > There are 2 possible ways around this: hacking the module loader so
> > it continues searching for a different driver when the first driver indicates
> > that it cannot control the device.
> > Or the easiest way, just blacklist rt2500usb if you are sure you need the rt73 driver.
>
> Thanks for the heads up - I think you have a good idea - there should be
> an interface between the loader and module to specify conditions like this.
>
> I will see if I can generate interest in that idea and hack up something
> along the lines of your suggestion.
Well it could be something quite simple, in the module loader it is looping
through all modules to look for a device with the correct USB/PCI ID.
Currently, after the first occurence it loads the module and doesn't continue,
it should perhaps be relatively easy that it checks if the driver returned -ENODEV
and continues looping to search for another driver.
Ivo
> Well it could be something quite simple, in the module loader it is looping
> through all modules to look for a device with the correct USB/PCI ID.
> Currently, after the first occurence it loads the module and doesn't continue,
> it should perhaps be relatively easy that it checks if the driver returned -ENODEV
> and continues looping to search for another driver.
But a driver (especially a driver for something as hot-pluggable as a
USB device) shouldn't return -ENODEV just because no devices are
present at the moment. It should just load successfully and wait for
a device to appear.
- R.
On Friday 26 October 2007 20:10, Roland Dreier wrote:
> ?> Well it could be something quite simple, in the module loader it is
> looping > through all modules to look for a device with the correct USB/PCI
> ID. > Currently, after the first occurence it loads the module and doesn't
> continue, > it should perhaps be relatively easy that it checks if the
> driver returned -ENODEV > and continues looping to search for another
> driver.
>
> But a driver (especially a driver for something as hot-pluggable as a
> USB device) shouldn't return -ENODEV just because no devices are
> present at the moment. ?It should just load successfully and wait for
> a device to appear.
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
Adam
> 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.
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