On Friday 27 March 2009, Sergei Shtylyov wrote:
> > +static void musb_h_ep0_flush_fifo(struct musb_hw_ep *ep)
> > +{
> > + void __iomem *epio = ep->regs;
> > + u16 csr;
> > + int retries = 5;
> > +
> > + /* scrub any data left in the fifo */
> > + do {
> > + csr = musb_readw(epio, MUSB_TXCSR);
> > + if (!(csr & (MUSB_CSR0_TXPKTRDY | MUSB_CSR0_RXPKTRDY)))
> > + break;
>
> Note that the same rule applies ot other endpoints, i.e. you shouldn't
> flush FIFO if these bits are not set
Right ... but, this patch is just for ep0.
> and even if you do, you need to force
> TXPktRdy set. This needs to be fixed too...
... except that setting those bits, at least in this case, was
taking priority over flushing the fifo, causing the "flush" to
return with a packet left in the fifo. Kind of a "non-flush".
Yes, that seems like a hardware race just begging to happen.
At least, if MUSB_CSR0_H_REQPKT is set on entry. Such cases
would be pre-existing bugs. Suitable for a separate patch;
this fixes bugs I *observed* happening.
(You had asked about CamelCase? TXPktRdy, vs TXPKTRDY as
used in the driver, is one example.)
--
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
