linux-kernel - Re: [PATCH v2 1/2] dt-bindings: gpio: brcm: Add bindings for xgs-iproc

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] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+iad9+SE8kwKdxKfOF6TsbTF1V+3yNOLhNNsgnmhSCiA@mail.gmail.com>
Date:   Fri, 18 Oct 2019 14:07:15 -0500
From:   Rob Herring <robh@...nel.org>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     Chris Packham <chris.packham@...iedtelesis.co.nz>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" 
        <bcm-kernel-feedback-list@...adcom.com>,
        linux-gpio <linux-gpio@...r.kernel.org>,
        linux-devicetree <devicetree@...r.kernel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: gpio: brcm: Add bindings for xgs-iproc

On Fri, Oct 18, 2019 at 1:00 AM Bartosz Golaszewski
<bgolaszewski@...libre.com> wrote:
>
> czw., 17 paź 2019 o 21:24 Rob Herring <robh@...nel.org> napisał(a):
> >
> > On Thu, Oct 17, 2019 at 04:10:50PM +1300, Chris Packham wrote:
> > > This GPIO controller is present on a number of Broadcom switch ASICs
> > > with integrated SoCs. It is similar to the nsp-gpio and iproc-gpio
> > > blocks but different enough to require a separate driver.
> > >
> > > Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> > > ---
> > >
> > > Notes:
> > >     Changes in v2:
> > >     - Document as DT schema
> > >     - Include ngpios, #gpio-cells and gpio-controller properties
> > >
> > >  .../bindings/gpio/brcm,xgs-iproc.yaml         | 83 +++++++++++++++++++
> > >  1 file changed, 83 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
> > > new file mode 100644
> > > index 000000000000..71998551209e
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
> > > @@ -0,0 +1,83 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/gpio/brcm,xgs-iproc.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Broadcom XGS iProc GPIO controller
> > > +
> > > +maintainers:
> > > +  - Chris Packham <chris.packham@...iedtelesis.co.nz>
> > > +
> > > +description: |
> > > +  This controller is the Chip Common A GPIO present on a number of Broadcom
> > > +  switch ASICs with integrated SoCs.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - brcm,iproc-gpio-cca
> >
> > enum vs. const usage depends on whether you think you'll add more
> > compatibles.
> >
>
> What if you don't know yet? For instance we use a const compatible and
> then a new chip is released for which we can reuse the driver?

Then you just change it to an enum (or oneOf if the new compatible has
a fallback to the old one). Not really a big deal.

> Is this
> something that is expected to remain stable in the binding document?

No, only in the sense we want to minimize changes.

> The question is unrelated to this patch, I'm just unsure about my own
> approach to writing yaml bindings.

We could perhaps just say single entries should always be 'const'
because then we could write a meta-schema enforcing that:

properties:
  enum:
    minItems: 2

I don't think we should be that strict though unless it becomes a
frequent review topic. So either way is fine, it's up to your
judgement, and let's stop talking about it before I change my mind. :)

Rob