Re: [PATCH v5 03/12] dt-bindings: clock: add Ambarella CV75 RCT
| Newsgroups | dev.linux.lists.mfd,org.kernel.vger.linux-clk,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The Device Tree binding intentionally omits `#reset-cells` for a hardware block that acts as a reset provider, violating the core DT principle that bindings must describe hardware rather than software/driver support. -- --- Patch [3]: [PATCH v5 03/12] dt-bindings: clock: add Ambarella CV75 RCT --- commit 74b3b598f48fd3b6837b5a870e3274a514495c94 Author: Long Zhao <[email protected]> dt-bindings: clock: add Ambarella CV75 RCT This commit introduces the Device Tree binding and clock ID header for the Ambarella CV75 RCT block. It currently describes only the clock-provider functionality, intentionally omitting reset properties. > This initial binding describes only the clock-provider functionality. > Reset-controller support is outside scope of this series, so #reset-cells > property is intentionally omitted. [Severity: Medium] Device tree bindings are expected to describe hardware rather than software driver support. Because this hardware block acts as a reset provider, should #reset-cells be documented and allowed in the schema now? > diff --git a/Documentation/devicetree/bindings/clock/ambarella,cv75-rct.yaml b/Documentation/devicetree/bindings/clock/ambarella,cv75-rct.yaml > new file mode 100644 > index 0000000000000..eb5956fc32bc4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/ambarella,cv75-rct.yaml [ ... ] > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - "#clock-cells" > + > +additionalProperties: false [Severity: Medium] Because additionalProperties is set to false without defining #reset-cells in the schema, any complete device tree node that accurately models the hardware's reset capabilities will fail schema validation. If #reset-cells is later added as a required property when reset support is implemented, won't it break backward compatibility with device trees created against this initial schema? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3