linux-kernel - Re: [patch update] Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code)

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.0906111041020.3040-100000@iolanthe.rowland.org>
Date:	Thu, 11 Jun 2009 10:52:03 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Oliver Neukum <oliver@...kum.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch update] Re: [linux-pm] Run-time PM idea (was: Re:
 [RFC][PATCH 0/2] PM: Rearrange core suspend code)

On Thu, 11 Jun 2009, Rafael J. Wysocki wrote:

> The point here is what the core is supposed to do.  Does it need to handle
> this at all or leave it to the bus type and driver?
> 
> After reconsidering it for a while I think that we should define what
> "suspended" is supposed to mean from the core point of view.  And my opinion
> is that it should mean "device doesn't communicate with the CPUs and RAM due
> to power management".  That need not be power management of the device itself,
> but such that leads to the device not doing I/O.
> 
> Under this definition all devices behind an inactive link are suspended,
> because they can't do any I/O.  Which appears to makes sense, because their
> drivers have to be notified before the link is suspended and the link has to be
> turned on for the devices to be able to communicate with the CPU and RAM.
> 
> If this definition is adopted, then it's quite clear that the device can only
> be suspended if all of its children are suspended and it's always necessary
> to resume the parent of a device in order to resume the device itself.

Okay, I'll agree to that.  It should be made clear that a device which 
is "suspended" according to this definition is not necessarily in a 
low-power state.  For example, before powering down the link to a disk 
drive you might want the drive's suspend method to flush the drive's 
cache, but it wouldn't have to spin the drive down.

(But this example leaves open the question of how we would go about
spinning down the disk.  Submitting a 15-minute (or whatever) delayed
autosuspend request wouldn't work; the request wouldn't be accepted
because the disk is already suspended as far as the PM core is
concerned.  The disk's driver would have to implement its own 
spin-down delayed_work.)

> > > > I haven't checked the details of the code yet.  More later...
> > 
> > One more thought...  The autosuspend and autoresume callbacks need to 
> > be mutually exclusive with probe and remove.  So somehow the driver 
> > core will need to block runtime PM calls.
> 
> That's correct and I'm going to take care of this.
> 
> > It might also be nice to make sure that the driver core autoresumes a 
> > device before probing it and autosuspends a device (after some 
> > reasonable delay) after unbinding its driver.
> 
> Agreed.

This is another case where a usage counter comes in handy.  The driver
core resumes the device and increments the counter -- thus preventing
any unwanted autosuspends -- before making the probe and remove calls.

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/