On Fri, Oct 18, 2019 at 1:00 AM Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> wrote: > > czw., 17 paź 2019 o 21:24 Rob Herring <robh@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> > > > --- > > > > > > 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@xxxxxxxxxxxxxxxxxxx> > > > + > > > +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
