On Thu, 2005-10-06 at 15:39 -0700, Steve Calfee wrote: > 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 > >
One last question on this thread for those that know the drivers and the hardware. What is the best explanation for the fact that the low quality cable works flawlessly with the uhci-hcd driver and the same hardware. Obviously the data transfers run at a slower rate, however the ehci_hcd driver won't even negotiate a connection. If you don't have the time to answer this don't bother, I am just curious. Thanks for your time. Jon ------------------------------------------------------- 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
