Re: [PATCH 11/24] dt-bindings: mfd: syscon: Add ZX279128S system controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: syscon: missing provider properties for zte,zx279128s-crm2
--

commit 942a9a1a223eab1257c9aca18072ed465ea30ecf
Author: Navid Ghahremani <ghahramani.navid@gmail.com>

dt-bindings: mfd: syscon: Add ZX279128S system controller

This commit adds the zte,zx279128s-crm2 compatible string to the generic
syscon list in mfd/syscon.yaml to describe the remaining system-control
syscon for the ZX279128S platform.

> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
[ ... ]
>                - ti,j784s4-acspcie-proxy-ctrl
>                - ti,j784s4-pcie-ctrl
>                - ti,keystone-pllctrl
> +              - zte,zx279128s-crm2

[Severity: Medium]
The commit message explicitly notes that this hardware involves PCIe clock,
reset, and PHY modeling. If this compatible string acts as a hardware
provider for these capabilities, shouldn't standard properties like
#clock-cells, #reset-cells, or #phy-cells be documented in the schema and
added to a required list with appropriate constraints?

Without these constraints defined, a device tree using zte,zx279128s-crm2
might pass schema validation even when missing required properties.
Alternatively, valid nodes could fail validation if unevaluatedProperties is
enforced without these cells being defined in the schema.

If these provider capabilities require detailed modeling, would it be better
to document this hardware variant in a dedicated YAML file rather than adding
it to the generic syscon schema?

>            - const: syscon

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010130024.177503-1-ghahramani.navid@gmail.com?part=11