From: Rob Herring <robh@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Magnus Damm <magnus.damm@gmail.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mmc: renesas,sdhi: add top-level constraints
Date: Mon, 19 Aug 2024 11:53:50 -0600 [thread overview]
Message-ID: <20240819175350.GA1700516-robh@kernel.org> (raw)
In-Reply-To: <CAMuHMdU3V=ZO6me5LekUQN4NC82yw5_UYNd23gZwctUa-GiJ6g@mail.gmail.com>
On Mon, Aug 19, 2024 at 03:38:48PM +0200, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Sun, Aug 18, 2024 at 7:29 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> > Properties with variable number of items per each device are expected to
> > have widest constraints in top-level "properties:" block and further
> > customized (narrowed) in "if:then:". Add missing top-level constraints
> > for clocks.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> Thanks for your patch!
>
> > --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
> > @@ -77,9 +77,13 @@ properties:
> > minItems: 1
> > maxItems: 3
> >
> > - clocks: true
> > + clocks:
> > + minItems: 1
> > + maxItems: 4
> >
> > - clock-names: true
> > + clock-names:
> > + minItems: 1
> > + maxItems: 4
> >
> > dmas:
> > minItems: 4
>
> I am a bit puzzled by all these add-top-level-constraint patches.
> E.g. this file already constrains all of them below.
>
> To me, it feels the same as a patch for driver code that would do:
>
> + if (param < 16 || param > 512)
> + return -EINVAL;
> +
> if (hw_variant_a) {
> if (param < 16 || param > 256)
> return -EINVAL;
> ...
> } else if (hw_variant_b) {
> if (param < 32 || param > 512)
> return -EINVAL;
> ...
> } else /* hw_variant_c */ {
> if (param < 32 || param > 384)
> return -EINVAL;
> ...
> }
>
> What's the point?
if/then schemas can be incomplete and we don't enforce they are missing
constraints. We could change that, but we'd have to do that everywhere.
It would make the schemas longer.
If you have a new chip not yet documented, but matches the fallback
compatible (as many Renesas bindings have), then you at least
get constraints within the existing bounds.
The keywords didn't exist when we started out. It is somewhat academic
because we know what the implementation supports, but it is entirely
possible a json-schema implementation doesn't support if/then schemas.
The spec says unknown keywords are ignored.
Rob
next prev parent reply other threads:[~2024-08-19 17:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-18 17:29 [PATCH] dt-bindings: mmc: renesas,sdhi: add top-level constraints Krzysztof Kozlowski
2024-08-19 13:38 ` Geert Uytterhoeven
2024-08-19 17:53 ` Rob Herring [this message]
2024-08-19 17:54 ` Rob Herring (Arm)
2024-08-20 11:50 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240819175350.GA1700516-robh@kernel.org \
--to=robh@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=ulf.hansson@linaro.org \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).