linux-kernel - Re: [linux-usb-devel] error to be returned while suspended

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 7 Oct 2006 22:03:38 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Oliver Neukum <oliver@...kum.org>
cc:	David Brownell <david-b@...bell.net>, Pavel Machek <pavel@....cz>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] error to be returned while suspended

On Sat, 7 Oct 2006, David Brownell wrote:

> On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:
> 
> > > > I dare say that the commonest scenario involving USB is a laptop with
> > > > an input device attached. Input devices are for practical purposes always
> > > > opened. A simple resume upon open and suspend upon close is useless.

You are distorting what I said.  The "resume upon open and suspend upon
close" scheme was not intended for things like input devices, which are
more or less permanently open.  It was intended for things like
fingerprint readers or printers, which spend most of their time not being
used.

> That is, the standard model is useless?  I think you've made
> a few strange leaps of logic there ... care to fill in those
> gaps and explain just _why_ that standard model is "useless"???
> 
> Recall by the way that the autosuspend stuff kicked off with
> discussions about exactly how to make sure that Linux could
> get the power savings inherent in suspending USB root hubs,
> with remote wakeup enabling use of the mouse on that keyboard.
> (I remember Len Brown talking to me a few years back about how
> that was the "last" 2W per controller easily available to save
> power on Centrino laptops ... now we're almost ready to claim
> that savings.)

The most obvious model for suspending keyboards or mice is an inactivity 
timeout (with the timeout limit set from userspace), but other policies 
certainly could be useful in specific circumstances.

Considering that we have virtually no autosuspend capability now, taking
the first few simple steps will be a big help.  Just getting an
infrastructure in place is a good start, even without a userspace API.  
Later on, when we have a better idea of what we want, bells and whistles
can be added.

Even Oliver has admitted that the implementation issues are very tricky 
and he doesn't know the best approach to take.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/