David:
I suspect that root-hub polling shouldn't be controlled by flags within
the hcd structure. The state transitions are under the control of the
driver, so it would be wrong to make the core responsible for following
those transitions and adjusting the polling to match. Instead we can add
some new core routines:
usb_hcd_enable_rh_polling(),
usb_hcd_disable_rh_polling(),
usb_hcd_disable_rh_polling_sync().
(The last is intended for when the HC is suspended and we need to be sure
no poll requests will arrive while the registers are inaccessible.)
To go along with this, the following HC states are appropriate for UHCI:
HCD_STATE_STOPPED,
HCD_STATE_RUNNING,
HCD_STATE_RH_SUSPENDED,
HCD_STATE_CORE_SUSPENDED,
HCD_STATE_HC_SUSPENDED,
HCD_STATE_DEAD.
Along with those states there needs to be an IN_TRANSIT modifier,
because controllers take some time to change their state (for instance, a
controller won't stop from a RUNNING state until the current transaction
has completed). There also needs to be a spinlock to protect the state.
Is this outline appropriate for other HCs as well as UHCI? Should it
replace the collection of states you have already set up in the hcd
structure? Or should it remain in the private uhci_hcd structure?
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://productguide.itmanagersjournal.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
