On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote: > > > > No, some of the hcds die a horrible death if you try to call unlink on a > > > urb after the device is gone :( > > > > They shouldn't. It should be perfectly valid to do that. > > > > Actually, it seems to me that that unlinking after disconnect would need > > to be a requirement for random disconnects to work. > > After physical disconnect, or logical disconnect?
Physical. I consider logical disconnect when the last reference to the device structure is put (ie it hits 0 and calls ops->deallocate()) After that, the device structure doesn't exist anymore and it's not safe to do anything (obviously). > > I actually don't have a problem with submitting a request for a device > > that's gone. It'll timeout. Big deal. > > Provided that the HCD doesn't keep state for devices. I don't see why that's a problem. It should be linked to the reference count on the device. > > Because it's superfluous. > > > > The HCDs shouldn't be unlinking any URBs (I don't know if that was > > brought up, but has been brought up in the past). The driver that > > submitted the URB should be the only code that unlinks them. > > Right. If an HCD can't deliver an URB it should return an error, not > an unlink. The only borderline case are PCMCIA host controllers. > But it's more a question of definitions than a real problem. 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? > > > > >then we don't know when the callback would have happened to be able to > > > > >unload the driver safely... > > > > > > > > I don't see why that would matter in that routine; > > > > that seems like a different discussion. > > > > > > No, you're saying that if a driver's disconnect() function has > > > completed, it is now safe to unload, right? Well if the hcd driver > > > hasn't cancelled the urb on device disconnect, then the callback can > > > still happen, in the driver module. Which could have just been > > > unloaded, oops :) > > No it cannot, disconnect() has to wait for the unlink to complete. Why is that? > > disconnect() and module unload are really different paths. > > > > As far as I'm concerned, there are no requirements for the module to be > > done with a device after disconnect() is called. The reference counting > > handles all of the correctness for that. > > What could a module do with a disconnected device? It can't do anything, but it simplifies the code significantly. You don't have to check if the device exists or not all of the time. Any new requests will result in an error anyway from the HC, so why duplicate the functionality and complicate the rest of the code? > Besides, if HCDs keep per device states, they must have a time they > can safely deallocate this information. Could you clarify what you mean by safely? 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
