Anyhow, I have been wondering since about Sunday whether it's really safe to write HcControlHeadED (and HcBulkHeadED) with 0. The register description itself is ambiguous. Now I'm finding that Figure 6-5 "List Service Flow" and Section 6.4.2.2 "Locating Endpoint Descriptors" are outright contradictory!
OHCI isn't as tightly specified as one might like. There are also differences in how vendors implemented it (notably initialization); but at least there don't seem to be major incompatibilities that crept in between implementations.
So, if the HC behaves as described in the text, then there is an obvious race: .... So I changed ohci-q.c ... to this:
if (ed->ed_prev == NULL) { if (!ed->hwNextED) { ohci->hc_control &= ~OHCI_CTRL_CLE; writel (ohci->hc_control, &ohci->regs->control); } else
(added the ELSE)
writel (le32_to_cpup (&ed->hwNextED), &ohci->regs->ed_controlhead); } else ...
and now there are no more crashes when plugging in the BTC keyboard.
Interesting. I had those "else"s in the patch I was testing too, and they were literally the last "is this really needed?" change I removed before posting that patch yesterday. I had tested it on four different implementations of OHCI (two on SMP) and the "else" didn't make a difference ... as it might not, given the race you identified. This is a good example of something better found with a fresh set of eyes looking at spec and code!
Looks like that's really needed then! Whose OHCI silicon are you testing with, by the way? Good catch, regardless.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
