On 24.12.2019 17.28, Alan Stern wrote:
On Mon, 23 Dec 2019, Mathias Nyman wrote:
The Maximum Packet Size of the full-speed bulk endpoint looks a bit suspicious (maxp 4)
12478.521580: xhci_add_endpoint: State disabled mult 1 max P. Streams 0 interval 125 us max ESIT payload 0 CErr 3 Type Bulk OUT burst 0 maxp 4 deq 00000000fff71001
For full speed bulk endpoints only support 8, 16, 32 and 64 bytes Max Packet sizes.
Host are not required to support other values. See USB2 spec section 5.8.3 for details
Maybe forcing it to one of the allowed values could work.
Does the below hack help? (untested)?
Is this the sort of thing we should handle in
config.c:usb_parse_endpoint()?
Even though 4 is not a valid maxpacket size for full-speed bulk
endpoints, many host controllers and hubs will handle it okay. Much
the same is true for devices that have a high-speed bulk endpoint with
maxpacket set to 1024. Should we try to treat these two errors the
same way?
Makes sense.
Looks like config.c:usb_parse_endpoint() shows a warning if maxpacket size is incorrect for
high-speed bulk endpoints, but leaves the maxpacket size unchanged.
If xhci is used then the xhci driver will later force the maxpacket to 512
I'm all for both checking and forcing maxpacket sizes in usb_parse_endpoint(), but
is there a risk that we break some devices that used to work. For example full-speed
bulk devices with maxpacket 4 that work fine under EHCI, but device can't handle
a new maxpacket size set to 8?
Or should we only warn in config.c if the maxpacket sizes are not according to specifications,
and leave it to the host controller drivers to force new maxpacket values?
-Mathias
