Re: [PATCH v11 03/13] dt-bindings: Convert gpio-mmio to yaml

On 14/03/2023 19:09, Sean Anderson wrote:

On 3/14/23 13:56, Krzysztof Kozlowski wrote:

quoted

On 13/03/2023 17:11, Sean Anderson wrote:

quoted

This is a generic binding for simple MMIO GPIO controllers. Although we
have a single driver for these controllers, they were previously spread
over several files. Consolidate them. The register descriptions are
adapted from the comments in the source. There is no set order for the
registers, so I have not specified one.

Rename brcm,bcm6345-gpio to brcm,bcm63xx-gpio to reflect that bcm6345
has moved.

Signed-off-by: Sean Anderson <redacted>
Reviewed-by: Linus Walleij <redacted>
---
Linus or Bartosz, feel free to pick this up as the rest of this series
may not be merged any time soon.

Changes in v11:
- Keep empty (or almost-empty) properties on a single line
- Don't use | unnecessarily
- Use gpio as the node name for examples
- Rename brcm,bcm6345-gpio.yaml to brcm,bcm63xx-gpio.yaml

Changes in v10:
- New

 ...m6345-gpio.yaml => brcm,bcm63xx-gpio.yaml} |  16 +--
 .../devicetree/bindings/gpio/gpio-mmio.yaml   | 134 ++++++++++++++++++
 .../bindings/gpio/ni,169445-nand-gpio.txt     |  38 -----
 .../devicetree/bindings/gpio/wd,mbl-gpio.txt  |  38 -----
 4 files changed, 135 insertions(+), 91 deletions(-)
 rename Documentation/devicetree/bindings/gpio/{brcm,bcm6345-gpio.yaml => brcm,bcm63xx-gpio.yaml} (78%)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
 delete mode 100644 Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
 delete mode 100644 Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt

diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
similarity index 78%
rename from Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
rename to Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
index 4d69f79df859..e11f4af49c52 100644
--- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml

quoted

+
+description:
+  Some simple GPIO controllers may consist of a single data register or a pair
+  of set/clear-bit registers. Such controllers are common for glue logic in
+  FPGAs or ASICs. Commonly, these controllers are accessed over memory-mapped
+  NAND-style parallel busses.
+
+properties:
+  big-endian: true
+
+  compatible:

Keep compatible as first property.

I thought it was alphabetical.

There is no clear rule, except that compatible is always first. In the
DTS reg is second, in bindings usually as well but not always.

quoted

quoted

+    enum:
+      - brcm,bcm6345-gpio # Broadcom BCM6345 GPIO controller
+      - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
+      - ni,169445-nand-gpio # National Instruments 169445 GPIO NAND controller

I think you got comment that these comments are making things
unreadable. I don't see here improvement.

That was not the comment I got.

OK

| I think you can inline description: statements in the enum instead of
| the # hash comments, however IIRC you have to use oneOf and
| const: to do it, like I do in
| Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml
| but don't overinvest in this if it is cumbersome.

I investigated this and determined it was cumbersome.

So just :

     # Western Digital MyBook Live memory-mapped GPIO controller
     - wd,mbl-gpio

quoted

For example first comment is useless - you say the same as compatible.
Same with last one. So only remaining WD comment should be made in new
line so everything is nicely readable.

I don't understand what you mean by "made in new line". Anyway, I will
leave just the WD comment.

quoted

BTW, order the enum by name.

OK

quoted

quoted

+
+  '#gpio-cells':
+    const: 2
+
+  gpio-controller:
+    true

I am sure I saw comments here...

https://lore.kernel.org/all/20230308231018.GA4039466-robh@kernel.org/ (local)

OK

quoted

quoted

+
+  reg:
+    minItems: 1
+    description:
+      A list of registers in the controller. The width of each register is
+      determined by its size.

I don't understand this comment. Aren't you describing now what 'reg' is
in DT spec? If so, drop. If not, please share more.

Each register describes exactly one hardware register. In some other
device, when you see `regs = <0x8000000 0x100>`, then you may have 64
32-bit registers. But for this device, it would be one 2048-bit
register.

Ah, so you do not mean here address space size? OK then, thanks for
clarification.

quoted

quoted

 All registers must have the same width. The number
+      of GPIOs is set by the width, with bit 0 corresponding to GPIO 0.
+    items:
+      - description:
+          Register to READ the value of the GPIO lines. If GPIO line is high,
+          the bit will be set. If the GPIO line is low, the bit will be cleared.
+          This register may also be used to drive GPIOs if the SET register is
+          omitted.
+      - description:
+          Register to SET the value of the GPIO lines. Setting a bit in this
+          register will drive the GPIO line high.
+      - description:
+          Register to CLEAR the value of the GPIO lines. Setting a bit in this
+          register will drive the GPIO line low. If this register is omitted,
+          the SET register will be used to clear the GPIO lines as well, by
+          actively writing the line with 0.
+      - description:
+          Register to set the line as OUTPUT. Setting a bit in this register
+          will turn that line into an output line. Conversely, clearing a bit
+          will turn that line into an input.
+      - description:
+          Register to set this line as INPUT. Setting a bit in this register
+          will turn that line into an input line. Conversely, clearing a bit
+          will turn that line into an output.
+
+  reg-names:
+    minItems: 1
+    maxItems: 5
+    items:
+      enum:

Why this is in any order? Other bindings were here specific, your 'reg'
is also specific/fixed.

Some devicetrees have dirout first, and other have dat first. There is no
mandatory order, and some registers can be included or left out as is
convenient to the devicetree author.

reg is not specific/fixed either. It is just done that way for
convenience (and to match the names here).

The items have order and usually we require strict order from DTS,
unless there is a reason. If there is no reason, use fixed order and
then fix the DTS.

quoted

quoted

+        - dat
+        - set
+        - clr
+        - dirout
+        - dirin
+
+  native-endian: true
+
+  no-output:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      If this property is present, the controller cannot drive the GPIO lines.
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - '#gpio-cells'
+  - gpio-controller
+
+additionalProperties: false
+
+examples:
+  - |
+    gpio@1f300010 {
+      compatible = "ni,169445-nand-gpio";
+      reg = <0x1f300010 0x4>;
+      reg-names = "dat";
+      gpio-controller;
+      #gpio-cells = <2>;
+    };
+
+    gpio@1f300014 {
+      compatible = "ni,169445-nand-gpio";
+      reg = <0x1f300014 0x4>;
+      reg-names = "dat";
+      gpio-controller;
+      #gpio-cells = <2>;
+      no-output;
+    };

No need to duplicate examples. Keep only one.

OK

quoted

Everything is the same.

Except no-output.

I would argue that even one example with no-output is enough, but sure,
can be two in total.



Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel