On Thursday 23 July 2009, Alan Stern wrote:
> BTW, qh_link_async does an apparently unnecessary check that
> qh->qh_state == QH_STATE_IDLE. Is there any reason for this? It would
> be a bug if the state weren't IDLE.
/* clear halt and/or toggle; and maybe recover from silicon quirk */
if (qh->qh_state == QH_STATE_IDLE)
qh_refresh (ehci, qh);
I don't recall just now. Probably it's left over from
early paranoia.
ISTR it took a while to iron out the QH handling in that
driver, so there may be a few such things left:
- early NEC silicon was solid but a bit slow (so it
never triggered races) and had that "silicon quirk";
which subtly affected QH handling;
- early VIA silicon was deeply buggy but fast ("is this
yet another silicon bug, or is the driver wrong?");
- ISTR that until Philips sent me one of their eval boards
(thank you to that now-NXP group in Hong Kong!) I had a
very hard time reproducing (then fixing) some races; it
reproduced many problems nicely, without HW bugs.
Nowadays the EHCI hardware is a lot better to work with,
and SMP systems are getting to be the norm. :)
- Dave
--
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
