linux-kernel - Re: [PATCH] gpiolib: Show correct direction from the beginning

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: <CACRpkdYGpEVG9gqPxNaOsD55k9idEfGaxOUrObbN9VZS06x5jw@mail.gmail.com>
Date:   Wed, 19 Sep 2018 22:23:42 -0700
From:   Linus Walleij <linus.walleij@...aro.org>
To:     timur@...nel.org
Cc:     Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>,
        Timur Tabi <timur@...eaurora.org>,
        Stephen Boyd <swboyd@...omium.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpiolib: Show correct direction from the beginning

On Wed, Sep 19, 2018 at 4:50 AM Timur Tabi <timur@...nel.org> wrote:
> On 9/18/18 11:04 PM, Ricardo Ribalda Delgado wrote:
> > And should't that be tacked in qcom hardware with something like:
> >
> > if (!priv->initialized)
> >     return INPUT;
> >
> > if you or Timur point me to the harware that was crashing I would not
> > mind looking into that, but the current situations seems to me like a
> > hack.
>
> I'd say the previous code was the hack.  My comment about not touching
> the hardware until it is properly claimed is valid, and it applies to
> all platforms.

I am a bit uncertain, I understand the reasoning that unless a GPIO line
has been "claimed" (i.e. .request() was called on it) then we should not
call any of the gpiochip callbacks.

But this is merely a convention, the gpiochip becomes what we want
it to be and it has the semantics we want it to have.

It also makes sense to inquire the direction initially so we know the
state of the hardware in the library.

I think most gpiochips easily survives calling the .get_direction()
early, Qualcomm's stand out here.

Now that we have .valid_mask in the gpiochip could we simply just
add this back, resepecting valid_mask and avoid checking the
direction of precisely these GPIOs?

Yours,
Linus Walleij