linux-kernel - Re: [RFC v2 5/5] dt-bindings: gpio: Add bindings for pinctrl based generic gpio driver

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: <CACRpkdY-5uS9EeXfDFVOiRKiFmwwSn3jRVGhT-n4JMqesHEumw@mail.gmail.com>
Date:   Tue, 24 Oct 2023 15:12:51 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Rob Herring <robh@...nel.org>, sudeep.holla@....com,
        cristian.marussi@....com, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, Oleksii_Moisieiev@...m.com,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [RFC v2 5/5] dt-bindings: gpio: Add bindings for pinctrl based
 generic gpio driver

On Tue, Oct 24, 2023 at 1:10 PM AKASHI Takahiro
<takahiro.akashi@...aro.org> wrote:

> As far as I understand, there is only one way for SCMI gpio driver
> to know which pins are actually GPIO pins; Calling PINCNTRL_CONFIG_GET
> command with "Input-mode" or "Output-mode" configuration type
> against *every* pin-controller's pins.
> (Here I assume that the command would fail with INVALID_PARAMETERS or
> NOT_SUPPORTED if configuring the given pin as a GPIO input or output
> is not possible. But the specification seems to be a bit ambiguous.)

As I also wrote in the reply to Christian, I expect the SCMI firmware
to consider GPIO a function on the pins, and either individual pins
(groups with just one pin in it) or entire groups of pins can be switched
to perform the "gpio function". ("gpio function" is akin to "i2c function"
or "HDMI function" etc.)

If the SCMI protocol considers GPIO usage to be something else
than a function of a pin, that is going to be a problem. Then the SCMI
protocol need some other way of determining that the pin is in
GPIO mode, and perhaps something would need to be added to
the protocol for that.

The reason is that in practice a lot of hardware has to decouple
the pin from any internal function in order to use it as GPIO, and
connect it to the GPIO block that can drive the line high and low.
And we don't select that as a function, how is the firmware going
to know that it needs to do this? Implicitly from the call requesting
the line to be output perhaps. But if the firmware can be altered
to do that, the firmware can just as well be altered to present
GPIO as a proper function.

Using a function makes most sense, because the board firmware
knows which pins are GPIO lines and what they are used for
(such as a LED or camera flash) and at boot certainly put them
into GPIO function and drive them high/low or set them as
input (high impedance).

> It means that, if SCMI firmware has 100 pinctrl pins, the driver needs
> to call the command 200 times in order to get the answer.

I think we should only need to check which function each pin
has and those that are in the GPIO function we put into the ranges.

Yours,
Linus Walleij