It won't leak EDs on power management. The cleanup will just be deferred until power comes back on. Big deal.
Not on the D3cold resume path -- that can't be deferred.
I haven't looked at the PM paths yet, but if the D3cold path is via normal PCI exit paths, then it'll be fine with the module removal fix I'm testing.
It doesn't use those paths, no. FWIW I recently noticed that 2.5 is still broken enough on those paths that I've got to test that part of the "ohci-hcd" code on 2.4 ... part of why I submitted those recent patches to simplify that backport!
Either way, if the device is powered off, it's safe to cleanup the list earlier since the HC isn't gonna use it anymore.
The "usb-ohci" ED unlink/cleanup code is a bit convoluted, and has a bug that made such cleanup awkward/bugprone:
It's a race condition. It was very difficult to reproduce. One out of every 20 times and I could only reproduce it on some slower machines.
So it could very well be a different bug -- the 2.4 "usb-ohci" was making assumptions about interrupt latency that seemed most likely to break on "slower" machines. (Fixed in 2.5, folk have reported oopses now being gone.)
The problem is with other drivers which take a reference count.
Like say usbdevfs and sending a control message.
That sounds like a usbdevfs bug ... they aren't unknown, even/especially on disconnect() paths! :)
- Dave
------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
