Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] The Nuvoton MA35D1 conditional schema block logically conflicts with top-level constraints, causing validation of valid Nuvoton device trees to unconditionally fail. - [Medium] The Nuvoton MA35D1 conditional block fails to restrict the `ports` property to a single output port, contradicting the hardware description. --
commit 6779aa6e54db7988d8c51ba66d2a7972829a44e6 Author: Joey Lu <[email protected]> dt-bindings: display: verisilicon,dc: generalize for single-output variants This commit adds the Nuvoton MA35D1 DCUltraLite to the verisilicon,dc binding. It introduces conditional blocks to express per-variant constraints for clocks and resets rather than hard-coding the DC8200 topology at the top level. > diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > index 9dc35ab973f20..1e751f3c7ce83 100644 > --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml [ ... ] > +allOf: [ ... ] > + - if: > + properties: > + compatible: > + contains: > + const: nuvoton,ma35d1-dcu > + then: > + properties: > + clocks: > + minItems: 2 > + maxItems: 2 > + > + clock-names: > + items: > + - const: core > + - const: pix0 [Severity: High] Does this conditional schema conflict with the top-level constraints? Any device tree node containing the compatible string for the Nuvoton variant is evaluated against both the top-level schema and this conditional block concurrently. The top-level definitions strictly enforce a 5-item array and specific constant values for clock-names (such as the second item being axi). This block attempts to override those with a maximum of 2 items and restricts the second item to pix0. Since a length cannot be both exactly 5 and a maximum of 2, and an element cannot be both axi and pix0, this creates an unsatisfiable constraint. Will this cause validation of valid Nuvoton device trees to unconditionally fail? > + > + resets: > + minItems: 1 > + maxItems: 1 > + > + reset-names: > + items: > + - const: core > + > + required: > + - resets > + - reset-names [Severity: Medium] Does this block need to explicitly restrict the ports property to a single output port? The commit message states that the Nuvoton MA35D1 DCUltraLite has a single output port. However, because this conditional block does not explicitly disallow the second port, it inherits the top-level allowances. Will malformed device trees incorrectly specifying two output ports for the Nuvoton variant silently pass schema validation, bypassing the hardware topology checks? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
