Hi Randy,
Ironically, my spam trap email account is now blocked from sending to the mailing list, probably because of too much spamming from hotmail. So, if you think this is relevant, please forward to the list. Anyway see below:
At 02:18 PM 2/23/2005 -0800, you wrote: Alan Stern wrote: On Wed, 23 Feb 2005, Glenn Maynard wrote:
On Wed, Feb 23, 2005 at 03:39:29PM -0500, Alan Stern wrote:
I ngelected to mention it above, but the stored strings should also be
used in core/devices.c for populating /proc/bus/usb/devices. And since the strings should be accessible through the usb_device and related
structures, other drivers would be able to use them directly. (For example, usb-storage does some string descriptor fetches that could be
eliminated.)
Does lsusb still do these queries, too? I've triggered errors by running "lsusb -v", and I've also had lsusb hang when those queries timed out. (I havn't looked to see if lsusb uses sysfs instead of libusb now, though.)
lsusb does make the queries (going through usbfs). lsusb _has_ to use libusb; sysfs only includes information for active configurations whereas lsusb wants to print out information for all configurations. Come to think of it, even when the proposed changes are made lsusb will still cause problems, as will every program that reads the string descriptors. You can see why this whole mess doesn't really have a simple solution...
IIRC, one reason this was tried (and dropped) is that some devices load new firmware which alters all/most/some of the device descriptors, so the kernel cache is incorrect... unless they are re-read after a firmware download.
Anybody else recall this? or am I remembering it incorrectly?
-- ~Randy
Well, I just fired up my Keyspan usb to rs232 adapter based on Cypress' EZUSB - connected to "winXP home". It morphs itself after reenumeration to a device with different strings than the original device. I looked at it with my "Kitty Usb Analyzer" to see what happened to the descriptors using the bus sniffer.
Initially it comes up as:
bmRequestType: 0x80 dev_to_host Standard Device
bRequest: 0x06 USB_REQ_GET_DESCRIPTOR
wValue: 0x0100 ind:0 type:DEVICE
wIndex: 0x0000
wLength: 0x0012
DEVICE Descriptor
0 bLength 0x12 The size of this descriptor is 18 bytes
1 bDescriptorType 0x1 DEVICE Descriptor Type
2 bcdUSB 0x0100 Device compliant to the USB specification version 1.0.0
4 bDeviceClass 0xff Class: Vendor-Specific
5 bDeviceSubClass 0xff undefined subclass
6 bDeviceProtocol 0xff No protocols per device
7 bMaxPacketSize0 0x40 Maximum packet size for endpoint zero is 64
8 idVendor 0x06cd The Vendor ID is 0x06cd=1741
10 idProduct 0x010b The Product ID is 0x010b=267
12 bcdDevice 0x8001 The device release number is 128.0.1
14 iManufacturer 0x0 manufacturer string descriptor describing the manufacturer
15 iProduct 0x0 manufacturer string descriptor describing the product
16 iSerialNumber 0x0 manufacturer string descriptor describing the serial number
17 bNumConfigurations 0x1 The device has 1 possible configurations
And after reenumeration, it gives this device descriptor:
DEVICE Descriptor
0 bLength 0x12 The size of this descriptor is 18 bytes
1 bDescriptorType 0x1 DEVICE Descriptor Type
2 bcdUSB 0x0110 Device compliant to the USB specification version 1.1.0
4 bDeviceClass 0xff Class: Vendor-Specific
5 bDeviceSubClass 0xff undefined subclass
6 bDeviceProtocol 0xff No protocols per device
7 bMaxPacketSize0 0x40 Maximum packet size for endpoint zero is 64
8 idVendor 0x06cd The Vendor ID is 0x06cd=1741
10 idProduct 0x010c The Product ID is 0x010c=268
12 bcdDevice 0x0001 The device release number is 0.0.1
14 iManufacturer 0x1 manufacturer string descriptor describing the manufacturer
15 iProduct 0x2 manufacturer string descriptor describing the product
16 iSerialNumber 0x0 manufacturer string descriptor describing the serial number
17 bNumConfigurations 0x2 The device has 2 possible configurations
So you can see that it now has string descriptors, where the first (pre download of firmware configuration) did not.
Now I don't see how this particular situation should be a problem to the Linux stack. Renumeration is a magic process where the device gets the download, takes itself off the bus and then puts itself back on the bus for a second enumeration as a new device. So in this case, the strings don't change, the device does. This means that the one physical device is two logical devices, first a firmware downloadable device and then later the device that was downloaded. The two devices are never simultaneously attached, just sequentially.
So as long as the Linux stack removes devices that are detached, the EZUSB devices should not be a problem with "redefining" their strings, because from the Linux standpoint that is an entirely different device from the one that was initially attached as a firmware downloadable device.
So my conclusion is that having the OS cache strings should work fine, as long as devices that detach are removed from the cache.
There may be other mutant USB devices that change their string descriptors while in use, but I have not seen one. In fact strings are pretty useless in a device, many don't even have any strings.
Regards ~Steve
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
