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]

Date:   Thu, 27 May 2021 10:58:37 +0800
From:   Steven Lee <steven_lee@...eedtech.com>
To:     Jeremy Kerr <jk@...abs.org>
CC:     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>,
        "Hongweiz@....com" <Hongweiz@....com>,
        Ryan Chen <ryan_chen@...eedtech.com>,
        Billy Tsai <billy_tsai@...eedtech.com>
Subject: Re: [PATCH v1 1/4] dt-bindings: aspeed-sgpio: Convert txt bindings
 to yaml.

The 05/27/2021 09:42, Jeremy Kerr wrote:
> 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.
> 

Thanks for your suggestion, I will split them into 2 patches.

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

AST2600 support both SGPIO master and slave interfaces. So we decide to
rename sgpio to sgpiom as it is the driver for sgpio master interface.
Since Andrew also point out the compatibility issues, I will modify driver
to keep the original design.

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

I will modify the description as you suggested.

> > +    minimum: 0
> > +    maximum: 128
> 
> Will this be the case for all (future) hardware? Can we leave this
> unbound?
> 

Since the future hardware may supports more gpios, I will remove it.

> Cheers,
> 
> 
> Jeremy
>