> > > 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).
Absolutely right. And IMHO to a device driver that state is reached after
it returns from disconnect().
> > > 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.
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 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.
> > No it cannot, disconnect() has to wait for the unlink to complete.
> Why is that?
1. Module unload
2. Freeing of internal state in the HCDs
> Any new requests will result in an error anyway from the HC, so why
> duplicate the functionality and complicate the rest of the code?
It shouldn't need to. That functionality belongs into usbcore and needs
a careful redesign of locking in usbcore, if it is to be done.
> > 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?
Safely means that a kfree() is OK. HCDs should not be forced to keep
reference counts on their internal states, nor should they have to need
to deal with "shadow devices". That is a new device should not collide
with already removed devices regardless of how a HCD organises internal
state.
Regards
Oliver
-------------------------------------------------------
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
