On Fri, Mar 6, 2015 at 7:08 PM, Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx> wrote: > Hello. > > On 03/06/2015 06:14 PM, Mathias Nyman wrote: > >> From: Aleksander Morgado <aleksander@xxxxxxxxxxxxx> > > >> When a control transfer has a short data stage, the xHCI controller >> generates >> two transfer events: a COMP_SHORT_TX event that specifies the >> untransferred >> amount, and a COMP_SUCCESS event. But when the data stage is not short, >> only the >> COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length >> to >> urb->transfer_buffer_length while processing the COMP_SUCCESS event, >> unless >> urb->actual_length was set already by a previous COMP_SHORT_TX event. > > >> The driver checks this by seeing whether urb->actual_length == 0, but this >> alone >> is the wrong test, as it is entirely possible for a short transfer to have >> an >> urb->actual_length = 0. > > >> This patch changes the xhci driver to rely on a new td->urb_length_set >> flag, >> which is set to true when a COMP_SHORT_TX event is received and the URB >> length >> updated at that stage. > > >> This fixes a bug which affected the HSO plugin, which relies on URBs with >> urb->actual_length == 0 to halt re-submitting the RX URB in the control >> endpoint. > > >> Cc: <stable@xxxxxxxxxxxxxxx> >> Signed-off-by: Aleksander Morgado <aleksander@xxxxxxxxxxxxx> >> Signed-off-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> > > > [...] > >> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h >> index 3b97f05..d066393 100644 >> --- a/drivers/usb/host/xhci.h >> +++ b/drivers/usb/host/xhci.h >> @@ -1,3 +1,4 @@ >> + >> /* >> * xHCI host controller driver >> * > > > Hm, I thought you've dropped this new line... > Ouch; sorry for that. How do I fix that now? Submit another patch just removing it? Or resubmit a v6 of the patch? I think Greg already cherry-picked it to his branch. -- Aleksander https://aleksander.es -- 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
