linux-kernel - Re: [RFC] sleepy linux

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]

Message-Id: <200712301739.42192.oliver@neukum.org>
Date:	Sun, 30 Dec 2007 17:39:42 +0100
From:	Oliver Neukum <oliver@...kum.org>
To:	Pavel Machek <pavel@....cz>
Cc:	kernel list <linux-kernel@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.osdl.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [RFC] sleepy linux

Am Sonntag, 30. Dezember 2007 00:51:34 schrieb Pavel Machek:
> Hi!
> 
> > > ... I also don't need to call any suspend() routines, because all the
> > > drivers are already suspended, right?
> > 
> > Well, you have a number of devices which cannot do runtime pm.
> > They can do suspend/resume with the whole system. For them these
> > operations mean saving/restoring state.
> > So for these devices implementing autosuspend makes no sense.
> > They would sensibly do only idle/busy detection.
> 
> Yep... Let's call busy/idle detection and save/restore state
> "autosuspend" for those devices. It does not save any power, but it
> can be viewed as "kind-of-suspend". (No, I do not have this kind of
> details ready).

Well, you probably would have to walk through all devices and check
all devices are either suspended or can be suspended. That would mean
struct device has to be extended to show common attributes.

But what's wrong with calling suspend() the conventional way once you've
decided to go into sleepy mode?

[..]
> > We lack a notion of telling devices that they are opened only for
> > detecting wakeups. Currently a driver has to assume that an opened
> > device has to be fully functional.
> 
> Yes, we'll need to add some userland interfaces. No, this will not be
> easy.

This mainly means input devices.

	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/