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]

Message-ID: <Pine.LNX.4.44L0.0906202223080.20502-100000@netrider.rowland.org>
Date:	Sat, 20 Jun 2009 22:30:01 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
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 Sun, 21 Jun 2009, Rafael J. Wysocki wrote:

> 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.

Good idea.  pm_runtime_resume_atomic() and pm_runtime_suspend_atomic().  
No need for _request variants since the status should never be 
RPM_SUSPENDING or RPM_RESUMING while the lock is released.


> > 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?

By mistake.  :-)

Seriously, there _are_ places where drivers get bound to device before
those devices are registered.  This happens for example in USB when a
bunch of related interfaces are present in the same physical device.  
When the first interface is registered, its driver binds itself to all
the others even though they haven't been registered yet.

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/