Re: [PATCH net-next v19 03/10] dt-bindings: mfd: Document support for Airoha AN8855 Switch SoC

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Low] The `reset-gpios` property is defined as `true` without a `maxItems` constraint.
- [Low] The `mdio` child node property is missing the `type: object` declaration.
- [Low] The example includes a DT binding header for GPIO flags but uses a magic number instead of the appropriate macro.
--

--- Patch [3]: [PATCH net-next v19 03/10] dt-bindings: mfd: Document support for Airoha AN8855 Switch SoC ---
commit bdb9e8bcc1f2530430cfc54469b92361f09d65cd
Author: Christian Marangi <[email protected]>

dt-bindings: mfd: Document support for Airoha AN8855 Switch SoC

This commit adds device tree bindings documentation for the Airoha AN8855
Switch SoC. It defines the constraints for peripherals including an Ethernet
switch, NVMEM provider, and Ethernet PHYs.

> diff --git a/Documentation/devicetree/bindings/mfd/airoha,an8855.yaml b/Documentation/devicetree/bindings/mfd/airoha,an8855.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/airoha,an8855.yaml
> @@ -0,0 +1,173 @@
[ ... ]
> +properties:
> +  compatible:
> +    const: airoha,an8855
> +
> +  reg:
> +    maxItems: 1
> +
> +  reset-gpios: true

[Severity: Low]
Should this define a maxItems constraint? 

Since it doesn't reference a common schema that enforces a limit (like
panel-common.yaml), device trees defining multiple GPIOs might silently pass
validation, even if the hardware only supports a single reset line.

> +
> +  efuse:
> +    type: object
> +    $ref: /schemas/nvmem/airoha,an8855-efuse.yaml
> +    description: EFUSE exposed by the Airoha AN8855 SoC
> +
> +  ethernet-switch:
> +    type: object
> +    $ref: /schemas/net/dsa/airoha,an8855-switch.yaml
> +    description: Switch exposed by the Airoha AN8855 SoC
> +
> +  mdio:
> +    $ref: /schemas/net/mdio.yaml#
> +    description: MDIO exposed by the Airoha AN8855 SoC

[Severity: Low]
Is type: object missing here?

The standard mdio.yaml does not enforce type: object at its root. If a
malformed device tree defines mdio as a scalar value, object-related
validation rules might be bypassed. The sibling efuse and ethernet-switch
declarations correctly specify it for their respective nodes.

> +
> +required:
> +  - compatible
> +  - reg
> +  - mdio
> +  - ethernet-switch
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    mdio {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        soc@1 {
> +            compatible = "airoha,an8855";
> +            reg = <1>;
> +
> +            reset-gpios = <&pio 39 0>;

[Severity: Low]
Since the dt-bindings/gpio/gpio.h header is included at the top of the
example, would it be better to use GPIO_ACTIVE_HIGH instead of the raw
integer 0 for the flags parameter?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3