On Mon, 25 Jun 2012, Sarah Sharp wrote: > On Mon, Jun 25, 2012 at 01:30:56PM -0400, Alan Stern wrote: > > On Mon, 25 Jun 2012, Sarah Sharp wrote: > > > static void > > > -dump_device_status(libusb_device_handle *fd, int otg, int wireless) > > > +dump_device_status(libusb_device_handle *fd, int otg, int wireless, int super_speed) > > > > This doesn't seem consistent... > > > > > @@ -3796,7 +3804,7 @@ static void dumpdev(libusb_device *dev) > > > do_dualspeed(udev); > > > } > > > do_debug(udev); > > > - dump_device_status(udev, otg, wireless); > > > + dump_device_status(udev, otg, wireless, desc.bcdUSB >= 0x0300); > > > > with this. Isn't it true that a USB-3 device will report a bcdUSB > > value of 0x0300 or above, even when running at high speed or slower? > > 9.6.1 in the USB-3 spec says: > > > > The device descriptor of a SuperSpeed capable device has > > a version number of 3.0 (0300H). > > I plugged in a USB 3.0 camera from Point Grey into a USB 2.0 only port, > and it reported a bcdUSB of 0x0210. A Pluggable USB 3.0 hard drive also > reports 0x0210, as well as a TI UAS device. So I assume that the bcdUSB > is always 0x0210 when operating at HS, and 0x0300 when operating at SS. Ah, so the manufacturers are not trying to comply with the spec... (Note that the spec says "A device has only one device descriptor." Presumably it means only one device descriptor for each operating speed -- the USB-2 spec makes the same mistake.) On the other hand, the USB-3 spec also says that when operating in a USB-2 electrical environment, the device will "return appropriate information according to the requirements laid out in the USB 2.0 specification". This contradicts the requirement the bcdUSB value will be 3.0. So maybe the manufacturers shouldn't be blamed. > > So it looks like the variable should be named "usb3" rather than > > "super_speed". > > Do you still want me to rename the variable? Shucks -- I don't care one way or another. It just seemed logical to have a closer relation between the variable's name and the test used for setting it. For that matter, it has been noticeable for a very long time that lsusb doesn't print out the device's operating speed. (In fact, usbfs doesn't even provide a way of getting the device speed; all it can report is whether or not the device is running at low speed! Of course, the speed _is_ available in sysfs.) > > Alan Stern > > > > P.S.: On the other hand, the USB-3 spec also says (in 9.6.2.2) that > > wSpeedsSupported is a bitmap encoding of the speed supported by the > > device when operating in SuperSpeed mode -- including bitflags > > indicating the device supports operation at low, full, and high speed! > > > > How is a device supposed to operate at high speed when operating in > > SuperSpeed mode? > > wSpeedsSupported has two purposes. First, it's an indication of the > speeds that the device can work at if it's not operating at SuperSpeed. > Second, it's an list of the possible data transfer speeds when operating > in SuperSpeed mode. You're missing my point. The specs says "speeds supported ... when operating in SuperSpeed mode". So how can it possibly indicate what the device can do while not operating at SuperSpeed? To put it another way, what sense is there in saying "this device can operate at full speed while in SuperSpeed mode"? The underlying intention behind the field seems fairly clear. But the actual wording of the spec does not express it properly. Do you sometimes get the impression that the USB-3 specification was created a little too hastily? So far I have run across only one place where the USB-2 design seems badly flawed -- the implementation of split transactions -- and even that wouldn't have been so bad if the EHCI design had been more intelligent than it is. But USB-3 seems to have rather more of these little infelicities. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
