Message-ID: <CAMuHMdUGXu8yj3JWKwM8mt7axkrzGMiowC1t0PHrbpxRCBME3w@mail.gmail.com>
Date:   Tue, 22 Jun 2021 10:17:28 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Rob Herring <robh@...nel.org>
Cc:     "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-ide@...r.kernel.org, linux-clk <linux-clk@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        dmaengine <dmaengine@...r.kernel.org>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        linux-iio@...r.kernel.org,
        ALSA Development Mailing List <alsa-devel@...a-project.org>,
        Linux IOMMU <iommu@...ts.linux-foundation.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Linux MMC List <linux-mmc@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>, linux-can@...r.kernel.org,
        linux-pci <linux-pci@...r.kernel.org>,
        linux-phy@...ts.infradead.org,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux PWM List <linux-pwm@...r.kernel.org>,
        "open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM" 
        <linux-remoteproc@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        linux-rtc@...r.kernel.org,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>,
        Linux Watchdog Mailing List <linux-watchdog@...r.kernel.org>,
        Jens Axboe <axboe@...nel.dk>, Stephen Boyd <sboyd@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>, Vinod Koul <vkoul@...nel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Kamal Dasu <kdasu.kdev@...il.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>, Joerg Roedel <joro@...tes.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Kishon Vijay Abraham I <kishon@...com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>, Lee Jones <lee.jones@...aro.org>,
        Ohad Ben-Cohen <ohad@...ery.com>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Brown <broonie@...nel.org>,
        Zhang Rui <rui.zhang@...el.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

Hi Rob,

On Tue, Jun 15, 2021 at 9:16 PM Rob Herring <robh@...nel.org> wrote:
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/maxItems.
>
> This condition is partially checked with the meta-schema already, but
> only if both 'minItems' and 'maxItems' are equal to the 'items' length.
> An improved meta-schema is pending.

> Signed-off-by: Rob Herring <robh@...nel.org>

> --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> @@ -46,7 +46,6 @@ properties:
>
>    clocks:
>      minItems: 3
> -    maxItems: 5
>      items:
>        - description: GMAC main clock
>        - description: MAC TX clock

While resolving the conflict with commit fea99822914039c6
("dt-bindings: net: document ptp_ref clk in dwmac") in soc/for-next,
I noticed the following construct for clock-names:

  clock-names:
    minItems: 3
    maxItems: 6
    contains:
      enum:
        - stmmaceth
        - mac-clk-tx
        - mac-clk-rx
        - ethstp
        - eth-ck
        - ptp_ref

Should this use items instead of enum, and drop maxItems, or is this
a valid construct to support specifying the clocks in random order?
If the latter, it does mean that the order of clock-names may not
match the order of the clock descriptions.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists