linux-kernel - Re: [PATCH 3/4] PM / core: Direct DPM_FLAG_SMART

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: <CAPDyKFqd6qk66C4M0h-4WzLjt_p=LyS1unCAzLxKrUYoSMbz6Q@mail.gmail.com>
Date:   Tue, 19 Dec 2017 14:15:30 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Kevin Hilman <khilman@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 3/4] PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization

On 19 December 2017 at 12:19, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Tue, Dec 19, 2017 at 12:13 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
>> On Tue, Dec 19, 2017 at 8:38 AM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
>>> On 10 December 2017 at 01:00, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>>>> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>>>>
>
> [cut]
>
>>
>>> Moreover, what happens when/if a driver that has deployed this
>>> solution, starts being used on a new SoC and then additional
>>> operations during system suspend becomes required (for example
>>> pinctrls that needs to be put in a system sleep state)? Then
>>> everything falls apart, doesn't it?
>>
>> Then you runtime-resume the device in ->suspend() and the remaining
>> callbacks will run for you just fine.
>
> BTW, I guess you'll need a middle layer in that case anyway so that
> the driver doesn't have to distinguish between platforms it has to
> work with which makes the argument somewhat moot.

No, this isn't the case. Let's take the pinctrl as an example.

The pinctrl system sleep state could be optionally defined in the DT,
depending on the platform.

All the driver shall do, is to try to set the state, if it has been defined.

Kind regards
Uffe