Hi,
On 06/29/2012 06:21 PM, Alan Stern wrote:
On Fri, 29 Jun 2012, Hans de Goede wrote:
As discussed in length on the mailinglist, USBDEVFS_URB_BULK_CONTINUATION
does not work as it should when combined with USBDEVFS_URB_SHORT_NOT_OK
(which is its intended use) on devices attached to an XHCI controller.
Note that this patch only does not advertise the cap, bulk transfers
with USBDEVFS_URB_BULK_CONTINUATION will still be accepted. Returning
-EINVAL for them would break existing apps, and in most cases the
troublesome scenario wrt USBDEVFS_URB_SHORT_NOT_OK urbs on XHCI controllers
will never get hit, so this would break working use cases.
The disadvantage of not returning -EINVAL is that cases were it is causing
real trouble may go undetected / the cause of the trouble may be unclear,
but this is the best we can do.
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3974,6 +3974,8 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
/* Accept arbitrarily long scatter-gather lists */
hcd->self.sg_tablesize = ~0;
+ /* XHCI controllers don't stop the ep queue on short tx :| */
+ hcd->self.no_stop_on_short_tx = 1;
The comment and the field name are a little misleading, for people who
always think "tx" is short for "transmit" or "transmission".
Right, note it is meant to mean transfer here.
Short
packets occur only for IN transfers, so if anything this should be
"no_stop_on_short_rx".
But maybe "no_stop_on_short_packet", or even "no_stop_on_short", would
be better since that's how we describe it everywhere else. For
instance, the URB flag is URB_SHORT_NOT_OK.
no_stop_on_short works for me, any other comments before I respin the
patch-set?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
