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 13:32:45 +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 Sunday 21 June 2009, Alan Stern wrote:
> 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.

Yes, exactly.  I also thought of the same names. :-)

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

Well, the suspend functions could be protected against that under the
assumption that no suspend is possible for resume_counter = 0 (then, the "good
to go" value would be -1).

Still, the resume functions start from acquring a spinlock, which is not going
to work if that spinlock is uninitialized.

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/