linux-kernel - Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power

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]

Date:   Wed, 29 Nov 2017 09:02:47 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        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 2/2] pinctrl: Allow indicating loss of pin states
 during low-power

* Linus Walleij <linus.walleij@...aro.org> [171129 13:03]:
> On Fri, Nov 3, 2017 at 12:15 AM, Florian Fainelli <f.fainelli@...il.com> wrote:
> 
> > Some platforms (e.g: Broadcom STB: BMIPS_GENERIC/ARCH_BRCMSTB) will lose
> > their register contents when entering their lower power state. In such a
> > case, the pinctrl-single driver that is used will not be able to restore
> > the power states without telling the core about it and having
> > pinctrl_select_state() check for that.
> >
> > This patch adds a new optional boolean property that Device Tree can
> > define in order to obtain exactly that and having the core pinctrl code
> > take that into account.
> >
> > Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
> 
> Florian, I'm really sorry for losing track of this patch set, it's
> important stuff and I see why systems are dependent on something
> like this.
> 
> Tony: can you look at this from a pinctrl-single point of view?
> This is the intended consumer: pinctrl-single users that lose the
> hardware state over suspend/resume.
> 
> How do you see this working with other pinctrl-single users?

Hmm well typically a device driver that loses it's context just does
save and restore of the registers in runtime PM suspend/resume
as needed. In this case it would mean duplicating the state for
potentially for hundreds of registers.. So using the existing
state in the pinctrl subsystem totally makes sense for the pins.

Florian do you have other reasons why this should be done in the
pinctrl framework instead of the driver? Might be worth describing
the reasoning in the patch descriptions :)

So as long as the pinctrl framework state is used to restore the
state by the pinctrl driver instead of the pinctrl consumer drivers,
I don't have issues with this patchset. So probably just improving
the patch messages a bit should do it.

FYI, on omaps, the PRCM hardware saves and restores the pinctrl
state so this has not been so far an issue.

Regards,

Tony