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: <ZTemAK/jBtv9b5xP@octopus>
Date:   Tue, 24 Oct 2023 20:09:52 +0900
From:   AKASHI Takahiro <takahiro.akashi@...aro.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     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

Hi Linus,

On Tue, Oct 24, 2023 at 11:40:00AM +0200, Linus Walleij wrote:
> Hi Takahiro,
> 
> On Tue, Oct 24, 2023 at 9:12???AM AKASHI Takahiro
> <takahiro.akashi@...aro.org> wrote:
> 
> > > I think it is better of the pin controller just parse and add any
> > > subdevices (GPIO or other) using of_platform_default_populate()
> > > (just grep for this function and you will see how many device
> > > drivers use that).
> >
> > IICU, then, we will have to add a "compatible" to pinctrl node
> > to make of_platform_default_populate() work as expected. That is:
> >
> > scmi {
> >     ...
> >     protocol@19 {
> >         compatible = "simple-bus"; // <- added
> 
> Hm right, but you could also use
> of_platform_populate(np, NULL, NULL, dev);
> 
> Then the compatible match is of no concern.
> 
> Sorry for my lack of attention to details :/
> 
> If you want to restrict the population to a few select compatibles
> (maybe only "pin-control-gpio") then you can do
> that with
> 
> const struct of_device_id of_scmi_protocol_19_match_table[] = {
>         { .compatible = "pin-control-gpio", },
>         {}
> };
> of_platform_populate(np, of_scmi_protocol_19_match_table, NULL, dev);
> 
> > Is this what you meant?
> > In this case, however, "protocol@19" has a mixture of sub-nodes,
> > most are pinconf definitions which are the properties of the pin
> > controller, while "scmi_gpio" is a separate device.
> 
> That looks good to me, it makes sense to have the GPIO as a subnode
> here and mandate it with a compatible to match.
> 
> > The code will work, but is it sane from DT binding pov?
> 
> Let's let the DT people jump in on that.
> 
> > > Instead just call gpiochip_add_pin_range() directly in Linux
> > > after adding the pin controller and gpio_chip.
> > > C.f. drivers/pinctrl/pinctrl-sx150x.c for an example of a driver
> > > doing this. In this case the SX150X is hot-plugged (on a slow
> > > bus) so it needs to figure out all ranges at runtime anyway.
> >
> > Are you suggesting implementing a custom function for parsing "gpio-ranges"
> > and calling it in pin_control_gpio_probe() instead of a generic helper?
> 
> The generic helper will always be attempted but if there are
> no ranges in the device tree, it will just continue without adding
> any ranges. I suggest putting *no* ranges into the device tree.
> 
> > Or do you want to always map all the pin controller's pins to
> > gpio pins as sx150x does?
> 
> I think since the SCMI firmware knows about the available line
> and pins etc, it makes sense that the driver comes up with the
> applicable ranges on its own (derived from the information from
> the SCMI firmware) and add them, instead of trying to put that
> information into the device tree at all. Just omit it, and make your
> own ranges, and add them in the Linux driver with
> gpiochip_add_pin_range() without involving DT at all when defining
> the ranges.

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.)

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.

It is possible but I believe that it is clunky and painful for the driver
initialization.
I'd like to see explicit "gpio-ranges" property in a device tree.

Thanks,
-Takahiro Akashi



> I'm sorry if I'm unclear sometimes.
> 
> Yours,
> Linus Walleij