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

[Linus Walleij]

Hi Takahiro,

On Tue, Oct 24, 2023 at 3:43 PM AKASHI Takahiro
<takahiro.akashi at linaro.org> wrote:

> First of all, there is no pre-defined naming convention either for
> pins, groups or functions. SCMI firmware can give them any names.

OK maybe that should be added to the spec?

[NB: I poked the pinctrl implementers in a separate mail, you
are on CC.]

Otherwise I think this is one of those cases where firmware
authors will simply start to use a certain naming convention if
the Linux driver requires it.

> Secondly, What you said in the above is already implemented in
> my RFC patch. Please remember the example that I gave:
>
> >     gpio-ranges = <&scmi_pinctrl 6 0 0>;
> >     gpio-ranges-group-names = "pinmux_gpio";
> >
> > means that SCMI *group*, "pinmux_gpio", are mapped to this driver's
> > gpio range which starts with 5. If "pinmux_gpio" indicates SCMI *pin*
> > range [20..24],
> >
> >     baa-gpios = <&gpio0 7>;
> > will refer to gpio pin#7 that is actually SCMI's 22 (=20 + (7-5)).

Right! I am so unused to the gpio-ranges-group-names that
I didn't parse that properly :(

> After all, I still believe we need "gpio-ranges" property in most of
> all use cases (The only exception is, as I mentioned, to unconditionally
> map all pinctrl's pins to GPIO (if possible) when SCMI firmware provides
> only GPIO function for all pins. I think it is a simple and yet likely
> use case.

I suppose it is a bit of placement question.

The device tree GPIO ranges will have to duplicate more information
that the SCMI firmware already knows (what ranges are GPIOs, the
name of the GPIO mux function), that is my main concern.
And when we have information in two places that need to be matched,
invariably we get mismatches.

I'm trying to figure out what is the best way forward here but I think
we need some feedback from the pinctrl driver authors.

Yours,
Linus Walleij