but the hcd drivers should have already canceled them, right? Hm, but
Nope, the only way an hcd can know the device is gone is by
calling the misnamed bus->op->deallocate() routine. And
because of the mess stemming from that misnaming, that code
path doesn't even try to do that any more.
Huh? Due to a change I just made? I don't see that. It seems to be
You didn't change that, right -- that's what I was saying.
that way for a while. And Johannes just stated that uhci doesn't even
implement disconnect() so there's gotta be some way it determines that a
device isn't there anymore. Or it probably just doesn't care anymore,
which seems to be a valid thing to do.
Having looked at the history of that misnamed API:
- Originally provided in 2.2.10 or so, I think OHCI was the only
user. It was misnamed at that time, given that it was used
only to handshake "device is gone".
- Sometime in the 2.3 series, someone made a change to make the
usage in usbcore match that misnaming: just free memory. But
whoever that was did not change that single implementation of
the method (ohci) to match the changed semantics.
- So that 2.3.x change created a bug where none existed before.
It would only appear with OHCI *and* with a device driver that
was buggy and didn't disconnect() or refcount correctly.
Of course the APIs were in such flux that long ago that it's very
understandable how a misnamed API would cause that kind of trouble.
Particularly in areas like this, where different HC hardware (or
at least their drivers) has different expectations.
UHCI doesn't care since there is no per device state that is tracked.
The other HCDs do have some per device state and use the functionality.
Think of UHCI as the exception.
The deallocate() callback is exactly what is needed. When all of the
references are gone, let the HCD free any private state for that device.
The deallocate() callback only did "exactly what is needed" for a
short while before that 2.3.x semantics change ... but that change
rather signifcantly broke the only real user of that API.
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.
Ignore the URB unlink problem ... think instead about QH unlinking.
I know that for UHCI, URB == QH. (Not that it needs to be, but
that's certainly a workable implementation approach.) But for the
other controllers, even after every URB for a device is unlinked,
one or more QHs can still be linked ... since the QHs are there
for endpoints, not for URBs. Even after every URB is unlinked,
the QH may still be in use by the hardware.
So it's natural, coming from a UHCI perspective, to think that the
only issue is making sure the URBs are unlinked. Not so, and that
misnamed deallocate() routine was solving a different problem from
the very beginning.
I'm still thinking through the urb module reference count stuff, and am
not entirely convinced that things are currently safe without it, but
other things have been distracting me...
The URB reference counting may not be necessary. There's only 2 possible
pieces of code that can use it: the driver and the HCD.
As long as the rules about who owns the URB when and where are clearly
defined (and implemented), then reference counting may not be necessary.
That's pretty much where I'm coming from, FWIW. Not that it hurts
to have a refcount, just minor overhead; and it can certainly help
guard agains some classes of error. But "not necessary".
- Dave
-------------------------------------------------------
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
