On Sat, 5 Feb 2005, David Brownell wrote:
> > > +#ifdef CONFIG_PM
> > > +
> > > +static int usbnet_suspend (struct usb_interface *intf, u32 state)
> > > +{
> Right now usb_driver::suspend() expects a u32 state, so that's correct.
>
> Though there was some patch that claimed to fix usbcore for those new
> typedefs; it seems to have been at best incomplete, having missed the
> main paths where a "pm_message_t" would be right. Were there other
> USB patches yet to merge in this area?
Pavel has been slinging patches around like crazy! Without checking
closely, I got the impression that the USB parts hit most but not quite
all of the places where a pm_message_t could be passed.
> Actually I kind of regret passing the "state" value down there anyway,
> its pretty useless since there's only one USB suspend state (unlike PCI).
>
> The rationale was that one state traditionally indicates suspend, and
> a different one traditionally indicates poweroff ... but for USB, it
> makes more sense to use disconnect() on poweroff and not complicate
> suspend processing unnecessarily.
That rationale is now officially superseded. The new rationale is that
the SUSPEND message indicates the device should either go to or prepare
for a low-power mode, while the FREEZE message indicates the device should
be quiesced but need not change power levels. For USB devices other than
root hubs there's no difference between the two.
At some point I will suggeste adding another type of message: SELECTIVE,
to indicate that the device should do a selective suspend. This implies
going to a low-power mode but possibly also enabling resume-request
interrupts, which are essential for autosuspend/autoresume. (By contrast,
the FREEZE and SUSPEND messages indicate that all interrupts must be
disabled.)
The difference between SELECTIVE and the other messages will be essential
HCDs when suspending a root hub. So the pm_message_t does need to be
passed.
> And hmm, there's no pm_message_t for "power off". I'm not sure where
> the knowledge gets discarded: that the host controller will enter a
> suspend state where the root hub won't provide any suspend current.
That distinction isn't really present in the PM core. All it knows is
that the system is going to a low- or no-power state (the various flags in
pm_message_t contain more detailed information). It's not the PM core's
job to know, for example, whether the motherboard can supply suspend
current to a built-in EHCI controller. Basically the HCDs should assume
that suspend current is available. If it isn't that fact will become
apparent after the system resume, because all the attached ports will be
disabled and hence unable to resume.
This means there's no need ever to turn off current to a USB device during
suspend. If suspend current isn't available to the HC it doesn't matter
what you do; and if current is available you may as well use it.
> The original problem there was that the PM core code has nasty driver
> model interactions, like self-deadlock if devices were removed during
> suspend or resume processing. (Part of that should be fixed now.)
> Which is why usbcore will now (with CONFIG_USB_SUSPEND) warn that
> "resume is unsafe!".
Devices aren't supposed to be removed during suspend or resume processing.
If they need to be, port changes should be queued for the hub driver. It
will process them when it gets out the refrigerator, _after_ the resume.
> So ... I'm not sure what a "follow-on" patch should do!
>
> Comments, anyone?
Just make it consistent with all the other patches Pavel has been sending
out.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
