Re: [RFC PATCH net-next v2 1/2] dt-bindings: net: pse-pd: Add bindings for LTC4266 PSE Controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The child node definition `^pse-pi@[0-3]$` is missing `unevaluatedProperties: false`.
--

--- Patch [1]: [RFC PATCH net-next v2 1/2] dt-bindings: net: pse-pd: Add bindings for LTC4266 PSE Controller ---
commit 1f8974966417493a9b12a4f2599002b08898882c
Author: Kyle Swenson <kyle.swenson@est.tech>

dt-bindings: net: pse-pd: Add bindings for LTC4266 PSE Controller
    
Add the LTC4266 Power Sourcing Equipment controller device tree bindings
documentation.

> diff --git a/Documentation/devicetree/bindings/net/pse-pd/lltc,ltc4266.yaml b/Documentation/devicetree/bindings/net/pse-pd/lltc,ltc4266.yaml
> new file mode 100644
> index 0000000000000..b3da8fea0b07a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/pse-pd/lltc,ltc4266.yaml
[ ... ]
> +  pse-pis:
> +    type: object
> +    additionalProperties: false
> +
> +    properties:
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +    patternProperties:
> +      '^pse-pi@[0-3]$':
> +        type: object
> +        properties:
> +          pairsets:

[Severity: Low]
Is it possible to add unevaluatedProperties: false to this object?

The Device Tree schema meta-schema strictly requires that any node defined as
type: object must specify either additionalProperties: false or
unevaluatedProperties: false. 

Omitting this on the ^pse-pi@[0-3]$ node causes the schema to silently allow
any undocumented or misspelled property inside the pse-pi@X nodes, which
defeats the purpose of dt-schema validation. Since this node relies on
properties defined in the referenced pse-controller.yaml, using
unevaluatedProperties: false seems to be needed here.

> +            description: The LTC4266 delivers power to a PI over a single
> +              pairset, driven by one of the controller's four channels. There
> +              is no 4-pair mode spreading a PI over two channels, so exactly
> +              one channel phandle is expected.
> +            maxItems: 1
> +          pairset-names:
> +            maxItems: 1

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820142429.2285172-1-kyle.swenson@est.tech?part=1