Gupta, Ajay Kumar wrote:
+ * the end; avoids starvation for other endpoints. + */ +static void musb_bulk_rx_nak_timeout(struct musb *musb, struct musb_hw_ep *ep) +{ + struct dma_channel *dma; + struct urb *urb; + void __iomem *mbase = musb->mregs; + void __iomem *epio = ep->regs; + struct musb_qh *cur_qh, *next_qh; + u16 rx_csr; + + musb_ep_select(mbase, ep->epnum); + dma = is_dma_capable() ? ep->rx_channel : NULL; + + /* clear nak timeout bit */ + rx_csr = musb_readw(epio, MUSB_RXCSR); + rx_csr |= MUSB_RXCSR_H_WZC_BITS; + rx_csr &= ~MUSB_RXCSR_DATAERROR; + musb_writew(epio, MUSB_RXCSR, rx_csr);
I don't think you want to clear the NAKTimeout bit without clearing ReqPkt as well since otherwise you're risking a race if the device decides to ACK the packet in the short window between this point and when you finally switch to another device...
Once we get NAK timeout limit there will not be any __IN token__ issued till the next QH is scheduled.
Only till you clear the NAKTimeout bit, of course.
So no question of clearing ReqPkt or any race condition.
Think again please.
+ + cur_qh = first_qh(&musb->in_bulk); + if (cur_qh) {
Is the opposite even possible? I *highly* doubt it given the fact that this gets called with non-NULL URB.
+ /* set rx_reinit and schedule the next qh */ + ep->rx_reinit = 1; + musb_start_urb(musb, 1, next_qh);
Note that the NAKTimeout bit will be cleared by musb_h_flush_rxfifo() called from musb_rx_reinit() a bit later anyway.
It doesn't. recheck.
Recheck yourself. It gets passed MUSB_RXCSR_CLRDATATOG which will effectively clear this bit.
WBR, Sergei -- 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
