[PATCH v3 0/3] arm64: dts: qcom: Add CSI2 PHY common-phy providers for SA8775P, QCS8300 and SC7280

[PATCH v3 0/3] arm64: dts: qcom: Add CSI2 PHY common-phy providers for SA8775P, QCS8300 and SC7280

[Anusha Arun Nandi]

This series adds devicetree nodes for the generic Qualcomm MIPI CSI2
PHY driver on the three platforms whose compatibles/soc_cfg were added
by the companion "phy: qcom-mipi-csi2: Add D-PHY support for SA8775P,
QCS8300 and SC7280".

Each CSIPHY is exposed as a standalone generic-PHY provider node at
its existing register address, with its own OF graph (port@0
sensor-facing, port@1 CAMSS-facing), so that camss_detect_legacy_phy()
picks the non-legacy path once a board wires a sensor through one of
them. The camss node's own reg-names/clocks/interrupts for the
CSIPHYs are left unchanged, so boards that don't use a provider still
fall back to the legacy in-driver CSIPHY handling. All provider nodes
are added disabled by default; a board or camera overlay enables the
one(s) it actually uses.

The three patches are otherwise independent and split one-per-SoC
since each touches a different dtsi file:

 - Patch 1 adds the four SA8775P CSIPHYs (csiphy0-3) as
   qcom,sa8775p-csi2-phy nodes.

 - Patch 2 adds the three QCS8300 CSIPHYs (csiphy0-2) as
   qcom,qcs8300-csi2-phy nodes.

 - Patch 3 adds the five SC7280 CSIPHYs (csiphy0-4) as
   qcom,sc7280-csi2-phy nodes.

This series depends on the compatible strings and soc_cfg entries
introduced by the driver series referenced below and should be applied
on top of it.

Depends-on: https://lore.kernel.org/all/20261105235137.2635442-1-anusha.nandi@oss.qualcomm.com/
Depends-on: https://lore.kernel.org/all/20261102213936.1251316-1-anusha.nandi@oss.qualcomm.com/

Changes in v3:
- Patch 1 (lemans): moved csiphy_opp_table out of the soc@0 simple-bus
  to the root node (a simple-bus's direct children need reg/ranges,
  which an OPP table has neither of), dropped the opp-300000000 entry
  (SA8775P's camcc only defines a 400 MHz rate for this clock, so it
  was unreachable), and reordered csiphy0..3 after camss so soc@0's
  children stay sorted by ascending unit address.
- Patch 2 (monaco): same csiphy_opp_table root-node move, and dropped
  both the opp-300000000 entry and the extra "csiphy_rx" clock from
  csiphy0..2 (QCS8300 binds through the sa8775p soc_cfg, which only
  declares two clocks, "core"/"timer", for this PHY).
- Patch 3 (kodiak): same csiphy_opp_table root-node move; its
  opp-300000000 and opp-400000000 entries are both kept, since
  SC7280's camcc genuinely supports both rates for this clock.

Link: https://lore.kernel.org/all/20261103221026.3662383-1-anusha.nandi@oss.qualcomm.com/

Changes in v2:
- Patch 1 (lemans): dropped the extra "csiphy_rx" clock from
  csiphy0..3 (3 clocks -> 2: "core", "timer"), matching the driver's
  sa8775p soc_cfg, which only declares two clocks for this SoC family.
- The "undocumented compatible" and "camss_detect_legacy_phy() does
  not exist" comments on all three patches were resolved by the
  companion phy-driver/binding series and CAMSS work landing, not by
  a change to these dtsi patches themselves.
- Patches 2 (monaco) and 3 (kodiak) are otherwise unchanged from v1.

Link: https://lore.kernel.org/all/20261017001116.2318647-1-anusha.nandi@oss.qualcomm.com/

Anusha Arun Nandi (3):
  arm64: dts: qcom: lemans: add CSI2 D-PHY common-phy providers
  arm64: dts: qcom: monaco: add CSI2 PHY common-phy providers
  arm64: dts: qcom: kodiak: add CSI2 D-PHY common-phy providers

 arch/arm64/boot/dts/qcom/kodiak.dtsi | 172 +++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/lemans.dtsi | 136 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/monaco.dtsi | 104 ++++++++++++++++
 3 files changed, 412 insertions(+)

Best regards,
-- 
Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
-- 
2.34.1

[PATCH v3 1/3] arm64: dts: qcom: lemans: add CSI2 D-PHY common-phy providers

[Anusha Arun Nandi]

Expose the four SA8775p CSIPHYs as standalone qcom,sa8775p-csi2-phy
generic-PHY provider nodes (csiphy0..3) at their existing register
addresses, each with its own OF graph (port@0 sensor-facing, port@1
CAMSS-facing) so camss_detect_legacy_phy() picks the non-legacy path
once a board wires a sensor through one of them. The camss node's own
reg-names/clocks/interrupts for the CSIPHYs are unchanged, so boards
that don't use a provider still get the legacy binding.

csiphy0..3 are placed after camss (ac78000 < ac9c000..aca2000), so
soc@0's children stay sorted by ascending unit address. Their shared
OPP table lives at the root node, not inside soc@0 (a simple-bus),
since it has no reg/ranges property of its own; it only lists
400000000 Hz, the one rate SA8775P's camcc clock driver actually
supports for this clock (ftbl_cam_cc_cphy_rx_clk_src has no 300 MHz
entry).

The provider nodes are disabled by default; a board or camera overlay
enables the one(s) it uses.

Reviewed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/lemans.dtsi | 136 +++++++++++++++++++++++++++
 1 file changed, 136 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 1fdb72fa5518..6909dfa06d86 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -545,6 +545,14 @@ opp-100000000 {
 		};
 	};
 
+	csiphy_opp_table: opp-table-csiphy {
+		compatible = "operating-points-v2";
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+		};
+	};
+
 	pmu {
 		compatible = "arm,armv8-pmuv3";
 		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
@@ -5348,6 +5356,134 @@ port@3 {
 			};
 		};
 
+		csiphy0: phy@ac9c000 {
+			compatible = "qcom,sa8775p-csi2-phy";
+			reg = <0x0 0x0ac9c000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
+				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy1: phy@ac9e000 {
+			compatible = "qcom,sa8775p-csi2-phy";
+			reg = <0x0 0x0ac9e000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY1_CLK>,
+				 <&camcc CAM_CC_CSI1PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy2: phy@aca0000 {
+			compatible = "qcom,sa8775p-csi2-phy";
+			reg = <0x0 0x0aca0000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY2_CLK>,
+				 <&camcc CAM_CC_CSI2PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy3: phy@aca2000 {
+			compatible = "qcom,sa8775p-csi2-phy";
+			reg = <0x0 0x0aca2000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY3_CLK>,
+				 <&camcc CAM_CC_CSI3PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
 		camcc: clock-controller@ade0000 {
 			compatible = "qcom,sa8775p-camcc";
 			reg = <0x0 0x0ade0000 0x0 0x20000>;
-- 
2.34.1

Re: [PATCH v3 1/3] arm64: dts: qcom: lemans: add CSI2 D-PHY common-phy providers

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: lemans: undocumented qcom,sa8775p-csi2-phy compatible
- [Medium] arm64: dts: qcom: lemans: single power-domain in csiphy0..3 causes -EEXIST
--

commit 03beee1895ec9b19424b0689817a5a264d09433f
Author: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>

arm64: dts: qcom: lemans: add CSI2 D-PHY common-phy providers

This commit adds four standalone qcom,sa8775p-csi2-phy generic-PHY provider
nodes (csiphy0..3) and their shared OPP table to lemans.dtsi so boards can
wire camera sensors through the non-legacy CAMSS PHY path.

> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 1fdb72fa55184..6909dfa06d867 100644
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi

[ ... ]

> @@ -5348,6 +5356,134 @@ port@3 {
>  			};
>  		};
>  
> +		csiphy0: phy@ac9c000 {
> +			compatible = "qcom,sa8775p-csi2-phy";

[Severity: Medium]
As reported by Sashiko on v1 [1], is there a devicetree binding update and
driver support accompanying qcom,sa8775p-csi2-phy (used on csiphy0..csiphy3)?

In Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml, only
qcom,x1e80100-csi2-phy and qcom,glymur-csi2-phy are documented, so dtbs_check
will fail on these nodes.

In addition, phy_qcom_mipi_csi2_of_match_table in
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c only matches
qcom,x1e80100-csi2-phy:

static const struct of_device_id phy_qcom_mipi_csi2_of_match_table[] = {
	{ .compatible	= "qcom,x1e80100-csi2-phy", .data = &mipi_csi2_dphy_4nm_x1e },
	{ }
};

When a board or overlay enables one of csiphy0..csiphy3 and wires a sensor
endpoint through it, camss_probe() -> camss_init_subdevices() ->
camss_detect_legacy_phy() in drivers/media/platform/qcom/camss/camss.c sees
the remote port parent node named phy and sets camss->legacy_phy = false.
Then msm_csiphy_subdev_init() in
drivers/media/platform/qcom/camss/camss-csiphy.c calls
devm_phy_get_by_of_node(dev, remote):

	csiphy->phy = devm_phy_get_by_of_node(dev, remote);
	of_node_put(remote);
	if (IS_ERR(csiphy->phy)) {
		ret = PTR_ERR(csiphy->phy);
		goto done;
	}

Without a driver matching qcom,sa8775p-csi2-phy to register a PHY provider
(and a corresponding 5nm v1.3.0 PHY configuration in
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c), won't
devm_phy_get_by_of_node() return -EPROBE_DEFER indefinitely?

> +			reg = <0x0 0x0ac9c000 0x0 0x2000>;
> +
> +			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> +				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
> +			clock-names = "core",
> +				      "timer";
> +
> +			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
> +
> +			operating-points-v2 = <&csiphy_opp_table>;
> +
> +			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +			power-domain-names = "top";

[Severity: Medium]
As reported by Sashiko on v2 [2], will phy_qcom_mipi_csi2_probe() fail with
-EEXIST when power-domains only contains a single entry on csiphy0..csiphy3?

When a platform device has a single power-domains entry in DT,
platform_probe() -> dev_pm_domain_attach() -> genpd_dev_pm_attach() in
drivers/pmdomain/core.c attaches that domain directly to dev->pm_domain before
the driver's probe callback runs:

	if (of_count_phandle_with_args(dev->of_node, "power-domains",
				       "#power-domain-cells") != 1)
		return 0;

	return __genpd_dev_pm_attach(dev, dev, 0, 1, true);

When phy_qcom_mipi_csi2_probe() in
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c subsequently calls
phy_qcom_mipi_csi2_attach_pm_domains() -> devm_pm_domain_attach_list() ->
dev_pm_domain_attach_list() in drivers/base/power/common.c:

	if (dev->pm_domain)
		return -EEXIST;

dev_pm_domain_attach_list() returns -EEXIST because dev->pm_domain is already
set, causing phy_qcom_mipi_csi2_probe() to fail. Furthermore, both
Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml and
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c expect three power domains
(top, mmcx, mx) and three clocks (core, timer, ahb).

[1] https://lore.kernel.org/r/sashiko-outbox-175063@kernel.org
[2] https://lore.kernel.org/r/sashiko-outbox-196105@kernel.org

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106030212.2811027-1-anusha.nandi@oss.qualcomm.com?part=1

[PATCH v3 2/3] arm64: dts: qcom: monaco: add CSI2 PHY common-phy providers

[Anusha Arun Nandi]

Expose the three QCS8300 CSIPHYs as standalone
qcom,qcs8300-csi2-phy generic-PHY provider nodes (csiphy0..2) at their
existing register addresses, each with its own OF graph (port@0
sensor-facing, port@1 CAMSS-facing) so camss_detect_legacy_phy() picks
the non-legacy path once a board wires a sensor through one of them.
The camss node's own reg-names/clocks/interrupts for the CSIPHYs are
unchanged, so boards that don't use a provider still get the legacy
binding.

csiphy0..2 drop the extra "csiphy_rx" clock: QCS8300 binds through the
sa8775p soc_cfg (no dedicated QCS8300 camcc driver exists), which only
declares two clocks ("core", "timer") for this PHY, not three.

csiphy_opp_table moves to the root node, not inside soc@0 (a
simple-bus), since it has no reg/ranges property of its own; its
opp-300000000 entry is dropped too, since QCS8300 shares SA8775P's
camcc, whose cam_cc_cphy_rx_clk_src only defines a 400 MHz rate.

The provider nodes are disabled by default; a board or camera overlay
enables the one(s) it uses.

Reviewed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco.dtsi | 104 +++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 35fbee63d4c6..a66c04a1d306 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -644,6 +644,14 @@ opp-120000000 {
 		};
 	};
 
+	csiphy_opp_table: opp-table-csiphy {
+		compatible = "operating-points-v2";
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+		};
+	};
+
 	pmu-a55 {
 		compatible = "arm,cortex-a55-pmu";
 		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
@@ -5577,6 +5585,102 @@ cci2_i2c1: i2c-bus@1 {
 			};
 		};
 
+		csiphy0: phy@ac9c000 {
+			compatible = "qcom,qcs8300-csi2-phy";
+			reg = <0x0 0x0ac9c000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
+				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy1: phy@ac9e000 {
+			compatible = "qcom,qcs8300-csi2-phy";
+			reg = <0x0 0x0ac9e000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY1_CLK>,
+				 <&camcc CAM_CC_CSI1PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy2: phy@aca0000 {
+			compatible = "qcom,qcs8300-csi2-phy";
+			reg = <0x0 0x0aca0000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY2_CLK>,
+				 <&camcc CAM_CC_CSI2PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
 		camss: isp@ac78000 {
 			compatible = "qcom,qcs8300-camss";
 
-- 
2.34.1

Re: [PATCH v3 2/3] arm64: dts: qcom: monaco: add CSI2 PHY common-phy providers

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] arm64: dts: qcom: monaco: undocumented and unmatched qcom,qcs8300-csi2-phy
- [High] arm64: dts: qcom: monaco: single power-domain on csiphy0..2 causes -EEXIST
- [Low] arm64: dts: qcom: monaco: csiphy0..2 placed before camss out of address order
- [Low] arm64: dts: qcom: monaco: commit message describes inter-version deltas
--

commit 73bdfe66a74e3ebe09640aa912bd64a757bca278
Author: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>

arm64: dts: qcom: monaco: add CSI2 PHY common-phy providers

This commit adds an OPP table and three disabled standalone CSI2 PHY
provider nodes (csiphy0, csiphy1, and csiphy2) to the Qualcomm Monaco
(QCS8300) devicetree.

>     arm64: dts: qcom: monaco: add CSI2 PHY common-phy providers
>     
>     Expose the three QCS8300 CSIPHYs as standalone
>     qcom,qcs8300-csi2-phy generic-PHY provider nodes (csiphy0..2) at their
>     existing register addresses, each with its own OF graph (port@0
>     sensor-facing, port@1 CAMSS-facing) so camss_detect_legacy_phy() picks
>     the non-legacy path once a board wires a sensor through one of them.
>     The camss node's own reg-names/clocks/interrupts for the CSIPHYs are
>     unchanged, so boards that don't use a provider still get the legacy
>     binding.
>     
>     csiphy0..2 drop the extra "csiphy_rx" clock: QCS8300 binds through the
>     sa8775p soc_cfg (no dedicated QCS8300 camcc driver exists), which only
>     declares two clocks ("core", "timer") for this PHY, not three.
>     
>     csiphy_opp_table moves to the root node, not inside soc@0 (a
>     simple-bus), since it has no reg/ranges property of its own; its
>     opp-300000000 entry is dropped too, since QCS8300 shares SA8775P's
>     camcc, whose cam_cc_cphy_rx_clk_src only defines a 400 MHz rate.
>     
>     The provider nodes are disabled by default; a board or camera overlay
>     enables the one(s) it uses.
>     
>     Reviewed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
>     Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>

[Severity: Low]
This isn't a bug, but arch/arm64/boot/dts/qcom/monaco.dtsi did not previously
define csiphy0..2 or csiphy_opp_table. The second and third paragraphs
describe changes between patch revisions (dropping the csiphy_rx clock,
moving csiphy_opp_table to the root node, and dropping opp-300000000) as if
modifying existing definitions in the tree, and also refer to the CSI2 PHY
driver soc_cfg as a camcc driver.

Should the inter-version changelog notes be moved below the --- tear line so
the commit description only explains the final state being added?

> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 35fbee63d4c65..a66c04a1d3063 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi

[ ... ]

> @@ -5577,6 +5585,102 @@ cci2_i2c1: i2c-bus@1 {
>  			};
>  		};
>  
> +		csiphy0: phy@ac9c000 {
> +			compatible = "qcom,qcs8300-csi2-phy";
> +			reg = <0x0 0x0ac9c000 0x0 0x2000>;
> +
> +			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> +				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
> +			clock-names = "core",
> +				      "timer";

[Severity: High]
As reported by Sashiko on v2 [1], csiphy0, csiphy1, and csiphy2 declare
compatible = "qcom,qcs8300-csi2-phy" with two clocks and no fallback
compatible string such as "qcom,sa8775p-csi2-phy".

In Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml, only
qcom,x1e80100-csi2-phy and qcom,glymur-csi2-phy are documented, and three
clocks (core, timer, ahb) are required:

  compatible:
    oneOf:
      - const: qcom,x1e80100-csi2-phy
      - items:
          - const: qcom,glymur-csi2-phy
          - const: qcom,x1e80100-csi2-phy

In drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c,
phy_qcom_mipi_csi2_of_match_table only matches qcom,x1e80100-csi2-phy, and no
qcom,qcs8300-csi2-phy or sa8775p soc_cfg entry exists in the driver:

  static const struct of_device_id phy_qcom_mipi_csi2_of_match_table[] = {
  	{ .compatible	= "qcom,x1e80100-csi2-phy", .data = &mipi_csi2_dphy_4nm_x1e },
  	{ }
  };

When a board or overlay enables any of csiphy0..2 and wires a sensor endpoint
through it, camss_detect_legacy_phy() selects non-legacy PHY mode and
msm_csiphy_subdev_init() in drivers/media/platform/qcom/camss/camss-csiphy.c
calls devm_phy_get_by_of_node():

  	csiphy->phy = devm_phy_get_by_of_node(dev, remote);
  	of_node_put(remote);
  	if (IS_ERR(csiphy->phy)) {
  		ret = PTR_ERR(csiphy->phy);
  		goto done;
  	}

Without a matching PHY driver and binding schema, will dtbs_check fail on the
undocumented compatible string and camss_probe() defer indefinitely with
-EPROBE_DEFER whenever one of these PHY nodes is enabled?

> +
> +			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
> +
> +			operating-points-v2 = <&csiphy_opp_table>;
> +
> +			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +			power-domain-names = "top";

[Severity: High]
As reported by Sashiko on v2 [2], csiphy0, csiphy1, and csiphy2 each specify
only a single power-domains entry.

When a platform device has a single power-domains phandle, platform_probe()
calls dev_pm_domain_attach() -> genpd_dev_pm_attach() in
drivers/pmdomain/core.c, which attaches that domain to dev->pm_domain before
the driver's probe callback runs:

  	if (of_count_phandle_with_args(dev->of_node, "power-domains",
  				       "#power-domain-cells") != 1)
  		return 0;

  	return __genpd_dev_pm_attach(dev, dev, 0, 1, true);

When phy_qcom_mipi_csi2_probe() in
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c subsequently calls
phy_qcom_mipi_csi2_attach_pm_domains() -> devm_pm_domain_attach_list() ->
dev_pm_domain_attach_list() in drivers/base/power/common.c, it checks
dev->pm_domain and fails with -EEXIST:

  	if (dev->pm_domain)
  		return -EEXIST;

Furthermore, Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
and drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c expect three power
domains (top, mmcx, and mx). Will having a single power-domains entry cause
phy_qcom_mipi_csi2_probe() to fail unconditionally with -EEXIST?

[ ... ]

> +		csiphy2: phy@aca0000 {
> +			compatible = "qcom,qcs8300-csi2-phy";
> +			reg = <0x0 0x0aca0000 0x0 0x2000>;

[ ... ]

> +		};
> +
>  		camss: isp@ac78000 {
>  			compatible = "qcom,qcs8300-camss";

[Severity: Low]
As reported by Sashiko on v2 [3], this isn't a bug, but under soc@0 in
arch/arm64/boot/dts/qcom/monaco.dtsi, MMIO child nodes are ordered by
ascending unit address. Here csiphy0 (phy@ac9c000), csiphy1 (phy@ac9e000),
and csiphy2 (phy@aca0000) are placed before camss (isp@ac78000) even though
0xac9c000..0xaca0000 are higher than 0xac78000.

Should csiphy0..2 be placed after camss: isp@ac78000 to maintain unit-address
order?

[1] https://lore.kernel.org/r/20261103221026.3662383-3-anusha.nandi@oss.qualcomm.com
[2] https://lore.kernel.org/r/20261103221026.3662383-3-anusha.nandi@oss.qualcomm.com
[3] https://lore.kernel.org/r/20261103221026.3662383-3-anusha.nandi@oss.qualcomm.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106030212.2811027-1-anusha.nandi@oss.qualcomm.com?part=2

[PATCH v3 3/3] arm64: dts: qcom: kodiak: add CSI2 D-PHY common-phy providers

[Anusha Arun Nandi]

Expose SC7280's five CSIPHYs as standalone
qcom,sc7280-csi2-phy generic-PHY provider nodes (csiphy0..4) at their
existing register addresses, each with its own OF graph (port@0
sensor-facing, port@1 CAMSS-facing) so camss_detect_legacy_phy() picks
the non-legacy path once a board wires a sensor through one of them.
The camss node's own reg-names/clocks/interrupts for the CSIPHYs are
unchanged, so boards that don't use a provider still get the legacy
binding.

csiphy_opp_table moves to the root node, not inside soc@0 (a
simple-bus), since it has no reg/ranges property of its own. Its
opp-300000000 and opp-400000000 entries are both kept unchanged: unlike
SA8775P/QCS8300, SC7280's cam_cc_cphy_rx_clk_src defines both rates.

The provider nodes are disabled by default; a board or camera overlay
enables the one(s) it uses.

Reviewed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 172 +++++++++++++++++++++++++++
 1 file changed, 172 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 8c7523602d27..e0e1fef7882e 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -968,6 +968,18 @@ opp-128000000 {
 		};
 	};
 
+	csiphy_opp_table: opp-table-csiphy {
+		compatible = "operating-points-v2";
+
+		opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+		};
+
+		opp-400000000 {
+			opp-hz = /bits/ 64 <400000000>;
+		};
+	};
+
 	soc: soc@0 {
 		#address-cells = <2>;
 		#size-cells = <2>;
@@ -5164,6 +5176,166 @@ cci1_i2c1: i2c-bus@1 {
 			};
 		};
 
+		csiphy0: phy@ace0000 {
+			compatible = "qcom,sc7280-csi2-phy";
+			reg = <0x0 0x0ace0000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
+				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy1: phy@ace2000 {
+			compatible = "qcom,sc7280-csi2-phy";
+			reg = <0x0 0x0ace2000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY1_CLK>,
+				 <&camcc CAM_CC_CSI1PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy2: phy@ace4000 {
+			compatible = "qcom,sc7280-csi2-phy";
+			reg = <0x0 0x0ace4000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY2_CLK>,
+				 <&camcc CAM_CC_CSI2PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy3: phy@ace6000 {
+			compatible = "qcom,sc7280-csi2-phy";
+			reg = <0x0 0x0ace6000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY3_CLK>,
+				 <&camcc CAM_CC_CSI3PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		csiphy4: phy@ace8000 {
+			compatible = "qcom,sc7280-csi2-phy";
+			reg = <0x0 0x0ace8000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY4_CLK>,
+				 <&camcc CAM_CC_CSI4PHYTIMER_CLK>;
+			clock-names = "core",
+				      "timer";
+
+			interrupts = <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>;
+
+			operating-points-v2 = <&csiphy_opp_table>;
+
+			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+			power-domain-names = "top";
+
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+				};
+
+				port@1 {
+					reg = <1>;
+				};
+			};
+		};
+
 		camss: isp@acb3000 {
 			compatible = "qcom,sc7280-camss";
 
-- 
2.34.1

Re: [PATCH v3 3/3] arm64: dts: qcom: kodiak: add CSI2 D-PHY common-phy providers

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: kodiak: undocumented qcom,sc7280-csi2-phy compatible
- [Medium] arm64: dts: qcom: kodiak: single power-domain on csiphy0..4 breaks probe
- [Low] arm64: dts: qcom: kodiak: csiphy0..4 placed out of unit-address order
--

commit 052b5f2483e5e0bfe39a886df72e88b30b2413ff
Author: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>

arm64: dts: qcom: kodiak: add CSI2 D-PHY common-phy providers

This commit adds five standalone CSI2 D-PHY generic-PHY provider nodes
(csiphy0 through csiphy4) and their operating points table to kodiak.dtsi
for SC7280.

> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 8c7523602d271..e0e1fef7882ec 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi

[ ... ]

> @@ -5164,6 +5176,166 @@ cci1_i2c1: i2c-bus@1 {
>  			};
>  		};
>  
> +		csiphy0: phy@ace0000 {
> +			compatible = "qcom,sc7280-csi2-phy";

[Severity: Medium]
As reported by Sashiko on v2 [1], is the qcom,sc7280-csi2-phy compatible
string used on csiphy0 through csiphy4 documented in the Devicetree
bindings or supported by a driver in the tree?

In Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml,
only qcom,x1e80100-csi2-phy and qcom,glymur-csi2-phy are listed:

  compatible:
    oneOf:
      - const: qcom,x1e80100-csi2-phy
      - items:
          - const: qcom,glymur-csi2-phy
          - const: qcom,x1e80100-csi2-phy

Likewise, phy_qcom_mipi_csi2_of_match_table in
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c only matches
qcom,x1e80100-csi2-phy:

static const struct of_device_id phy_qcom_mipi_csi2_of_match_table[] = {
	{ .compatible	= "qcom,x1e80100-csi2-phy", .data = &mipi_csi2_dphy_4nm_x1e },
	{ }
};

When a board or overlay enables one of csiphy0 through csiphy4 and connects
a sensor through it, camss_detect_legacy_phy() selects the non-legacy PHY
path and camss_init_subdevices() -> msm_csiphy_subdev_init() calls
devm_phy_get_by_of_node():

	csiphy->phy = devm_phy_get_by_of_node(dev, remote);
	of_node_put(remote);
	if (IS_ERR(csiphy->phy)) {
		ret = PTR_ERR(csiphy->phy);
		goto done;
	}

Without a matching PHY driver registered for qcom,sc7280-csi2-phy, will
dtbs_check fail validation and msm_csiphy_subdev_init() return
-EPROBE_DEFER indefinitely?

> +			reg = <0x0 0x0ace0000 0x0 0x2000>;
> +
> +			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> +				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
> +			clock-names = "core",
> +				      "timer";
> +
> +			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
> +
> +			operating-points-v2 = <&csiphy_opp_table>;
> +
> +			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +			power-domain-names = "top";

[Severity: Medium]
As reported by Sashiko on v2 [2], will specifying a single entry in
power-domains on csiphy0 through csiphy4 cause probing with the Qualcomm
MIPI CSI2 PHY driver to fail with -EEXIST?

When a platform device has a single power-domains entry,
platform_probe() -> dev_pm_domain_attach() -> genpd_dev_pm_attach()
attaches that domain directly to dev->pm_domain before invoking the
driver's probe callback:

	if (of_count_phandle_with_args(dev->of_node, "power-domains",
				       "#power-domain-cells") != 1)
		return 0;

	return __genpd_dev_pm_attach(dev, dev, 0, 1, true);

Subsequently, phy_qcom_mipi_csi2_probe() calls
phy_qcom_mipi_csi2_attach_pm_domains() -> devm_pm_domain_attach_list() ->
dev_pm_domain_attach_list(), which rejects devices that already have
dev->pm_domain populated:

	if (dev->pm_domain)
		return -EEXIST;

In addition, shouldn't csiphy0 through csiphy4 and csiphy_opp_table also
specify the RPMHPD voltage rail power domains and required-opps needed for
scaling between the 300 MHz and 400 MHz OPPs in
phy_qcom_mipi_csi2_set_clock_rates()?

[ ... ]

> +		csiphy4: phy@ace8000 {
> +			compatible = "qcom,sc7280-csi2-phy";
> +			reg = <0x0 0x0ace8000 0x0 0x2000>;

[ ... ]

> +		};
> +
>  		camss: isp@acb3000 {
>  			compatible = "qcom,sc7280-camss";

[Severity: Low]
As reported by Sashiko on v2 [3], this isn't a bug, but csiphy0 through
csiphy4 (phy@ace0000 through phy@ace8000) are placed before
camss: isp@acb3000 even though 0xace0000 is higher than 0xacb3000. Should
phy@ace0000 through phy@ace8000 be placed after isp@acb3000 (and before
camcc: clock-controller@ad00000) to keep the child nodes of soc@0 sorted
by unit address?

Also, the commit message states that csiphy_opp_table "moves to the root
node" and that its entries "are both kept unchanged", which describes
changes between patch revisions rather than against the baseline tree.

[1] https://lore.kernel.org/r/20261103221026.3662383-4-anusha.nandi@oss.qualcomm.com
[2] https://lore.kernel.org/r/20261103221026.3662383-4-anusha.nandi@oss.qualcomm.com
[3] https://lore.kernel.org/r/20261103221026.3662383-4-anusha.nandi@oss.qualcomm.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106030212.2811027-1-anusha.nandi@oss.qualcomm.com?part=3