This patch shortens the logic in xhci_endpoint_init() by moving common
calculations involving max_packet and max_burst outside the switch
statement, rather than repeating the same code in multiple
case-specific statements. It also replaces two usages of max_packet
which were clearly intended to be max_burst all along.
More importantly, it compensates for a common bug in high-speed bulk
endpoint descriptors. In many devices there is a bulk endpoint having
a wMaxPacketSize value smaller than 512, which is forbidden by the USB
spec. Some xHCI controllers can't handle this and refuse to accept
the endpoint. This patch changes the max_packet value to 512, which
allows the controller to use the endpoint properly.
In practice the bogus maxpacket size doesn't matter, because none of
the transfers sent via these endpoints are longer than the maxpacket
value anyway.
Hi Christopher,
I will not need a backport to a release prior to Saucy (I'm compiling and running the kernel 3.9.5).
I don't think the status should be changed to Invalid but to Fixed, as their is a specific fix in the kernel 3.9.5 for this issue.
Here is a copy/paste from the 3.9.5 log:
commit 3251317e8f0b705 ca4999e4f272eb1 3ec5dcd6c4
Author: Alan Stern <email address hidden>
Date: Wed May 8 11:18:05 2013 -0400
USB: xHCI: override bogus bulk wMaxPacketSize values
commit e4f47e3675e6f1f 40906b785b934ce 963e9f2eb3 upstream.
This patch shortens the logic in xhci_endpoint_ init() by moving common
calculations involving max_packet and max_burst outside the switch
statement, rather than repeating the same code in multiple
case-specific statements. It also replaces two usages of max_packet
which were clearly intended to be max_burst all along.
More importantly, it compensates for a common bug in high-speed bulk
endpoint descriptors. In many devices there is a bulk endpoint having
a wMaxPacketSize value smaller than 512, which is forbidden by the USB
spec. Some xHCI controllers can't handle this and refuse to accept
the endpoint. This patch changes the max_packet value to 512, which
allows the controller to use the endpoint properly.
In practice the bogus maxpacket size doesn't matter, because none of
the transfers sent via these endpoints are longer than the maxpacket
value anyway.
Signed-off-by: Alan Stern <email address hidden> and-tested- by: "Aurélien Leblond" <email address hidden>
Reported-
Signed-off-by: Greg Kroah-Hartman <email address hidden>