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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <200610080907.16443.oliver@neukum.org>
Date:	Sun, 8 Oct 2006 09:07:16 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	Alan Stern <stern@...land.harvard.edu>
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

Am Sonntag, 8. Oktober 2006 04:03 schrieb Alan Stern:
> 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

Sorry.

> 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.

OK.

> > 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.

The simplicity is much reduced if each class of devices needs to have
its own method of determining activity. And if you don't find a good way
for some devices, users with these are out in the rain and can do nothing
about it if suspension cannot be triggered from user space.

> Considering that we have virtually no autosuspend capability now, taking
> the first few simple steps will be a big help.  Just getting an

No question about that.

> 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.

I've never said that autosuspend is a bad idea. For many devices it is
simple and painless. But it is insufficient. Therefore I think removing
the ability to explicitely request a suspension from user space is wrong.

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

If so many people cannot come up with a good design, doesn't that indicate
there's no single method that satisfies all needs?

	Regards
		Oliver
-
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/