Hi!
>>>>> Yauheni Kaliuta writes:
> > > diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> > > index 0a50a35..830768f 100644
> > > --- a/drivers/usb/musb/musb_gadget.c
> > > +++ b/drivers/usb/musb/musb_gadget.c
> > > @@ -1524,6 +1524,7 @@ static void musb_gadget_fifo_flush(struct usb_ep *ep)
> > > csr = musb_readw(epio, MUSB_TXCSR);
> > > if (csr & MUSB_TXCSR_FIFONOTEMPTY) {
> > > csr |= MUSB_TXCSR_FLUSHFIFO | MUSB_TXCSR_P_WZC_BITS;
> > > + csr &= ~MUSB_TXCSR_TXPKTRDY;
> > CPU can't clear this bit according to the programming guide -- it can only
> > set the bit. So this should have no effect.
> Ok, the situation is that it reads it and set again, so let's say "the
> flush code should not set the flag".
BTW, as you might understood, I have observed the situation (unflushed
fifo) on a running system. The code was called and as soon as host resumes
IN polling, there are 2 512 bytes transfers (double buffering) without the
patch.
--
WBR, Yauheni Kaliuta
--
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
