linux-kernel - Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force a state

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: <CACRpkdY82RPKNbVPC8XC3BeHa27-gsyu2j+G-pSFgg8AYUJvZw@mail.gmail.com>
Date:   Wed, 29 Nov 2017 14:06:34 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Florian Fainelli <f.fainelli@...il.com>,
        ext Tony Lindgren <tony@...mide.com>
Cc:     linux-gpio@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
        Stephen Warren <swarren@...dia.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Al Cooper <alcooperx@...il.com>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>
Subject: Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force
 a state

On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli <f.fainelli@...il.com> wrote:

> It may happen that a device needs to force applying a state, e.g:
> because it only defines one state of pin states (default) but loses
> power/register contents when entering low power modes. Add a
> pinctrl_dev::flags bitmask to help describe future quirks and define
> PINCTRL_FLG_FORCE_STATE as such a settable flag.
>
> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>

So if I understand correctly, the state is lost across
suspend/resume, correct?

Or are we even talking runtime PM runtime_suspend
and runtime_resume here?

> @@ -1197,9 +1197,21 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
>  {
>         struct pinctrl_setting *setting, *setting2;
>         struct pinctrl_state *old_state = p->state;
> +       bool force = false;
>         int ret;
>
> -       if (p->state == state)
> +       if (p->state) {
> +               list_for_each_entry(setting, &p->state->settings, node) {
> +                       if (setting->pctldev->flags & PINCTRL_FLG_FORCE_STATE)
> +                               force = true;
> +               }
> +       }
> +
> +       /* Some controllers may want to force this operation when they define
> +        * only one set of functions and lose power state, e.g: pinctrl-single
> +        * with its pinctrl-single,low-power-state-loss property.
> +        */
> +       if (p->state == state && !force)
>                 return 0;

So the idea is we go and change the state even if we are in the right
state already, I understand that much.

But how is pinctrl_select_state() being called in the first place under
these circumstances?

If this comes from the resume() callback in .pm of the device driver,
would not the same thing be achived if you just set some mock
"sleep" state in suspend()? It could even have exactly the same settings
as the "default" state, as long as it is another state, the register
will be reprogrammed.

See further include/linux/pinctrl/pinctrl-state.h

Yours,
Linus Walleij