Re: [PATCH v2 04/10] dt-bindings: pinctrl: add Ambarella CV75 pinctrl

[sashiko-bot@kernel.org]

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 <longzhao@ambarella.com>

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.

> 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