Greg KH wrote:
Hm, maybe we should mark the device gone at the beginning of this call,
or right at the time we realize it's gone in the hub driver.  That would
keep drivers from submitting urbs from within their disconnect
functions.  But it would also prevent them from canceling them...  Ah,
Only because you put that check in the unlink path ... I think it'd
be better to mark earlier, and allow cleanup at any time (not check).

In the gadget code I posted, I've made a point of making sure that
when the host goes away, or an endpoint gets disabled, the cleanup
paths continue to work ... only methods like enabling endpoints or
submitting requests get blocked.  So things start to quiesce right
away, and shutdown is guaranteed to work in one pass, there's no
need to patch it up later.

No reason the host side can't use the same approach.


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.

We'd need a new bus->op hook to let them do that.  I think
that'd be a good thing to do at some point ... and it'd be
practical to have "hcd.c" handle the logic, without touching
any of the hardware-specific code (ehci, ohci, uhci).


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.


Nah, I think it's good where it is, if a driver is trying to do
something when disconnect happens on it, the hcd can handle any problems
if the present flag isn't set exactly when disconnect is happening, as
it has to be able to do that right now, correct?
It's always been messy there, and rather than requiring the HCDs to do
more work, I'd much rather see them do less ... by guaranteeing that
those more exotic cases will never appear.

- 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

Reply via email to