Hi, Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> writes: >>>>> 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. yeah, that's part of the USB spec. High-speed bulk endpoints must have wMaxPacketSize of 512. Similarly for Super-speed, it must be 1024. -- balbi
Attachment:
signature.asc
Description: PGP signature
