On Mon, 25 Jun 2012, Sarah Sharp wrote:
> > 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.
(The same is true for all USB-2 hubs, not just rate-matching root
hubs. Furthermore, it was never possible to use the bus to
differentiate between full speed and low speed.)
The speed is also given in /sys/kernel/debug/usb/devices, if your
kernel has CONFIG_USB_DEBUG enabled. For most purposes I find that
file easier to use than lsusb output, because it's more concise.
> 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.
Ah, now I get it. A typical example of inadequate editing.
Unfortunately this sort of thing happens all the time...
> 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.
I'll plan to do it during my copious free time. :-)
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
