Re: ERROR: unexpected command completion code 0x11 for DJ-Tech CTRL (resending as plain text ;)

[Felipe Balbi <balbi@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]


Hi,

Mathias Nyman <mathias.nyman@linux.intel.com> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]