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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
