> It's entirely possible that the stall packets are created by the hub.
> When a full-speed device is connected to a USB-2 hub, and the device
> fails to respond to a packet sent by the host, the hub reports this
> failure as a stall.

Here I don’t think device fails to respond to a packet sent by the
host. I verified this by connecting Ellisys USB analyser in between
host and devices.

For example Look at the attached(Sample_HciEvt.png) HCI event captured
by Ellisys USB analyser. It is a valid HCI event from device to Host.
IN transaction 96 1 ACK FS 16 bytes (FF 2F C2 01 00 17 00 DF 00 01 10
00 00 A9 EE 0F)
IN transaction 96 1 ACK FS 16 bytes (00 00 00 5A 06 9D 39 00 00 66 00
00 00 00 00 00)
IN transaction 96 1 ACK FS 16 bytes (00 00 00 00 00 00 00 00 00 00 00
8E 05 28 00 01)
IN transaction 96 1 ACK FS 1 byte (00)

Due to spurious stall packets , sometimes btusb driver is not
receiving this full event , instead it got STALL packet instead of
first 16 bytes plus rest of other 33 bytes.



> When the device is connected to an OHCI controller, such failures would
> be reported in a different way, such as a -EPROTO or -EILSEQ status.
>

I did not observed -EPROTO or -EILSEQ status in OHCI controller scenario.

Thanks,
Naveen