Here is patch #3. It also Works For Me. I was wondering whether it
I've had several "Works For Me" patches too, but then if the silicion got kicked a bit differently it'd not behave... :(
it is really safe to mess with the OHCI control registers the way ed_deschedule() does at a time the OHCI is running. To test this
It must be, or we'd not have had a driver working for several years now!
The quick stop/restart cycles haven't seemed to be a problem with any OHCI silicion in the way they are with, for example, VIA EHCI.
theory, I delayed the ed_deschedule() handling to finish_unlinks(), as shown in the patch below. I don't know whether this is really safe as far as the host's lists are concerned, but it does avoid the crashes.
My suspicions have been focussing on finish_unlinks().
That's really the only place the HCD does anything that could corrupt the ED queues, which is what looks to be happening.
Your change doesn't actually _unlink_ in the same way; interesting change, I'll have to think about it. It certainly changes timings.
What's the argument as to why it's safe to update the OHCI control registers in ed_deschedule() at the time start_ed_unlink() is running?
It's always safe to update those registers, except that some silicon doesn't support that while the controller is suspended.
- 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
