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:	Sun, 21 Jun 2009 01:48:56 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Magnus Damm <magnus.damm@...il.com>, 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 Saturday 20 June 2009, Alan Stern 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.

Then, we'll need special suspend and resume calls for them.

> 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.)
> 
> Should there be a flag in dev_pm_info to select this behavior?

I don't think we should complicate pm_request_suspend() and pm_request_resume()
further to handle this particular case.  IMO it's better to provide separate
core calls for that.

> When a device structure is unregistered and deallocated, we have to
> insure that there aren't any pending runtime PM workqueue items.  
> Hence device_del should call a routine that changes the status to an
> exceptional state (not RPM_ERROR but something else) to prevent new
> requests from being queued, and then calls cancel_work_sync or
> cancel_delayed_work_sync as required.

This is done in the patch I've just sent.
 
> Similarly, we should insure that runtime PM calls made before the
> device is registered don't do anything.  So when the device structure
> is first created and the contents are all 0, this should also be
> interpreted as an exceptional state.  We could call it RPM_UNREGISTERED
> and use it for both purposes.

Hmm.  How do you think is possible that the pm_runtime_* functions will be
called in such a situation?

Best,
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/