On 2.1.2020 17.31, Alan Stern wrote:
On Thu, 2 Jan 2020, Mathias Nyman wrote:
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
Does the driver do this because otherwise the controller will refuse to
handle the endpoint?
There are indeed high-speed devices that have a bulk endpoint with
maxpacket set to 1024; I have used some. They work okay with EHCI
because the driver and the controller will accept the invalid value.
But probably they won't work with xHCI.
Looks like high-speed bulk endpoint maxpacket was forced to 512 to handle cases where
wMaxPacketSize was smaller than 512. Some xHC controllers apparently couldn't handle that.
This is done in a patch from 2013:
e4f47e3675e6 USB: xHCI: override bogus bulk wMaxPacketSize values
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?
I haven't run across that combination before, so I don't know. Maybe
the reason it worked okay until now is because those devices never need
to perform a bulk transfer containing more than 4 bytes?
In any case, making this sort of change would definitely break the
1024-byte maxpacket devices mentioned above.
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?
I think that would be a lot safer.
Ok, lets go with that
-Mathias
