On Thu, 3 Jun 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > You could move the root hub vs. normal device distinction from
> > __usb_suspend_device() down into hub_port_suspend(). Then root hubs would
> > be suspended just like other devices, so they could be resumed the same
> > way too.
>
> The hub to which the root hub is attached, and through a port on
> which it'd be suspended, is ... what? :)
When asked to suspend a root hub, who cares what the port number is? The
number won't get used because there is no parent port. You simply have to
pass the device itself as an additional argument (or in place of the
parent hub device argument).
> The root hub is a special kind of device, and that special nature
> shows up in the top level usb_{suspend,resume}_device() logic in
> much the same way. The rest of the suspend/resume logic doesn't
> need to know or care, and shouldn't -- it deals with interfaces,
> not devices.
By that reasoning hub_port_suspend() belongs to the top level, not the
lower level part of the suspend logic, since it deals with devices rather
than interfaces. Furthermore __usb_suspend_device() really belongs to the
lower level, since most of its code concerns notifying interfaces' device
drivers. So by your own argument the distinction between root hubs and
other devices should be made in hub_port_suspend, not
__usb_suspend_device().
It might be appropriate to change the name of the routine, though, to
something like hub_device_suspend().
> > What happens is PME# causes the power management routines to issue the PCI
> > resume() driver call. Then the controller, now in D0, issues its
> > resume-detected IRQ and the driver must handle that. The driver resumes
> > the root hub. What will resume all the devices beneath? Will the PCI/bus
> > glue code take care of it as part of the PCI resume?
>
> Near as I noticed, the only times Linux takes care of the PM
> parent/child trees are (a) during system suspend/resume, or
> (b) when the CONFIG_USB_SUSPEND patch suspends a hub.
> Not as good as it should eventually be.
In other words, this won't be fixed until the PM subsystem gets into
better shape. Okay.
> > How will the HCD know whether it is resuming from D3hot vs. D3cold? In
> > one case a USB global bus reset isn't needed, in the other it is.
>
> OHCI sees D3cold by having the controller be in RESET state on resume,
> instead of SUSPEND (or RESUME/wakeup). Which was a messy case that
> deadlocked 2.6.5 and earlier kernels inside the PM code, because it
> thinks devices can't disappear on resume.
I don't think that approach will work with UHCI. Isn't there any standard
way to tell, when you wake up, whether you were in D3hot vs. D3cold?
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
