On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote: > > > > Absolutely right. And IMHO to a device driver that state is reached after > > > it returns from disconnect(). > > > > I don't see why that is advantageous. > > > > It sounds like it would just complicate the code even more. > > How so, this is the current rule, isn't it?
I don't think it has ever been clearly stated either way. I had never intended for that rule to be made, but there's lots of drivers that do make sure that URBs don't exist past disconnect() anyway (to be pedantic and/or to ensure cleanup during module unload). I'm open for reasons as to why it could be a good rule. > > > The problem is the transition period. > > > 1. disconnect() > > > 2. driver does usb_submit_urb() nevertheless > > > 3. deallocate -> HCD drops all device state > > > 4. the URB from (2) completes -> BOOM > > > > > > If you reverse the order of (2) and (3) the HCD can return -ENODEV, > > > but you can't guarantee that at least on SMP. > > > To beat that we'd need an awful amount of refcounting and locking. > > > > The refcounting already occurs atleast in 2.4: > > It doesn't help. usb_inc_dev_use() can come to late. In fact, given > sufficient bad luck it can hang, if you depend on it in this way. How so? If the driver increments it at probe() time and decrements it when it's done, like say, when the application has closed the device, then it's still above 0? It sounds like a driver problem. I don't know of any drivers that do that, but I don't see any reason why they couldn't. > > > > The borderline case with PCMCIA host controllers is that the HC > > > > disappered, and as a result it should throw all of the existing pending > > > > URBs into error? > > > > > > Right. I haven't checked that code path yet. > > > > So, this is a situation where the HCD, or possibly the core, needs to track > > all of the URBs. > > Depends on what you want. You could call disconnect for all devices on the > bus, and just don't care for the URBs in flight. From a HCD viewpoint, this > is the simplest solution. Yeah, I think this will require some more thought to make sure it works correctly. But I think this is a different subject. JE ------------------------------------------------------- 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
