On Mon, Jun 25, 2012 at 04:10:16PM -0400, Alan Stern wrote:
> 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.)
Yes, I would assume so.
> 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.
Yep, there's definitely some inconsistencies in the USB 3.0 spec.
> > > 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.)
I see. Actually one of my co-workers was asking the same question,
("How do I know what speed the USB device is actually running at?") and
the best I could answer him was to tell him to check whether the device
showed up on the USB 3.0 roothub or the USB 2.0 roothub. Of course,
with the rate matching EHCI roothubs, you can't use the bus to
differentiate between full speed and high speed.
> > > 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.
You're missing my point too. :) I know the sentence doesn't make sense,
and I'm trying to provide a explanation of why that occurred.
wSpeedsSupported was originally put in only to future-proof against USB
3.0 speed increases. With that purpose, the description made sense.
Late in the spec development, the committee members had a discussion
about what we should do with the USB 2.0 "other speed" descriptor.
Originally, the spec authors thought that USB 3.0 devices should only be
able to work at HS when they were plugged into a USB 2.0 bus. The
"other speed" descriptor would report USB 3.0 in that case, and we would
issue an errata against the USB 2.0 spec to support that value.
However, device manufacturers wanted to be able to work at multiple USB
2.0 speeds, or even only support FS instead of HS. So late in the spec,
the bits to say which USB 2.0 speeds the device could work at were
hacked into the wSpeedsSupported field. That's why the bit descriptions
were changed, but the summary description doesn't make much sense.
> 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.
I wouldn't say it was a hastily-made spec. The spec development effort
was 2-3 years, and I came on board fairly late into it. But the
chapters were all written by different people from different companies,
so it's not surprising that there are inconsistencies. The USB-IF has
updated the spec several times, so you might want to download the latest
one and report the inconsistencies, either to me, or the official
feedback address.
Sarah Sharp
--
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
