[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb-devel
Subject:    [linux-usb-devel] More about USB PM
From:       Alan Stern <stern () rowland ! harvard ! edu>
Date:       2003-08-29 20:26:46
[Download RAW message or body]

David:

Ownership of hcd->state is unclear.  In hcd-pci.c, I see the following:

	usb_hcd_pci_probe() calls driver->reset() but doesn't set
hcd->state.  It later calls driver->start() but still doesn't set
hcd->state.

	usb_hcd_pci_remove() sets hcd->state to QUIESCING -- even if it
was previously equal to HALT(!) -- and calls driver->stop().  Lastly it
sets hcd->state to HALT.

	usb_hcd_pci_suspend() checks that hcd->state isn't already
SUSPENDED or HALT.  If not, it calls driver->suspend() and then sets
hcd->state to SUSPENDED.

	usb_hcd_pci_resume() checks that hcd->state is SUSPENDED, sets
hcd->state to RESUMING, calls driver->resume(), and then checks that 
hcd->state is either RUNNING or READY.

So who is responsible for setting hcd->state?  Sometimes the glue layer
does it and sometimes it doesn't.  To work properly, the driver's start()
and resume() methods have to set it to RUNNING, the reset() method should
set it to HALT, and the suspend(), and stop() methods don't have to set it
at all.

Also, what does USB_STATE_READY mean?  It doesn't appear anywhere in the 
code AFAICT, only in hcd.h.

And why doesn't pci_suspend() set hcd->state to QUIESCING during the time 
that driver->suspend() is underway?

Alan Stern



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic