Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Low] The top-level `clocks` definition retains a fixed `items` array with descriptions that conflict with the Nuvoton single-output variant, erroneously documenting its second clock as `DMA AXI bus clock`. - [Low] The schema does not strictly enforce the single-output variant constraint for `nuvoton,ma35d1-dcu`, allowing a device tree to incorrectly define an invalid `port@1`. --
commit 5f08249fbf664513d5ae1c658d2a7ebfc4f0b03e Author: Joey Lu <[email protected]> dt-bindings: display: verisilicon,dc: generalize for single-output variants The existing schema hard-codes the five-clock/three-reset/dual-port topology of the DC8200 IP block. This commit reworks the schema to express variant specific constraints via allOf/if blocks, allowing reuse for single-output variants like the Verisilicon DCUltraLite used in the Nuvoton MA35D1 SoC. > diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > index 9dc35ab973f20..db0260d874c53 100644 > --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml [ ... ] > @@ -26,6 +27,7 @@ properties: > maxItems: 1 > > clocks: > + minItems: 2 > items: > - description: DC Core clock > - description: DMA AXI bus clock > @@ -34,24 +36,19 @@ properties: [Severity: Low] Since the top-level clocks property retains a fixed items array, does this cause the Nuvoton variant's second clock to incorrectly inherit the description "DMA AXI bus clock" instead of its actual "pix0" clock? Should the items array for clocks be moved to the per-variant if/then blocks (similar to how clock-names is handled) so that the hardware interface is documented accurately for each variant? [ ... ] > -additionalProperties: false > +allOf: [ ... ] > + - if: > + properties: > + compatible: > + contains: > + const: nuvoton,ma35d1-dcu > + then: > + properties: > + clocks: > + minItems: 2 > + maxItems: 2 > + > + clock-names: > + items: > + - const: core > + - const: pix0 > + > + resets: > + maxItems: 1 > + > + reset-names: > + items: > + - const: core [Severity: Low] Because unevaluatedProperties: false operates globally, any property defined at the top level (such as port@1 in the global ports object) is permitted for all variants unless explicitly disallowed. Since nuvoton,ma35d1-dcu is a single-output variant, should this block explicitly forbid port@1 (e.g., by adding ports: properties: port@1: false) so that device trees with invalid multiple ports cannot silently pass schema validation? > + > +unevaluatedProperties: false -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
