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

Sean Anderson sean.anderson at seco.com
Wed Mar 15 05:09:00 AEDT 2023


On 3/14/23 13:56, Krzysztof Kozlowski wrote:
> On 13/03/2023 17:11, Sean Anderson wrote:
>> 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 <sean.anderson at seco.com>
>> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>> ---
>> 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
> 
> 
>> +
>> +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.

>> +    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.

| 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.

> 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.

> BTW, order the enum by name.

OK

>> +
>> +  '#gpio-cells':
>> +    const: 2
>> +
>> +  gpio-controller:
>> +    true
> 
> I am sure I saw comments here...
> 
> https://lore.kernel.org/all/20230308231018.GA4039466-robh@kernel.org/

OK

>> +
>> +  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.

>>  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).

>> +        - 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 at 1f300010 {
>> +      compatible = "ni,169445-nand-gpio";
>> +      reg = <0x1f300010 0x4>;
>> +      reg-names = "dat";
>> +      gpio-controller;
>> +      #gpio-cells = <2>;
>> +    };
>> +
>> +    gpio at 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

> Everything is the same.

Except no-output.

--Sean


More information about the Linuxppc-dev mailing list