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. > 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. Alan Stern
