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]

Date:   Tue, 24 Oct 2023 15:01:19 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Cristian Marussi <cristian.marussi@....com>
Cc:     AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Rob Herring <robh@...nel.org>, sudeep.holla@....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 12:55 PM Cristian Marussi
<cristian.marussi@....com> wrote:

> ...a maybe dumb question from my side, BUT does the SCMI Pinctrl carry
> enough information as it stands for the driver to derive autonomously
> and efficently the possible/applicable gpio ranges ?

I don't know, that's part of the problem I suppose. But if the
pin controller can report functions supported by certain pins
or groups of pins, then certainly "gpio" should be one of those
functions or else the pin cannot be used for GPIO at all?

Then maybe that function is just a name convention, such
as "all pins are members of a 1-pin group named 'gpioN'
where N is the pin number" then you need to switch the pin
into this function in order to use the pin as a GPIO line.
Pins that do not have this group associated with them
cannot be used for GPIO.

This is incidentally exactly the method used by the Qualcomm
pin control driver (IIRC).

If the SCMI protocol has not though about GPIO as a special
function, or mentioned anything about group name
conventions for the GPIO function, then there is a hole
in the specification, and this is likely best filled by creating
one-pin groups as per above and feed this back to the
spec.

If the GPIO usecase isn't even considered a function by SCMI,
or (more likely) "nobody thought about that" then this is
a good time to send it back to the drawing board for
specification, right? It's normal for specs to run into a bit
of friction when confronted with the real world.

Yours,
Linus Walleij