On Fri, Jun 27, 2003 at 11:46:33AM -0700, David Brownell wrote: > Greg KH wrote: > > >As for how to solve this? The module reference count will be > >incremented when the device is opened, right? Then on close, make sure > >all urbs are flushed out before finishing the close function. > >Unfortunatly, this seems to require keeping track of all pending urbs in > >flight, which is kind of the opposite for doing what the visor driver is > >doing... > > > >There was some proposals for how to fix this in the past on the mailing > >list, but I don't think they ever went very far. > > We now have lots of the necesary infrastructure, but backwards > compatibility (for drivers) has been preventing a final step. > > Specifically, drivers/usb/core/usb.c has usb_disconnect() trigger > the driver disconnect() call ... and only AFTER that returns (and > driver module might be rmmodded) will it disable() the endpoints. > > For correctly functioning USB device drivers, disable() just means > the HCD and HC handshake correctly. For malfunctioning drivers, > which violate the long-standing "driver disconnect() must unlink > all pending URBs" rule, disable() also forces still-pending URBs > to complete ... potentially after the driver has been rmmodded. > > It'd be simple, now that we have the endpoint disable capability, > to change the semantics of disconnect(). Just disable all the > endpoints BEFORE calling drivers' disconnect(): switch those > two short blocks of code in usb_disconnect(). > > That's the model I used in the gadget API, and it made the > interactions between the controller driver and the device > (gadget) driver a LOT simpler during disconnect/rmmod. > > IMO this change would be worth considering for 2.5 even at this > late date, even though it'd break some TBD number of drivers.
What would break? At the worse, drivers would just spit back a bunch of "warnings" about urbs that were not in flight attempting to be disconnected, right? > Because the upside of that change would be that on 2.5, USB > device driver disconnect() bugs would be less _able_ to break > things in usbcore or elsewhere in the system. And there are > a lot of driver disconnect() bugs that likely won't get fixed > without some fundamental change like that. I agree, I'd like to at least test this kind of change out, and hopefully add it. It is the "right" thing to do :) thanks, greg k-h ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
