linux-kernel - Re: [PATCH v1 1/4] dt-bindings: aspeed-sgpio: Convert txt bindings to yaml.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f50dec3a8be8f8254321d22d784eba4f5a032887.camel@ozlabs.org>
Date:   Thu, 27 May 2021 09:42:51 +0800
From:   Jeremy Kerr <jk@...abs.org>
To:     Steven Lee <steven_lee@...eedtech.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "moderated list:ARM/ASPEED MACHINE SUPPORT" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/ASPEED MACHINE SUPPORT" 
        <linux-aspeed@...ts.ozlabs.org>,
        open list <linux-kernel@...r.kernel.org>
Cc:     Hongweiz@....com, ryan_chen@...eedtech.com,
        billy_tsai@...eedtech.com
Subject: Re: [PATCH v1 1/4] dt-bindings: aspeed-sgpio: Convert txt bindings
 to yaml.

Hi Steven,

> SGPIO bindings should be converted as yaml format.
> In addition to the file conversion, a new property max-ngpios is
> added in the yaml file as well.
> The new property is required by the enhanced sgpio driver for
> making the configuration of the max number of gpio pins more
> flexible.

There are a number of things going on here - you're doing the YAML
conversion, introducing the max-gpios property, and changing the
compatible value.

The first two make sense, but may be better split into separate
changes, so that the YAML conversion is a "linear" change.

I'm not clear on why you're changing the compatible value though,
particularly as you're dropping support for the existing compatible
value anyway. How about we keep the old one, and use the default of 128
for cases where max-ngpios is absent? That way, we retain support for
the existing device trees.

> +  max-ngpios:
> +    description:
> +      represents the number of actual hardware-supported GPIOs (ie,
> +      slots within the clocked serial GPIO data). Since each HW GPIO is both an
> +      input and an output, we provide max_ngpios * 2 lines on our gpiochip
> +      device. We also use it to define the split between the inputs and
> +      outputs; the inputs start at line 0, the outputs start at max_ngpios.

Most of this description is better suited to the ngpios property, which
controls the number of lines that the gpiochip will expose.

Also, minor nit: max_ngpios -> max-ngpios.

How about something like:

  ngpios:
    description:
      Number of GPIO lines to expose. Since each HW GPIO is an input and an
      output, we provide ngpios * 2 lines on our chip device. We also use it
      to define the split between the inputs and outputs; the inputs start at
      line 0, the outputs start at ngpios.

  max-ngpios:
    description:
      Represents the number of actual hardware-supported GPIOs (ie, slots within
      the clocked serial GPIO data), and therefore the maximum value for
      the ngpios property

> +    minimum: 0
> +    maximum: 128

Will this be the case for all (future) hardware? Can we leave this
unbound?

Cheers,


Jeremy