linux-kernel - Re: [PATCH] PM: Introduce core framework for run-time PM of I/O devices (rev. 3)

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: <Pine.LNX.4.44L0.0906231303390.3209-100000@iolanthe.rowland.org>
Date:	Tue, 23 Jun 2009 13:10:20 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	linux-pm@...ts.linux-foundation.org,
	Oliver Neukum <oliver@...kum.org>,
	Magnus Damm <magnus.damm@...il.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>, Greg KH <gregkh@...e.de>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] PM: Introduce core framework for run-time PM of I/O
 devices (rev. 3)

On Tue, 23 Jun 2009, Rafael J. Wysocki wrote:

> Hi,
> 
> Below is a new revision of the patch introducing the run-time PM framework.
> 
> The most visible changes from the last version:
> 
> * I realized that if child_count is atomic, we can drop the parent locking from
>   all of the functions, so I did that.
> 
> * Introduced pm_runtime_put() that decrements the resume counter and queues
>   up an idle notification if the counter went down to 0 (and wasn't 0 previously).
>   Using asynchronous notification makes it possible to call pm_runtime_put()
>   from interrupt context, if necessary.
> 
> * Changed the meaning of the RPM_WAKE bit slightly (it is now also used for
>   disabling run-time PM for a device along with the resume counter).
> 
> Please let me know if I've overlooked anything. :-)

This first thing to strike me was that you moved the idle notifications 
into the workqueue.

Is that really needed?  Would we be better off just make the idle
callbacks directly from pm_runtime_put?  They would run in whatever
context the driver happened to be in at the time.

It's not clear exactly how much work the idle callbacks will need to 
do, but it seems likely that they won't have to do too much more than 
call pm_request_suspend.  And of course, that can be done in_interrupt.

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/