Re: [PATCH v3 1/3] dt-bindings: clock: qcom: Move x1e80100 TCSR to own binding

[email protected]
Newsgroups org.kernel.vger.linux-clk,org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The TCSR clock controller driver does not implement support for the newly added mandatory LDO supplies.
--

--- Patch [1]: [PATCH v3 1/3] dt-bindings: clock: qcom: Move x1e80100 TCSR to own binding ---
commit aad425dc59252c040c4a40218a6fd98a6935f85a
Author: Qiang Yu <[email protected]>

dt-bindings: clock: qcom: Move x1e80100 TCSR to own binding

This commit creates a dedicated binding file for the x1e80100 TCSR
clock controller to document newly required LDO supply properties.
These supplies are mandated for the QREF block to provide stable
reference clocks to PCIe, USB, and UFS PHYs.

> diff --git a/Documentation/devicetree/bindings/clock/qcom,x1e80100-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,x1e80100-tcsr.yaml
> new file mode 100644
> index 0000000000000..92fa416e7270b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,x1e80100-tcsr.yaml
> @@ -0,0 +1,120 @@
[ ... ]
> +  vdda-refgen2-0p9-supply: true
> +  vdda-refgen2-1p2-supply: true
> +
> +required:
> +  - compatible
> +  - clocks
> +  - '#clock-cells'
> +  - '#reset-cells'
> +  - vdda-qrefrpt0-0p9-supply

[Severity: High]
This is a pre-existing issue, but does the TCSR clock controller driver
actually implement support for these newly mandated LDO supplies?

Looking at drivers/clk/qcom/tcsrcc-x1e80100.c, the reference clocks are
modeled as standard clk_branch structures rather than qcom_clk_ref_desc 
objects that natively handle regulators:

    static struct clk_branch tcsr_edp_clkref_en = {
        .halt_reg = 0x15130,
        .halt_check = BRANCH_HALT_DELAY,
        .clkr = {
            .enable_reg = 0x15130,
            .enable_mask = BIT(0),
        ...
    };

Additionally, the driver relies on qcom_cc_probe(), which does not parse
or request these regulators.

Since the commit message notes that the USB/PCIe/eDP PHYs cannot work
properly without these LDOs, will the lack of driver support cause these
peripherals to unconditionally fail on boot when they request their clocks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.