Steve Calfee wrote:
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.
Yep, that all makes sense, thanks.
--
~Randy
-------------------------------------------------------
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
