linux-kernel - Re: [PATCH 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

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: <20160928080907.GA4567@sharon>
Date:   Wed, 28 Sep 2016 16:09:07 +0800
From:   Chen Yu <yu.c.chen@...el.com>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     linux-pm@...r.kernel.org, "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Lee Jones <lee.jones@...aro.org>, linux-kernel@...r.kernel.org,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended
 lpss unnecessarily

Hi Oliver,
On Wed, Sep 28, 2016 at 09:42:54AM +0200, Oliver Neukum wrote:
> On Wed, 2016-09-28 at 11:28 +0800, Chen Yu wrote:
> > So first try is to use pm_request_resume() instead, to make the
> > runtime
> > resume process asynchronously. Unfortunately the asynchronous runtime
> > resume relies on pm_wq, which is freezed at early stage. So we choose
> > another method, that is to avoid resuming runtime-suspended devices,
> > if they are already runtime suspended. This is safe because for LPSS
> > driver, the runtime suspend and system suspend are of the same
> > hook - i.e., intel_lpss_suspend(). And moreover, this device is
> > neither runtime wakeup source nor system wakeup source.
> 
> I agree with the reasoning but I don't see the specificity to LPSS.
> Shouldn't this go into the core?
>
Thanks for your reply. Do you mean we should add the logic to pm core?
There is already one if the driver's
.prepare() returns a positive number(aka, RPM_SUSPENDED), then pm core will keep
this device in runtime-suspended during sleep.
Documentation/power/runtime_pm.txt:
"the PM core provides a mechanism allowing some coordination between
different levels of device hierarchy.  Namely, if a system suspend .prepare()
callback returns RPM_SUSPENDED for a device, that indicates to the PM core
that the device appears to be runtime-suspended and its state is fine, so it
may be left in runtime suspend provided that all of its descendants are also
left in runtime suspend.  If that happens, the PM core will not execute any
system suspend and resume callbacks for all of those devices, except for the
complete callback, which is then entirely responsible for handling the device
as appropriate. "

Thanks,
Yu