linux-kernel - Re: [linux-pm] Re: [RFC][PATCH -mm 3/3] PM: Disable _request

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: <200705291309.47559.david-b@pacbell.net>
Date:	Tue, 29 May 2007 13:09:47 -0700
From:	David Brownell <david-b@...bell.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	linux-pm@...ts.linux-foundation.org, Pavel Machek <pavel@....cz>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend

On Monday 28 May 2007, Alan Stern wrote:

> This is a matter of one's philosophy.  In suspend-to-RAM, should tasks
> be frozen or should I/O queues be frozen?
> 
> With the USB subsystem I have followed the approach taken by the PM
> core, which is that tasks are frozen.  But one can -- and Linus has on
> at least one occasion -- make a good case that tasks should be left
> running while only I/O is frozen. 

In fact that makes a heck of a lot more sense to me from the
conceptual point of view.  From the hardware perspective, the
task of preparing to enter true suspend states (STR, or suspend
for ACPI; embedded systems have more options) focusses on what
I/O signals are disabled.

Once the relevant I/O signals are first idled, then disabled,
the CPU can do whatever it likes.  Whether it runs or not is
purely a workload decision...

Remember too that not all systems suffer from the constraints
that ACPI decrees.  In particular, it's not uncommon that some
parts of the system be active in certain suspend states.  The
whole point is to turn off as much of the system as possible,
especially the high power portions, while letting work proceed.

Turning off some clocks and peripherals doesn't need to imply
turning them all off, or disabling DMA ... and should not need
to be triggered by a user (or userspace tool) explicitly saying
"go into STR".

> This would require the subsystem to 
> distinguish between a selective device suspend and a system-wide
> suspend-to-RAM, so that selective resume could be enabled on demand in
> one case but not the other.

Exactly.  "Selective suspend" of parts of the system is a far
more general model.  It fits well with runtime power management,
degrades smoothly to states where memory goes into self-refresh
(maybe the system idle loop when NO_HZ is being effective) or
even hibernation (as discussed elsewhere).

- Dave

> It's quite doable in principle -- it's just not the technique I used.
> 
> 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/