John, Doug, or anyone else:
I've got a Raspberry Pi 2B and I'm trying to use it with a compound
device. The device has a High-Speed hub with a Full-Speed function
permanently attached to port 4.
The RPi detects the function but fails to initialize it. My bus
analyzer shows the reason why: A Start Split packet sent to the
device's internal hub for delivery to the FS function contained these
bytes:
78 44 01 c0
0x78 is the SPLIT packet ID. 0x44 is the hub's bus address, with a 0
in the high-order bit to indicate a Start Split. 0x01 is supposed to
be the port number in the hub (with a 0 in the high-order bit to
indicate the target device is Full Speed). The final 0xc0 is the CRC
with a few extra uninteresting bits.
The problem here is the third byte. It is set to 0x01 even though the
port number is 4. As a result, the packet never gets delivered and the
host controller is unable to communicate with the target function.
(By contrast, when the same device was attached to a laptop PC instead
of the RPi, the bus analyzer showed the SPLIT packet contained 78 06
04 60, as one would expect.)
Now oddly enough, when I ran a similar test on the RPi using a
Low-Speed target device, it worked perfectly. In this case the device
was attached to port 5 of the HS hub, and the third byte of the SPLIT
packet was 0x85 (high-order bit is on to indicate Low Speed).
Is this a bug in the Pi's host controller hardware? Or a bug in the
dwc_otg driver? The kernel I tested was current Raspbian, 4.1.15-v7+.
Is this a known problem? Is there any reasonable way to fix it?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
