Hi Rob,
On Fri, 27 Jun 2025 at 23:05, Rob Herring <robh@xxxxxxxxxx> wrote:
> On Wed, Jun 25, 2025 at 02:07:10PM +0100, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> >
> > 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@xxxxxxxxxxxxxx>
> > Signed-off-by: Thierry Bultel <thierry.bultel.yh@xxxxxxxxxxxxxx>
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > --- /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@xxxxxxxxxxxxxx
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
