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