Alan Stern wrote:
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).
I think you're missing the point. A "suspend this port" call
needs a port to suspend, and a hub the port is attached to.
We need that kind of primitive, and its sibling to resume.
I don't see any benefit to what you're suggesting. There's
an "if/else" that's got to go someplace, and putting it in
the way it's now done is just fitting into the framework of
all the other hub operations that manipulate ports.
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
By that reasoning, hub_port_suspend() belongs to *the topmost level
that actually deals with a port* ... which it does!
than interfaces. Furthermore __usb_suspend_device() really belongs to the
lower level, since most of its code concerns notifying interfaces' device
That's the "top" level (other than get-the-lock) since it's what
makes all devices suspend the same: interfaces first, then whatever
hardware is controlling the device (parent hub, or hc itself).
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().
No, by my argument it's appropriate right now ... since there's no
way that hub_port_suspend() should deal with something that doesn't
have a port!
It might be appropriate to change the name of the routine, though, to
something like hub_device_suspend().
Well, since it suspends a _port_ not a device, I don't see any issue
with the naming!! It doesn't only suspend hubs; and suspending a
port doesn't necessarily suspend just one device either.
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.
That's my understanding, right.
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?
Well, what's the difference? Loss of VAUX power, as I recall.
Does UHCI specify what VAUX protects? I don't remember it doing
anything like that. But if the chip looks like it does in
power-up reset, then that's likely what happened.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
