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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200906130106.58464.rjw@sisk.pl>
Date:	Sat, 13 Jun 2009 01:06:57 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
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 Friday 12 June 2009, Alan Stern wrote:
> On Fri, 12 Jun 2009, Rafael J. Wysocki wrote:
> 
> > On Friday 12 June 2009, Alan Stern wrote:
> > > On Fri, 12 Jun 2009, Rafael J. Wysocki wrote:
> > > 
> > > > So, are you suggesting that the core should only check the "all children
> > > > suspended" condition if special flag is set in dev_pm_info?
> > > 
> > > Or rather, check it only if the special flag _isn't_ set.
> > 
> > Where the default is unset, I guess?
> 
> Yep.
> 
> > But then, what about the resuming of the parents before the device is resumed?
> > Should the parents be resumed regardless of the flag state?
> 
> Yes.  In general you should assume a device's parent (and the device
> itself!) needs to be resumed whenever the kernel wants to do something
> with the device.  The special flag arises because sometimes it's safe
> to suspend the parent without suspending the device _if_ the kernel
> isn't using the device.
> 
> Imagine an idle disk at the end of a link.  We might want to 
> autosuspend the link without spinning down the disk.  When we have to 
> communicate with the disk again, we autoresume the link.  (Including 
> the case where the communication is a "spin-down" command.)
> 
> >  And if so, what's
> > the condition for breaking the recurrence?  Surely it's not sufficient to check
> > if the parent is active, because its parent need not be active if it has this
> > special flag set.
> 
> That's a good question.  Let's assume that situations like this will be 
> handled by the drivers.
> 
> For example, suppose A is the parent of B is the parent of C, and A is
> suspended but B isn't and C is.  What happens when somebody wants to
> use C?
> 
> An autoresume request is generated for C.  Since C's parent is already
> resumed, the runtime_resume method in C's driver is called.  The driver
> has to do some I/O in order to resume C, so it passes an I/O request up
> to B's driver.  The request then gets passed up to A's driver.  This
> driver knows that A is suspended, so it starts an autoresume of A and
> waits for the autoresume to complete before carrying out the request.
> 
> Then the I/O can go through, so C gets resumed and everything works 
> out.
> 
> I don't know how often this sort of pattern will arise.  It certainly
> could be used in usb-storage; there would be no difficulty starting an
> autoresume when an I/O request arrives from the SCSI layer below.  In
> fact, that is exactly how some early runtime-PM patches for usb-storage
> worked.

So, the conclusion seems to be that we should break the recurrence
at the point we find an already active device or a device with no parent and
let the driver(s) handle the more complicated cases.  Is this correct?

BTW, is __device_release_driver() the right place for blocking the run-time PM
temporarily during remove?

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/