linux-kernel - Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for run-time PM of I/O devices

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]

Date:	Mon, 22 Jun 2009 15:20:43 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for 
	run-time PM of I/O devices

On Sat, Jun 20, 2009 at 11:30 PM, Alan Stern<stern@...land.harvard.edu> wrote:
> Some more thoughts...
>
> Magnus, you might have some insights here.  It occurred to me that some
> devices can switch power levels very quickly, and the drivers might
> therefore want the runtime suspend and resume methods to be called as
> soon as possible, even in interrupt context.

I'd like to call pm_request_suspend() from interrupt context. I don't
depend on it, but being able to perform runtime suspend directly from
the ISR would be convenient from a device driver POV. I'm not sure if
that should result in bus/device ->runtime_suspend() calls from
interrupt context though.

In my case the bus specific code for ->runtime_suspend() may just
decrease the usage count of the powerdomain but refrain from calling
the device ->runtime_suspend() callbacks until all devices in the
powerdomain have been suspended. The bus/device runtime suspend
callbacks do not need to be executed from interrupt context. Just
noting that the device is idle is enough at interrupt time. This could
be handled by generic code IMO.

Runtime resume needs to block until the hardware is woken up though.
Just marking the device as resumed and letting the driver access the
hardware before it is woken up does not seem like a good idea. =) For
my SuperH devices I do not need to resume from interrupt context, at
least at this point.

>From my perspective it's ok to specificy that the ->runtime_suspend()
and ->runtime_resume() callbacks are executed from process context
only and may sleep. Seems like a simple and good interface that can be
accepted by many bus types. My bus and driver code do not need to
sleep though, so a direct-from-interrupt-context design is fine as
well.

> In terms of the current framework, this probably means holding the
> runtime PM lock (i.e., not releasing it) across the calls to
> ->runtime_suspend and ->runtime_resume.  It also means that
> pm_request_suspend and pm_request_resume should carry out their jobs
> immediately instead of queuing a work item.  (Unless the current status
> is RPM_SUSPENDING or RPM_RESUMING, which should never happen.)

No problem holding a per struct device lock. I suspect that executing
the callbacks from interrupt context is the most efficient design, but
it may come with interrupt latency side effects.

> Should there be a flag in dev_pm_info to select this behavior?

I'd say that executing the callbacks from process context is enough
for now. This will probably be a good match together with interrupt
threads as well.

Maybe the ARM guys have more advanced requriements?

Cheers,

/ magnus
--
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/