Re: [PATCH v2 03/17] dt-bindings: display: spacemit: add K3 Innosilicon DP/eDP controller

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Probe deadlock and circular dependency due to the parent DP controller consuming a clock and PHY provided by its own child node.
--

--- Patch [3]: [PATCH v2 03/17] dt-bindings: display: spacemit: add K3 Innosilicon DP/eDP controller ---
commit ead86f1749dc824cd3f2b3c8dc8d28611bfc6866
Author: Cody Kang <[email protected]>

dt-bindings: display: spacemit: add K3 Innosilicon DP/eDP controller
    
This commit adds the device tree binding schema for the Innosilicon
DisplayPort transmit controller on the SpacemiT K3 SoC. It includes
definitions for the DP PHY child node which provides clocks and PHY
resources to the parent DP controller.

> diff --git a/Documentation/devicetree/bindings/display/spacemit/spacemit,k3-inno-dp.yaml b/Documentation/devicetree/bindings/display/spacemit/spacemit,k3-inno-dp.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/spacemit/spacemit,k3-inno-dp.yaml
[ ... ]
> +examples:
> +  - |
[ ... ]
> +        edp@cac84000 {
> +            compatible = "spacemit,k3-inno-dp";
> +            reg = <0x0 0xcac84000 0x0 0x4000>;
> +            interrupts = <132 IRQ_TYPE_LEVEL_HIGH>;
> +            clocks = <&syscon_apmu CLK_APMU_EDP0_PXCLK>, <&edp0_phy>;
> +            clock-names = "pxclk", "pll";
> +            resets = <&syscon_apmu RESET_APMU_EDP0>;
> +            phys = <&edp0_phy>;
> +            phy-names = "dp";
> +
> +            edp0_phy: phy {
> +                compatible = "spacemit,k3-inno-dp-phy";
> +                #phy-cells = <0>;
> +                #clock-cells = <0>;

[Severity: High]
Does modeling the PHY and clock resources this way create a circular probe
dependency?

The parent node references its own child node (edp0_phy) for both clocks
and phys. If the parent requests these resources via standard APIs during
its probe function, it will likely receive an indefinite -EPROBE_DEFER.

The child cannot probe and register its resources until the parent completes
enough of its own probe to populate its children.

Is there a specific driver sequence expected here to avoid this deadlock,
or should the hardware abstraction be represented differently to avoid the
self-referential phandles?

> +                clock-output-names = "edp0_pll_pxclk";
> +            };
[ ... ]

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

-- 
linux-phy mailing list
[email protected]
https://lists.infradead.org/mailman/listinfo/linux-phy