[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdU+hT=i=gs35ia_9vvmqJPAsjscQ0CBhBZK3wyn=35Emg@mail.gmail.com>
Date: Wed, 2 Jul 2025 15:19:43 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Rob Herring <robh@...nel.org>
Cc: Prabhakar <prabhakar.csengg@...il.com>, Linus Walleij <linus.walleij@...aro.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Magnus Damm <magnus.damm@...il.com>, Bartosz Golaszewski <brgl@...ev.pl>, linux-renesas-soc@...r.kernel.org,
linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>,
Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v2 1/3] dt-bindings: pinctrl: renesas: document RZ/T2H and
RZ/N2H SoCs
Hi Rob,
On Fri, 27 Jun 2025 at 23:05, Rob Herring <robh@...nel.org> wrote:
> On Wed, Jun 25, 2025 at 02:07:10PM +0100, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Document the pin and GPIO controller IP for the Renesas RZ/T2H
> > (R9A09G077) and RZ/N2H (R9A09G087) SoCs, and add the shared DTSI
> > header file used by both the bindings and the driver.
> >
> > The RZ/T2H SoC supports 729 pins, while the RZ/N2H supports 576 pins.
> > Both share the same controller architecture; separate compatible
> > strings are added for each SoC to distinguish them.
> >
> > Co-developed-by: Thierry Bultel <thierry.bultel.yh@...renesas.com>
> > Signed-off-by: Thierry Bultel <thierry.bultel.yh@...renesas.com>
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzt2h-pinctrl.yaml
> > +additionalProperties:
>
> This style was for existing bindings which had no node name pattern.
> Define a pattern for node names.
The node name depends on the device for which pin control is configured.\
Typical examples are "sd2", "sound", "usb0", ...
...
> > + anyOf:
> > + - type: object
> > + additionalProperties: false
> > + allOf:
> > + - $ref: pincfg-node.yaml#
> > + - $ref: pinmux-node.yaml#
> > +
> > + description:
> > + Pin controller client devices use pin configuration subnodes (children
> > + and grandchildren) for desired pin configuration.
> > + Client device subnodes use the below standard properties.
> > +
> > + properties:
> > + pinmux:
> > + description:
> > + Values are constructed from GPIO port number, pin number, and
> > + alternate function configuration number using the RZT2H_PORT_PINMUX()
> > + helper macro from <dt-bindings/pinctrl/renesas,r9a09g077-pinctrl.h>.
> > + pins: true
> > + gpio-hog: true
> > + gpios: true
> > + input: true
> > + input-enable: true
> > + output-enable: true
> > + output-high: true
> > + output-low: true
> > + line-name: true
> > +
> > + - type: object
> > + additionalProperties:
> > + $ref: "#/additionalProperties/anyOf/0"
>
> Do you really need both 1 OR 2 levels of nodes? Can't you decide on one
> way?
Having two possible levels allows us to group pins that need similar
configuration, which is quite common for e.g. Ethernet and SDHI.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists