On Wed, 20 Jun 2007, David Brownell wrote:
> > > + if (cc == TD_PIDCHECKFAIL || cc == TD_DEVNOTRESP) {
> > > + urbpriv = td->urb->hcpriv;
> > > +
> > > + td->ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
> > > + td->hwINFO &= ~cpu_to_hc32(ohci, TD_CC);
> > > + td->hwINFO &= ~cpu_to_hc32(ohci, TD_EC);
> > > + urb = td->urb;
> > > + for (count = 0; count < urbpriv->length; count++)
> > > {
> > > + td = urbpriv->td[count];
> > > + if (td) {
> > > + list_del(&td->td_list);
> > > + td_dma =
> > > + hc32_to_cpup(ohci,
> > > &td->hwNextTD);
> > > + }
> > > + }
> > > + list_del(&urbpriv->pending);
> > > + td_submit_urb(ohci, urb);
> >
> > My impression is that this would lead to an infinite loop when you try
> > to communicate with a non-responding device.
>
> Regardless, it's incorrect. The hardware is misbehaving, or else it
> would neither send packets with the wrong PID, nor stop responding
> entirely.
Is the misbehaving hardware the USB network device or is it the OHCI
host controller? Something like this might be an appropriate way to
recover if the host controller reports TD_PIDCHECKFAIL or TD_DEVNOTRESP
when it gets valid packets.
But if the controller is okay and the device is at fault then I agree
with David. Workarounds should exist at higher levels, not be added
here.
Alan Stern
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
