Re: [PATCH v2 4/4] dt-bindings: watchdog: factor out RZ/V2H(P) watchdog

[Rob Herring <robh@kernel.org>]

On Mon, Oct 06, 2025 at 11:25:11AM +0200, Geert Uytterhoeven wrote:
> Hi Wolfram,
> 
> On Mon, 6 Oct 2025 at 08:30, wsa+renesas
> <wsa+renesas@sang-engineering.com> wrote:
> > > > > > +      - enum:
> > > > > > +          - renesas,r9a09g057-wdt    # RZ/V2H(P)
> > > > > > +          - renesas,r9a09g077-wdt    # RZ/T2H
> > > > > > +
> > > > > > +      - items:
> > > > > > +          - const: renesas,r9a09g087-wdt # RZ/N2H
> > > > > > +          - const: renesas,r9a09g077-wdt # RZ/T2H
> > >
> > > I guess a comment like # fallback RZ/T2H here will avoid confusion.
> >
> > Hmmm, if we add such a comment for every fallback, this will be quite
> > some churn, I would think. My favourite solution would be to swap the
> > 'items' entry with the 'enum'. So, everything with a fallback comes
> > first, and the 'plain' entries last. But what do others think?

That's probably what I'd pick, but I try not to define rules we can't 
check with tools. Otherwise, I get tired of having to review that rule. 

And adding a rule to tools has the cost of fixing the existing cases 
everywhere.

> We do have "fallback" comments in other places, and I think they do
> help in understanding compatible naming schemes.
> 
> Would it be possible to handle this in dt-schema?
> Currently we have to write:
> 
>       - const: vendor,soc1-ip
> 
>       - items:
>           - enum:
>               - vendor,soc2-ip
>               - vendor,soc3-ip
>           - const: vendor,soc1-ip       # fallback
> 
> If dt-schema would automatically drop duplicates of the fallback,
> we could just write:
> 
>       - items:
>           - enum:
>               - vendor,soc1-ip
>               - vendor,soc2-ip
>               - vendor,soc3-ip
>           - const: vendor,soc1-ip       # fallback
> 
> What do you think?

It would almost work with just 'minItems: 1' added. That's because we 
require strings to be unique entries, so soc1 twice will be rejected. 
But then that allows for no fallback with soc2 and soc3.

So I don't see a way to do this other than transforming the above back 
into what we have today under a oneOf. That's a bit more deviation from 
json-schema than I'm comfortable with. Mostly the tools just add 
properties (like 'additionalItems: false' here) where the default is not 
what we want.

Rob