On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > Will someone at least prevent the device management calls > > > from being called in_interrupt() though? That is _guaranteed_ > > > to oops with driver bugs. Even Johannes admitted that he's > > > broken the EHCI and OHCI drivers. > > > > > > The simple fix is to move the call to > > > > > > dev->bus->deallocate(dev) > > > > > > from the memory management stuff (usb_free_dev) to the > > > device management, at the very end of usb_disconnect(). > > > Then dev->bus should be nulled. > > > > Could you explain to me the difference between memory management and > > device management in the example of usb-ohci? > > Look at "ohci-hcd" instead. And you might have different > terms you'd prefer ... looking specifically at the disconnect > paths: > > "Memory Management" is what you're doing with refcounting. > (This style is often called "poor man's garbage collection".) > > -> struct usb_device memory ... kfree() when last known > pointer goes away. > > "Device Management" is where state associated with the > device's current configuration needs get cleaned up. The > stuff coupled to the "real hardware" which just went away. > > -> EDs for that device that are still linked ... need to > block in the driver until we know the HC isn't using > these EDS any longer > > -> any TDs on such EDs (reflecting driver bugs FWIW, > they should all have been unlinked already) must be > scrubbed out. > > -> then free that ED/TD memory once the HC is known > not to be using it any more. > > It's much the same for EHCI: any QH still linked has got > to get unlinked before the kernel state for the device is > really and truly gone. (And before its device address > can be reused on that bus, FWIW ... not that anyone is > likely to disable the round-robin addressing lately.) > > Yes, your "uhci" code tracks such state differently.
You're targeting your code for the wrong system. You should be coding assuming a working system. You shouldn't be assuming a buggy system. When you remove all of that extra code, it appears to reduce down to a single pci_pool_free call. Is that correct? JE _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
