On Thu, 1 Mar 2007, Oliver Neukum wrote:
> Down an interface and it stays down. Suspend an interface and it ...
... and it stays suspended until the kernel tries to send a packet out
through that interface or until a packet is received (assuming proper
hardware wakeup support is available and enabled). That's pretty much
exactly how I'd want my interface to behave if I was trying to save power.
> Why?
If you down an interface and _then_ suspend it -- if the driver were
smart, it would do an autosuspend shortly after the interface went down
and you woldn't have to do anything special -- the interface will remain
suspended until you actively try to do something with it, like run
ifconfig again.
The Moral: Suspend is different from ifconfig down.
> > I can't think of any way to express the idea of "a specific purpose" in a
> > form the kernel can understand. However the user could always disable
> > autosuspend; that also should force an immediate resume and it wouldn't
>
> Yes, only waking up, as opposed to wake up and keep woken up,
> is useless from user space.
I guess you're right. Given that we wake on demand anyway, there's not
much point to waking up for no reason. It might be useful for testing,
but not for doing real work.
> > > > Open question: Do we need a suspend mode in which the device _doesn't_
> > > > wake up on request? I don't think so... and in any case, there's no
> > > > way
> > > > to pass this information (whether to ignore I/O requests) to the driver.
> > >
> > > Why not?
> >
> > Take a look at the definition of pm_message_t and tell me where you think
> > the information could be stored.
>
> How many in kernel data structures have been changed?
How many times have you succeeded in getting Pavel to change any of his
data structures? :-)
> Though if we limit
> pm to autosuspend the point is moot.
This boils down to one of our unanswered questions: How can we allow the
user to suspend a device if the driver wants remote-wakeup capability but
remote wakeup is disabled? Autosuspend won't do it, for a simple reason:
Autosuspend is always supposed to be safe, and without remote wakeup
it might not be safe. We will need something stronger.
The other unanswered question is whether we need a separate attribute
(with separate permissions) for enabling/disabling autosuspend. Note
that this attribute would be per-device and not per-interface, even if we
do have a per-interface delay attribute.
It would be nice if we could solve both questions together. For example,
we might have a device attribute that would allow the superuser to:
Turn off autosuspend completely;
Allow autosuspend to operate normally, using the delay value
specified in the other attribute file;
Force an immediate suspend, even if remote wakeup is disabled.
That's not really a harmonious or consistent set of functions, but it
would do the job.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
