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
| ||
|
Date: Thu, 23 Jun 2011 11:11:46 -0400 (EDT) From: Alan Stern <stern@...land.harvard.edu> To: "Rafael J. Wysocki" <rjw@...k.pl> cc: Kevin Hilman <khilman@...com>, Linux PM mailing list <linux-pm@...ts.linux-foundation.org>, Greg Kroah-Hartman <gregkh@...e.de>, Magnus Damm <magnus.damm@...il.com>, Paul Walmsley <paul@...an.com>, LKML <linux-kernel@...r.kernel.org>, <linux-sh@...r.kernel.org> Subject: Re: [Update][PATCH 7/8] PM / Domains: System-wide transitions support for generic domains (v3) On Thu, 23 Jun 2011, Rafael J. Wysocki wrote: > > It might be worthwhile to include a little warning about the difference > > between suspend and hibernate. > > Well, there already is one: > > "* The driver's idea of the device state may not agree with the device's > physical state. This can happen during resume from hibernation." > > (in Documentation/power/runtime_pm.txt). Also, the new text in the patch > https://lkml.org/lkml/2011/6/23/200 I've just sent says literally: > > "If that is the case and none of the situations listed above takes place, it > may be more efficient to leave the devices that had been suspended before > the system sleep began in the suspended state." > > where the "situations listed above" include it. > > Do you think that's not sufficient? The preceding text in your new patch says: +On some systems, however, system sleep is not entered through a global firmware +or hardware operation. Instead, all hardware components are put into low-power +states directly by the kernel in a coordinated way. Then, the system sleep +state effectively follows from the states the hardware components end up in +and the system is woken up from that state by a hardware interrupt or a similar +mechanism entirely under the kernel's control. As a result, the kernel never +gives control away and the states of all devices during resume are precisely +known to it. It should say "system suspend" rather than "system sleep". Then to drive the point home, the following sentence chould say something like this: If that is the case and none of the situations listed above takes place (in particular, if the system is waking up from suspend and not from hibernation), it may be more efficient to leave the devices that had been suspended before the system suspend began in the suspended state. 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/
Powered by blists - more mailing lists