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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171129174500.GJ28152@atomide.com>
Date:   Wed, 29 Nov 2017 09:45:01 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     linux-gpio@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.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>,
        ckeepax@...nsource.cirrus.com, ckeepax@...nsource.wolfsonmicro.com,
        swarren@...dia.com, andy.shevchenko@...il.com, alcooperx@...il.com,
        bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force
 a state

* Florian Fainelli <f.fainelli@...il.com> [171129 17:37]:
> On 11/29/2017 09:01 AM, Tony Lindgren wrote:
> > * Florian Fainelli <f.fainelli@...il.com> [171102 23:18]:
> >> 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.
> > 
> > It makes sense to tag the existing state with the context loss
> > information as otherwise we'll be duplicating the state in the
> > pinctrl driver potentially for hundreds of pins.
> > 
> > Maybe this patch description should clarify that it's the
> > pinctrl device restoring the pin state, not the pinctrl
> > consumer devices?
> > 
> > So maybe just "a pinctrl device needs to force apply a state"
> > instead of just device above?
> 
> It's a bit more involved than that, the pinctrl consumer device might
> want to restore a particular state by calling pinctrl_select_state(),
> however, because of the (p->state == state)check, the pinctrl provider
> driver has no chance of making that call do the actual HW programming.

Hmm but isn't it the pinctrl provider device losing context here?
I think the restore of the pin state should somehow happen automatically
by the pinctrl provider driver without a need for the pinctrl consumer
drivers to do anything.

Or what's the use case for pinctrl consumer driver wanting to store
a pin?

Regards,

Tony