linux-kernel - Re: [linux-pm] [PATCH 0/2] PM: Wakeup sources and async suspend error path bug fix

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: <201010040104.09789.rjw@sisk.pl>
Date:	Mon, 4 Oct 2010 01:04:09 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	markgross@...gnar.org
Cc:	"Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] [PATCH 0/2] PM: Wakeup sources and async suspend error path bug fix

On Monday, October 04, 2010, mark gross wrote:
> On Mon, Sep 20, 2010 at 07:57:40PM +0200, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > The following two patches are ready to go into linux-next from my point of
> > view, so please let me know if there are any objections:
> > 
> > [1/2] - PM / Wakeup: Introduce wakeup source objects and event statistics (v3)
> > 
> > [2/2] - PM: Fix potential issue with failing asynchronous suspend
> > 
> > Thanks,
> > Rafael
> 
> Sorry for the late response but, what user feed back will this provide
> to the OS stack looking to put the system in a low power state?
> 
> There are 2 cases I can think of:
> 1) system wakes from an event that user mode needs to handle (i.e. key
> press or phone ring or alarm events)
> 2) system wakes (or more likely, is blocked from suspending) by a
> kernel critical section, say if USB-OTG is connected.
> 
> When wake's are of the type 1, then the power manager service could
> simply wait for a user mode wake lock be taken and released from the
> usermode before re-attempting to suspend.
> 
> When the wakes are of type 2, a power manager service thread would need
> to do a select on a system file and be woken up to re-try the suspend
> after the suspend-blocking is no longer needed.

IMO it is more convenient to implement that in a different way, but
generally I think you're right.

> Do you think I should cobble together an android PM driver that plugs
> into your code to expose an ABI for the 2 cases listed above?

Well, I'm not sure if I understand correctly, can you elaborate a bit, please?

> Also, with this do we want to revisit a pm_qos class for "active"
> systems?  Or do you think thats redundant now?

I don't really think the pm_qos for "active" systems is really necessary at
this point.

Thanks,
Rafael
--
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/