Bug in USB Generic Serial driver
Hi all,
It seems that the last round of hotplug changes broke a few more things. If you load (or compile in) the USB Generic Serial driver, it will _always_ grab any device that it is offered, if the user does not specify a product and vendor id for it on the 'insmod' command line.
This is because its vendor and product id are set to 0 initially, with _no_ match_flags setting either. In the function, usb_match_id, a value of 0 means accept any as a wild card.
So to fix this, either the Generic Serial driver can change its default values to something like 0xffff for both the vendor and product id, or we can change the usb_match_id function somehow, or something else?
I thought that the usb scanner driver would also have this problem, but it looks like the ability to specify the vendor and product ids as a module load parameter have been removed.
And I also don't like the ordering specificness of the new USB_DEVICE macro, and liked the named initializers better, but can't think of a better way to do it right this second.
Comments?
Thanks Randy, for pointing this problem out to me.
greg k-h
Signature · 6 lines
greg@(kroah|wirex).com _______________________________________________ Linux-hotplug-devel mailing list [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line
From: Greg KH <[email protected]>
[...]
Quoted 7 lines
If you load (or compile in) the USB Generic Serial driver, it will _always_ grab any device that it is offered, if the user does not specify a product and vendor id for it on the 'insmod' command line.
This is because its vendor and product id are set to 0 initially, with _no_
match_flagssetting either. In the function,usb_match_id, a value of 0 means accept any as a wild card.
I have not tried this, but you should be able fix this problem
by changing the declaration of generic_device_ids to something like this:
static struct usb_device_id generic_device_ids[] = {
{ match_flags: USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_PRODUCT}, { } /* Terminating entry */
};
This will cause the device and vendor ID's always to be tested.
From /usr/share/usb.ids, it looks like vendor ID 0 is reserved, so it will not match unless the user sets it.
I sympathize with your misgivings about the USB device ID
helper macros. As I said a couple of days ago, if we shrink the USB_DEVICE_ID_MATCH_xxxx names to USB_MATCH_xxxx, we should not need so many helper macros to keep the code readable, and we should be able to have labelled initializers.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 [email protected] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines
From: Greg KH [mailto:[email protected]]
Hi all,
It seems that the last round of hotplug changes broke a few more things.
If you load (or compile in) the USB Generic Serial driver, it will _always_ grab any device that it is offered, if the user does not specify a product and vendor id for it on the 'insmod' command line.
...
Quoted 5 lines
I thought that the usb scanner driver would also have this problem, but
it looks like the ability to specify the vendor and product ids as a module load parameter have been removed.
No, it's still there, partly in scanner.h, so it may also have this problem. I haven't tried it.
Quoted 7 lines
And I also don't like the ordering specificness of the new
USB_DEVICEmacro, and liked the named initializers better, but can't think of a better way to do it right this second.Comments?
Thanks Randy, for pointing this problem out to me.
I'm glad that you found the cause so quickly.
~Randy
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Adam J. Richter
I sympathize with your misgivings about the USB device ID
helper macros. As I said a couple of days ago, if we shrink theUSB_DEVICE_ID_MATCH_xxxxnames toUSB_MATCH_xxxx, we should not need so many helper macros to keep the code readable, and we should be able to have labelled initializers.
This is another case of "you can't please everyone".
Linus specifically objected to shorter macros and a lack of helper macros. Go figure. But, I wanted it in, and so I did it his way. I didn't really expect him to cram it into 2.4.0 final like he did... but hey, Linux is his baby, not mine.
Matt
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver Your lips are twitching. You're playing Quake aren't you. -- Stef to Greg User Friendly, 8/11/1998