On Tue, Sep 08, 2026 at 10:58:48PM +0200, Marek Vasut wrote:
> On 9/7/26 7:43 PM, Conor Dooley wrote:
> 
> Hello Conor,
> 
> > > > > +unevaluatedProperties: false
> > > > 
> > > > I said this elsewhere today, but this binding has lots of "distasteful"
> > > > properties for things that should be determined from the compatible
> > > 
> > > Which properties would those be ? (it seems
> > > reg/clocks/interrupts/phys/power-domains/resets really need to be there as
> > > separate properties, but maybe I am missing the point?)
> > 
> > All the quirk properties is what I am talking about here. There's about
> > 50 of them and I don't know if a single one should actually exist.
> 
> I cannot tell whether every one of them will ever be used or useful, but I
> also do not have a good argument to block most of them as they are tunables
> which apply to the DWC3 core itself.
> 
> I could make only the ones which are currently used available, but that
> would be confusing the implementers by suggesting that the other quirks are
> not applicable even if they might be ; and this would likely turn into an
> endless stream of schema updates, with random users enabling random quirks
> they just used. I don't think that would be helpful.

My understanding was that these things were effectively errata, so users
should not be enabling them willy nilly - the vast majority of these are
set in soc.dtsi files, and the couple dts users I checked were all SoCs
for which there was only one board. IMO it's far more confusing to suggest
that a user has to figure out which of these may apply on their platform.
But of course, do what you want, they're your users.

> 
> > > > , so I
> > > > would appreciate it if you could use additionalProperties: false here
> > > > cite the ones you need to use explicitly.
> > > 
> > > May I ask, what exactly is the rule of thumb for additionalProperties:false
> > > and unevaluatedProperties:false ? I seem to struggle with picking the right
> > > one for a while now.
> > 
> > I would say, if all properties being imported apply to you device, use
> > unevaluated. If only some do, and there are some that will be
> > problematic or confusing if used, then additionalProperties: false and
> > citing the good ones explicit is clearer for users and prevents the bad
> > combos.
> 
> Thank you for this clarification, I will make a note of it.