On Tue, 19 Mar 2019 guido@xxxxxxxxxxxxxxxxxx wrote:
> Zitat von Guido Kiener <guido@xxxxxxxxxxxxxxxxxx>:
>
> > Restore the status of ep->stopped in function net2272_dequeue().
> >
> > When the given request is not found in the endpoint queue
> > the function returns -EINVAL without restoring the state of
> > ep->stopped. Thus the endpoint keeps blocked and does not transfer
> > any data anymore.
> >
> > This fix is only compile-tested, since we do not have a
> > corresponding hardware. An analogous fix was tested in the sibling
> > driver. See "usb: gadget: net2280: Fix net2280_dequeue()"
> >
> > Signed-off-by: Guido Kiener <guido.kiener@xxxxxxxxxxxxxxxxx>
> > ---
> > drivers/usb/gadget/udc/net2272.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/gadget/udc/net2272.c
> > b/drivers/usb/gadget/udc/net2272.c
> > index b77f3126580e..c2011cd7df8c 100644
> > --- a/drivers/usb/gadget/udc/net2272.c
> > +++ b/drivers/usb/gadget/udc/net2272.c
> > @@ -945,6 +945,7 @@ net2272_dequeue(struct usb_ep *_ep, struct
> > usb_request *_req)
> > break;
> > }
> > if (&req->req != _req) {
> > + ep->stopped = stopped;
> > spin_unlock_irqrestore(&ep->dev->lock, flags);
> > return -EINVAL;
> > }
> > --
> > 2.17.1
>
> Alan,
>
> do you want to add an acknowledgement for the sibling driver, too?
>
> Guido
Yes, okay. I can't test this patch either, but for what it's worth:
Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
Alan Stern
