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

linux

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

Postby Adam Baker » Sat, 27 Oct 2007 05:10:20 GMT



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 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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

Postby Ivo van Doorn » Sat, 27 Oct 2007 06:00:19 GMT

Hi,


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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

Postby Parag Warudkar » Sat, 27 Oct 2007 07:40:08 GMT






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.


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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

Postby Ivo van Doorn » Sun, 28 Oct 2007 03:30:10 GMT




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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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

Postby Roland Dreier » Sun, 28 Oct 2007 04:20:14 GMT

 > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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

Postby Adam Baker » Sun, 28 Oct 2007 05:00:15 GMT



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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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

Postby Roland Dreier » Sun, 28 Oct 2007 05:10:13 GMT

 > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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

Postby Ivo van Doorn » Sun, 28 Oct 2007 06:20:22 GMT



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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 



Return to linux

 

Who is online

Users browsing this forum: No registered users and 3 guest