Re: [PATCH v8 2/7] dt-bindings: clock: qcom,glymur-tcsr: Add mahua support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The device tree binding defines `#clock-cells` and `#reset-cells` as provider capabilities but fails to include them in the global `required` list.
- [Medium] Supply properties for the Mahua SoC are incorrectly named after the external board regulators (`vdda-refgen3-0p9`, `vdda-refgen3-1p2`) rather than the consumer hardware block's input pad (`REFGEN4`).
--

--- Patch [2]: [PATCH v8 2/7] dt-bindings: clock: qcom,glymur-tcsr: Add mahua support ---
commit 95da44cfb54a2f053c5c1da86a79be1166f21f64
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>

dt-bindings: clock: qcom,glymur-tcsr: Add mahua support

This commit adds the qcom,mahua-tcsr compatible string and documents its
required supply properties. It notes that Mahua has a single QREF block fed
by REFGEN4 only, which is supplied by regulators vdda-refgen3-1p2 and
vdda-refgen3-0p9.

> diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> index ec89feff89e4e..2b64226271657 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
[ ... ]
> @@ -82,6 +83,25 @@ allOf:
[ ... ]
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: qcom,mahua-tcsr
> +    then:
> +      required:
> +        - vdda-qrefrpt0-0p9-supply
[ ... ]
> +        - vdda-qreftx1-0p9-supply
> +        - vdda-refgen3-0p9-supply
> +        - vdda-refgen3-1p2-supply

[Severity: Medium]
The commit message mentions that the internal hardware block being fed here
is REFGEN4. Do these supply properties violate device tree property naming
principles by encoding the board-specific external regulator names
(vdda-refgen3-*) rather than the consumer pad name?

Should these required properties be renamed to correspond to the REFGEN4 pad
to avoid encoding board-specific regulator topology into the SoC hardware
schema?

>  
>  required:
>    - compatible

[Severity: Medium]
The device tree binding defines #clock-cells and #reset-cells as provider
capabilities, but they appear to be missing from this global required list.

Does this omission allow incomplete device tree nodes (those lacking
#clock-cells and #reset-cells) to pass schema validation? Could this lead
to dependent drivers or subsystems silently failing at runtime when they
attempt to use these functionalities?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-tcsr_qref_0708-v8-0-62c42b5fa269@oss.qualcomm.com?part=2