linux-kernel - Re: [PATCH] pinctrl: qcom: Add egpio feature support

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: <CACRpkdaJm_UbJu=kXGOFs76MiAiTkqToEpOnf1Pk-by4FsCcgQ@mail.gmail.com>
Date:   Tue, 21 Sep 2021 17:56:04 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Rajendra Nayak <rnayak@...eaurora.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Prasad Sodagudi <psodagud@...eaurora.org>
Subject: Re: [PATCH] pinctrl: qcom: Add egpio feature support

On Tue, Sep 21, 2021 at 12:39 PM Rajendra Nayak <rnayak@...eaurora.org> wrote:
> On 9/20/2021 6:14 AM, Bjorn Andersson wrote:

> > It seems reasonable that this would be another pinmux state for these
> > pins, rather than just flipping them all in one or the other direction.
>
> hmm, I don't understand. This is not a pinmux state, its a switch to decide
> the ownership.
> These egpio pins have regulator mux functions, some for apps, some for the
> island processor, they might not always be used as gpios.

The pinmux API is for muliplexing a pin between owners, and that
is what is going on is it not?

If the bit(s) select different processors that is changing the owner
and creating a usage matrix, e.g.

TLMM_GPIO
ISLAND_GPIO
TLMM_I2C
ISLAND_I2C
etc etc

They become different muxing states nevertheless. How to encode them,
such as (a) bitfields in the enums, (b) more cells in the device tree or
(c) ... that is another question.

Shoehorning it into pinconf is not the answer IMO.

Yours,
Linus Walleij