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]

Date:	Sun, 8 Oct 2006 09:14:26 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Pavel Machek <pavel@....cz>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-usb-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [linux-usb-devel] error to be returned while suspended

Am Sonntag, 8. Oktober 2006 02:03 schrieb David Brownell:
> 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.
> 
> That is, the standard model is useless?  I think you've made

To be precise a simple implementation of autosuspend is useless.
The idea can be expanded as I wrote if you care to read a bit further.
But still I find the idea to have drawbacks for input devices.

That is not to say that autosuspend is bad in all cases, but there are
unavoidable cases in which it is not optimal, which leads me to conclude
that suspension for a device must remain triggerable from user space.

	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/