At 01:51 PM 10/4/2005 -0400, Alan Stern wrote:
On Tue, 4 Oct 2005, Jon Nettleton wrote:
> > Unloading the
>> > ehci_hcd with this cable and just using uhci_hcd produced a
functioning
> >> device. Using a USB 2.0 cable with the ehci_hcd driver also produced
a
> > functioning device. > > > > It is my understanding that the 1.1
cable should cause the driver to
> > fallback to the 1.1 protocol.
> > No. Using a bad cable should cause the connection to fail, as you
saw.
Why is a low speed cable considered bad, when it is just not high speed?
There are physical differences between the two types of cable, most notably
in the amount of shielding that protects the data lines from noise.
High-speed signals really need that extra shielding; being so quick, they
are easily perturbed by even small amounts of noise and distortion.
In terms of cables there is only one USB cable. (ignoring mini connectors
and OTG issues for now). There is a USB.org legal cable spec for low speed,
but one end must be "captured" in a low speed device. This means that a low
speed cable can only be used with that one low speed device. Think USB mouse
or keyboard for instance where they have a usb cable coming out of their
device. The low speed cable allows very low cost devices.
However, there are low quality cables, just as there are low quality
operating systems :) Cables and hardware can and do fail.
Is there a functionality reason not to try to force the hub port down to
usb 1.1 and try to connect that way? This is honest question I am not
trying to start a flame war on the subject. :-)
In principle this is possible. Linux doesn't do it, though. And in any
case, full speed and high speed both require the same kind of shielded
cable -- it's only low speed that can get away with less shielding.
Forcing the connection to low speed is not possible.
If enough people clamor for a fall-back-to-full-speed feature, maybe
someone will implement it. However I suspect that it won't really be
popular. People expect their high-speed devices to run at high speed and
won't be happy if they don't.
If you have a low quality cable, it is possible the high speed chirping will
not work, so it will fall back to full speed anyway. Flakiness in a
communications connection is always a problem. The big problem with
downshifting to full speed is trying to determine when is the appropriate
time. And the speed is determined during the device reset, so to downshift
would require resetting the device. And then somehow convincing the EHCI
controller to ignore the chirp, and use a companion for a full speed device.
This could be a major source of unintended consequences.
From the USB 2.0 spec:
6.4 Cable Assembly
This specification describes three USB cable assemblies: standard detachable
cable, high-/full-speed
captive cable, and low-speed captive cable.
A standard detachable cable is a high-/full-speed cable that is terminated
on one end with a Series “A” plug
and terminated on the opposite end with a series “B” plug. A
high-/full-speed captive cable is terminated
on one end with a Series “A” plug and has a vendor-specific
connect means (hardwired or custom
detachable) on the opposite end for the high-/full-speed peripheral. The
low-speed captive cable is
terminated on one end with a Series “A” plug and has a
vendor-specific connect means (hardwired or
custom detachable) on the opposite end for the low-speed peripheral. Any
other cable assemblies are
prohibited.
The spec also forbids extension cables, and I have two devices that came
with them. Protocols are rules. People violate rules. Expecting an OS to get
around violations can be a never ending game.
Regards ~Steve
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
