在 2026-06-25四的 17:33 +0100，Conor Dooley写道： > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote: > > The verisilicon,dc binding was originally written for the T-Head > > TH1520 > > SoC carrying a DC8200, and hard-codes five clocks, three resets and > > two > > output ports. > > > > Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the > > binding. > > The DCUltraLite uses only two clocks (core, pix0) and one reset > > (core), > > with a single output port. > > > > Use allOf/if blocks to express per-variant constraints rather than > > hard-coding the DC8200 topology at the top level. Each > > compatible's > > block constrains the clock and reset item counts; the nuvoton block > > additionally overrides clock-names to the two names it actually > > uses. > > > > Signed-off-by: Joey Lu <[email protected]> > > --- > > .../bindings/display/verisilicon,dc.yaml | 57 > > +++++++++++++++++++ > > 1 file changed, 57 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > index 9dc35ab973f2..1e751f3c7ce8 100644 > > --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > > @@ -17,6 +17,7 @@ properties: > > items: > > - enum: > > - thead,th1520-dc8200 > > + - nuvoton,ma35d1-dcu > > - const: verisilicon,dc # DC IPs have discoverable > > ID/revision registers > > > > reg: > > @@ -77,6 +78,62 @@ required: > > - clock-names > > - ports > > > > +allOf: > > + - if: > > + properties: > > + compatible: > > + contains: > > + const: thead,th1520-dc8200 > > + then: > > + properties: > > + clocks: > > + minItems: 5 > > + maxItems: 5 > > + > > + clock-names: > > + minItems: 5 > > + maxItems: 5 > > All the maxItems here repeat the maximum constraint and do nothing. > > Since you didn't change the minimum constraint at the top level, your > minItems also do nothing. > > > + > > + resets: > > + minItems: 3 > > + maxItems: 3 > > + > > + reset-names: > > + minItems: 3 > > + maxItems: 3 > > + > > + required: > > + - resets > > + - reset-names > > Both conditional sections have this, but the original binding doesn't > require these for the thead device. This is a functional change > therefore and shouldn't be in a patch calling itself "generalise for > single ended variants".
Well yes they're required. Should I send a patch adding the `thead,th1520-dc8200` part of the schema? > > FWIW, adding your new compatible shouldn't really be in a patch with > that subject either, it really should say "add support for nuvoton > ma35d1" or something. > > > + > > + - if: > > + properties: > > + compatible: > > + contains: > > + const: nuvoton,ma35d1-dcu > > + then: > > + properties: > > + clocks: > > + minItems: 2 > > Anything that updates the minimum constraint should be done at the > top > level of this schema. The conditional section should then tighten the > constraint, in this case that means only having maxItems. > > > + maxItems: 2 > > + > > + clock-names: > > + items: > > + - const: core > > + - const: pix0 > > Does this even work when the top level schema thinks clock 2 should > be > called axi? > > > + > > + resets: > > + minItems: 1 > > + maxItems: 1 > > + > > + reset-names: > > + items: > > + - const: core > > This is just maxItems: 1. Well the implicit rules of DT binding schemas are quite weird... Thanks, Icenowy > > pw-bot: changes-requested > > Thanks, > Conor. > > > + > > + required: > > + - resets > > + - reset-names > > + > > additionalProperties: false > > > > examples: > > -- > > 2.43.0 > >
