Dave:
Going back to the questions about hcd->state... Let's consider just how
it's used in hcd.c. Slightly rearranged from what I said before, these
uses include:
1. Tested during URB submission for a device on the bus.
2. Tested during root-hub control URB submission.
3. Tested during root-hub status polling.
4. Tested in get_frame_number.
5. Tested before IRQ forwarding.
6. Tested after IRQ handling to see if the HC has died.
7. Used for warning about unlink while the HC isn't running.
8. Used for warning about endpoint-disable while the HC isn't
running.
As far as usbcore is concerned, the states an HC can be in are:
a. Running normally.
b. Root hub suspended.
c. Root hub and HC both suspended.
d. Died.
e. Gone (i.e., after usb_deregister_bus).
For the most part, the tests are intended to prevent actions from taking
place when the HC is not in an appropriate state. The big problem is that
the state transitions are not synchronized in any way with the tests.
This isn't surprising, since only the HCD is in a position to do such
synchronization.
States a and b don't require any special action at all. Eveything is
legal in those states.
For the most part states d and e shouldn't be too troublesome either.
All devices below the root hub will have been disconnected (the root too,
for e). Assuming drivers are careful not to use a device after being
unbound from it, we only need to worry about the small window between the
time the controller dies and the time the devices are disconnected. But
notice that no matter what we do, we can't handle the even smaller window
between the time the controller dies and the time hcd->state is set to
HC_STATE_HALT. So tests 1-4 don't do much for d and e. Of course 5 is
useful for d, even without precise synchronization.
We should consider d-6: detecting that the HC has died. I'm not so sure
that we're doing it the best way. First, an HCD might decide that the HC
is dead when a watchdog timer fires, not when an interrupt is received.
Second, it should be just about as easy for an HCD to call usb_hc_died
directly as to set hcd->state. So action 6 could be eliminated.
So the whole thing boils down to state c. While the HC is suspended is
when we really want to avoid trying to access the controller. However
lack of synchronization means that we aren't really doing this correctly
now. Either we need to find a way of preventing 1-4 precisely while the
HC is suspended or we might as well give up and just rely on the HCDs to
do the necessary synchronizing. Whatever this way is, it will have to
involve the HCDs somehow because the suspend/resume callbacks for non-PCI
HC devices don't pass through usbcore.
My conclusion is that on the whole, hcd->state can be eliminated from
hcd.c. The exceptions are:
hcd->state, or something like it, will be useful to prevent IRQ
forwarding at times when we know the HC isn't active.
Those two warnings (7 and 8) seem to need it. But do we need
the warnings? I don't think I've ever seen them triggered.
Blocking calls to the HCD while the HC is suspended is the
single major stumbling block. It should be done properly
(which hcd->state can't do) or not at all.
Comments?
Alan Stern
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
