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]
Date:	Fri, 8 Jul 2011 11:24:17 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Kevin Hilman <khilman@...com>
Cc:	Linux PM mailing list <linux-pm@...ts.linux-foundation.org>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	Magnus Damm <magnus.damm@...il.com>,
	Paul Walmsley <paul@...an.com>,
	Alan Stern <stern@...land.harvard.edu>,
	LKML <linux-kernel@...r.kernel.org>, linux-sh@...r.kernel.org,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [Update][PATCH 6/10] PM / Domains: System-wide transitions support for generic domains (v5)

On Friday, July 08, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@...k.pl> writes:
> 
> > From: Rafael J. Wysocki <rjw@...k.pl>
> >
> > Make generic PM domains support system-wide power transitions
> > (system suspend and hibernation).  Add suspend, resume, freeze, thaw,
> > poweroff and restore callbacks to be associated with struct
> > generic_pm_domain objects and make pm_genpd_init() use them as
> > appropriate.
> >
> > The new callbacks do nothing for devices belonging to power domains
> > that were powered down at run time (before the transition).  
> 
> Thinking about this some more, how is a driver supposed to reconfigure
> wakeups during suspend if it has already been runtime suspended?

If the device belongs to a PM domain that has been powered off, it
won't be notified.

> For example, assume a device where device_may_wakeup() == false.  This
> means wakeups during *suspend* are disabled, but wakeups wakeups are
> assumed to enabled when it is runtime suspended.
> 
> So now, assume this device is RPM_SUSPENDED, it has wakeups *enabled*,
> and then system suspend comes along.  
> 
> With this current patch, the driver will never receive any callbacks, so
> it can never disable its wakeups.  
>
> Am I missing something?

As I said above, this only happens with devices that belog to PM domains
that were powered off before system suspend has started, so the problem
is limited to devices that wakeup is signaled on behalf of even when they
have no power.

So this is a limitation, but not affecting all platforms.

There are a few ways to avoid this limitation I can think of:
(1) Add a "make me operational during system suspend" flag to struct dev_pm_info
    and run pm_runtime_resume() on such devices from the core (either dpm_prepare()
    core, or pm_genpd_prepare()).
(2) Add a "my .prepare() is safe to run if device is not accessible" flag to
    struct dev_pm_info and make pm_genpd_prepare() execute .prepare() for such
    devices regardless of whether or not their PM domains are off.
(3) Call .prepare() from all drivers unconditionally during system suspend
    (and probably .complete() too) in the hope they won't access inaccessible
    devices.
Probably, there's more.

In any case I think it's material for future work.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ