[v4,2/7] dt-bindings: gpio: rockchip,gpio-bank: add unique hardware GPIO ID

Add a unique hardware GPIO ID to the Rockchip GPIO nodes with
the "rockchip,gpio-controller" property to be independent from aliases
and probe order. "gpio-ranges" can't be used for that, because there is
no semantic restrictions on how they are set up.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
---

See discussion:
https://lore.kernel.org/u-boot/CACRpkdZx8EaSFLeh4vruRsdC+Sx_ieBiKmuE7t37zhiYqtS3WQ@mail.gmail.com/
---
 .../devicetree/bindings/gpio/rockchip,gpio-bank.yaml        | 6 ++++++
 1 file changed, 6 insertions(+)

--
2.20.1

On 23/02/2023 20:46, Johan Jonker wrote:
> Add a unique hardware GPIO ID to the Rockchip GPIO nodes with
> the "rockchip,gpio-controller" property to be independent from aliases
> and probe order. "gpio-ranges" can't be used for that, because there is
> no semantic restrictions on how they are set up.
> 
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
> 
> See discussion:
> https://lore.kernel.org/u-boot/CACRpkdZx8EaSFLeh4vruRsdC+Sx_ieBiKmuE7t37zhiYqtS3WQ@mail.gmail.com/
> ---
>  .../devicetree/bindings/gpio/rockchip,gpio-bank.yaml        | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> index 2e9a5179c..39ac41e9d 100644
> --- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> @@ -52,6 +52,12 @@ properties:
> 
>    gpio-line-names: true
> 
> +  rockchip,gpio-controller:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    maximum: 8
> +    description:
> +      Unique hardware GPIO ID.

Neither commit msg nor this description explain why do you need it.
Also: what is a unique ID? why only 8 of them are allowed? Why assigning
arbitrary numbers should be a property of DT (answer: it's not)?

Best regards,
Krzysztof

On Thu, Feb 23, 2023 at 8:46 PM Johan Jonker <jbx6244@gmail.com> wrote:

> Add a unique hardware GPIO ID to the Rockchip GPIO nodes with
> the "rockchip,gpio-controller" property to be independent from aliases
> and probe order. "gpio-ranges" can't be used for that, because there is
> no semantic restrictions on how they are set up.
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
>
> See discussion:
> https://lore.kernel.org/u-boot/CACRpkdZx8EaSFLeh4vruRsdC+Sx_ieBiKmuE7t37zhiYqtS3WQ@mail.gmail.com/
> ---
>  .../devicetree/bindings/gpio/rockchip,gpio-bank.yaml        | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> index 2e9a5179c..39ac41e9d 100644
> --- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> @@ -52,6 +52,12 @@ properties:
>
>    gpio-line-names: true
>
> +  rockchip,gpio-controller:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    maximum: 8
> +    description:
> +      Unique hardware GPIO ID.

So we need to discuss this with the Device Tree people because if this is needed
it need to be motivated in terms of "any operating system needs this".

Very similar precedents exist:

pinctrl/renesas,rzg2l-poeg.yaml

  renesas,poeg-id:
    $ref: /schemas/types.yaml#/definitions/uint32
    enum: [ 0, 1, 2, 3 ]
    description: |
      POEG group index. Valid values are:
        <0> : POEG group A
        <1> : POEG group B
        <2> : POEG group C
        <3> : POEG group D

pinctrl/st,stm32-pinctrl.yaml

      st,bank-name:
        description:
          Should be a name string for this bank as specified in the datasheet.
        $ref: "/schemas/types.yaml#/definitions/string"
        enum:
          - GPIOA
          - GPIOB
          - GPIOC
          - GPIOD
          - GPIOE
          - GPIOF
          - GPIOG
          - GPIOH
          - GPIOI
          - GPIOJ
          - GPIOK
          - GPIOZ

I don't know how the above properties are used in practice, but any creative
driver writer can use them exactly as you intend to do with this, so we need to
figure out if this is something all operating systems actually need or
whether we
should let driver authors just keep smuggling it in under the radar as
is already
happening.

Yours,
Linus Walleij