Re: [PATCH v10 03/26] dt-bindings: ufs: mediatek,ufs: Add mt8196 variant

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] A typo in the `mediatek,mt8192-ufshci` conditional block uses `clocks-names` instead of `clock-names`, bypassing array length validation.
- [Low] The binding omits a supply property for the `AVDD09_UFS_1` pin, tying it to `AVDD09_UFS`, which violates the principle that Device Tree describes the SoC hardware rather than a specific board's power routing.
--

--- Patch [3]: [PATCH v10 03/26] dt-bindings: ufs: mediatek,ufs: Add mt8196 variant ---
commit e0eeeaec009272d40ddbc2fee8902782c15e776c
Author: Nicolas Frattaroli <[email protected]>

dt-bindings: ufs: mediatek,ufs: Add mt8196 variant

The MT8196 SoC's UFS controller uses a different set of supplies, making it
incompatible with MT8195. This commit adds a compatible string for mt8196
and updates the binding. It also notes that the AVDD09_UFS and AVDD09_UFS_1
pins are commoned together on the referenced board.

> While it does have a AVDD09_UFS_1 pin in addition to the AVDD09_UFS pin,
> it appears that these two pins are commoned together, as the board
> schematic I have access to uses the same supply for both, and the
> downstream driver does not distinguish between the two supplies either.

[Severity: Low]
Does omitting a separate supply property for the AVDD09_UFS_1 pin violate the
principle that Device Tree bindings should describe the SoC hardware rather
than a specific board's power routing?

If a future board design supplies the AVDD09_UFS and AVDD09_UFS_1 pins from
separate voltage regulators, the current binding wouldn't be able to accurately
describe that hardware.

While reviewing the file touched by this patch, I noticed a regression in the
conditional block for the mt8192-ufshci compatible string:

Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml:allOf
>   - if:
>       properties:
>         compatible:
>           contains:
>             const: mediatek,mt8192-ufshci
>     then:
>       properties:
>         clocks:
>           minItems: 3
>           maxItems: 3
>         clocks-names:
>           minItems: 3
>           maxItems: 3

[Severity: Medium]
Is the "clocks-names" property a typo here? It seems like this should be
"clock-names".

Because of the typo, the length of the clock-names array is not properly
constrained for mt8192-ufshci. An invalid device tree with 3 clocks but a
mismatched number of clock-names could silently pass dt_binding_check validation.

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