Re: [PATCH v7 1/2] dt-bindings: usb: dwc3: Document Renesas R-Car Gen5 DWC3 xHCI USB controller

[Conor Dooley]

On Fri, Sep 04, 2026 at 06:24:04PM +0200, Marek Vasut wrote:
> On 9/4/26 5:32 PM, Conor Dooley wrote:
> 
> Hello Conor,
> 
> [...]
> 
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - reg-names
> > > +  - clocks
> > > +  - interrupts
> > > +  - phys
> > > +  - phy-names
> > > +  - power-domains
> > > +  - resets
> > > +
> > > +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.

> > , 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.

> 
> > Sounds like dr_mode: true and
> > maximum-speed: true are all you'd need?
> Ah, I think this also answers my previous question a bit. And, as for
> limiting the properties that are really needed -- this pulls in the common
> DWC3 USB IP core properties, which all do apply to the DWC3 core. They might
> not be used on current hardware, but they are still valid for the DWC3 core
> (IP).

Attachment: signature.asc
Description: PGP signature