Re: [PATCH v2 04/10] dt-bindings: pinctrl: add Ambarella CV75 pinctrl
From: sashiko-bot@kernel.org
Date: 2026-08-06 09:41:17
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] The pin configuration node schema (`^[a-z0-9-]+-pins$`) incorrectly uses `additionalProperties: false` alongside `$ref` schemas, and restrictively hardcodes `function` and `groups` exclusively to `uart0`. - [Medium] The GPIO child node pattern (`^gpio@[0-9a-f]+$`) incorrectly uses `additionalProperties: false` while omitting a reference to standard GPIO schemas, blocking common GPIO properties. --
--- Patch [4]: [PATCH v2 04/10] dt-bindings: pinctrl: add Ambarella CV75 pinctrl ---commit 004945278e95f95e4ac87cc90d5d3bc4136ce194 Author: Long Zhao [off-list ref] dt-bindings: pinctrl: add Ambarella CV75 pinctrl This commit adds the Ambarella CV75 pin controller device tree binding, which configures pin multiplexing, bias, and drive strength.
quoted hunk ↗ jump to hunk
diff --git a/Documentation/devicetree/bindings/pinctrl/ambarella,cv75-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ambarella,cv75-pinctrl.yaml new file mode 100644 index 0000000000000..3fa30b275e514 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ambarella,cv75-pinctrl.yaml
[ ... ]
+patternProperties: + "^gpio@[0-9a-f]+$": + type: object + additionalProperties: false
[Severity: Medium] Does this strict property boundary prevent the use of standard GPIO properties like gpio-line-names or ngpios? Setting additionalProperties to false without referencing /schemas/gpio/gpio.yaml# typically causes validation to fail when these common optional properties are used. Would unevaluatedProperties: false along with a reference to the standard GPIO schema be more appropriate here? [ ... ]
+ "^[a-z0-9-]+-pins$": + type: object + allOf: + - $ref: pinmux-node.yaml# + - $ref: pincfg-node.yaml# + additionalProperties: false
[Severity: Medium] Does using additionalProperties: false here incorrectly restrict standard properties inherited from the $ref schemas? This usually requires workarounds like redeclaring properties such as bias-disable. Would unevaluatedProperties: false be the correct approach when using $ref schemas?
+ + properties: + function: + const: uart0 + + groups: + $ref: /schemas/types.yaml#/definitions/string-array + items: + enum: [uart0tx, uart0rx]
[Severity: Medium] Does this lock the schema strictly to uart0? Hardcoding the function and groups like this appears to invalidate configurations for any other hardware functions such as I2C, SPI, or GPIO, causing device tree validation to fail for them. -- Sashiko AI review · https://sashiko.dev/#/patchset/20260806-longzhao-upstream-cv75-v2-v2-0-6b09707c5fe9@ambarella.com?part=4