On Fri, Oct 6, 2023 at 3:23 PM Rob Herring <robh@xxxxxxxxxx> wrote: > On Thu, Oct 05, 2023 at 11:58:43AM +0900, AKASHI Takahiro wrote: > > A dt binding for pin controller based generic gpio driver is defined in > > this commit. One usable device is Arm's SCMI. > > You don't need a "generic" binding to have a generic driver. Keep the > binding specific and then decide in the OS to whether to use a generic > or specific driver. That decision could change over time, but the > binding can't. For example, see simple-panel. What you say is true for simple-panel (a word like "simple" should always cause red flags). This case is more like mfd/syscon.yaml, where the singular compatible = "syscon"; is in widespread use: $ git grep 'compatible = \"syscon\";' |wc -l 50 I would accept adding a tuple compatible if you insist, so: compatible = "foo-silicon", "pin-contro-gpio"; One case will be something like: compatible = "optee-scmi-pin-control", "pin-control-gpio"; In this case I happen to know that we have the problem of this being standardization work ahead of implementation on actual hardware, and that is driven by the will known firmware ambition to be completely abstract. It is supposed to sit on top of pin control, or as part of pin control. Which leads me to this thing (which I didn't think of before...) > + gpio0: gpio@0 { > + compatible = "pin-control-gpio"; > + gpio-controller; > + #gpio-cells = <2>; > + gpio-ranges = <&scmi_pinctrl 0 10 5>, > + <&scmi_pinctrl 5 0 0>; > + gpio-ranges-group-names = "", > + "pinmux_gpio"; > + }; Maybe we should require that the pin-control-gpio node actually be *inside* the pin control node, in this case whatever the label &scmi_pinctrl is pointing to? We can probably mandate that this has to be inside a pin controller since it is a first. Yours, Linus Walleij