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

[PATCH 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 above and should be applied
on top of it.

Depends-on: https://lore.kernel.org/all/20260917-x1e-camss-csi2-phy-dtsi-v7-0-1a63eb35838b@linaro.org/

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 | 148 ++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/monaco.dtsi | 114 +++++++++++++++++
 3 files changed, 434 insertions(+)
--
base-commit: 37dc35244bd8c6be6d79a6ac591d14c660822dd1
change-id: 20260226-x1e-camss-csi2-phy-dtsi-52c85c0d4da8

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

[PATCH 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.

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

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

diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 695eae1b7256..a92a06a5d486 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -5166,6 +5166,154 @@ cci3_i2c1: i2c-bus@1 {
 			};
 		};
 
+		csiphy0: phy@ac9c000 {
+			compatible = "qcom,sa8775p-csi2-phy";
+			reg = <0x0 0x0ac9c000 0x0 0x2000>;
+
+			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
+				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
+			clock-names = "core",
+				      "timer",
+				      "csiphy_rx";
+
+			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>,
+				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
+			clock-names = "core",
+				      "timer",
+				      "csiphy_rx";
+
+			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>,
+				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
+			clock-names = "core",
+				      "timer",
+				      "csiphy_rx";
+
+			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>,
+				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
+			clock-names = "core",
+				      "timer",
+				      "csiphy_rx";
+
+			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>;
+				};
+			};
+		};
+
+		csiphy_opp_table: opp-table-csiphy {
+			compatible = "operating-points-v2";
+
+			opp-300000000 {
+				opp-hz = /bits/ 64 <300000000>;
+			};
+
+			opp-400000000 {
+				opp-hz = /bits/ 64 <400000000>;
+			};
+		};
+
 		camss: isp@ac78000 {
 			compatible = "qcom,sa8775p-camss";
 
-- 
2.34.1

Re: [PATCH 1/3] arm64: dts: qcom: lemans: add CSI2 D-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: lemans: duplicate MMIO and IRQ resources in csiphy0..3
- [Medium] arm64: dts: qcom: lemans: undocumented compatible and missing csiphy driver
- [Medium] arm64: dts: qcom: lemans: missing #phy-cells in csiphy0..3 provider nodes
- [Medium] arm64: dts: qcom: lemans: invalid csiphy_opp_table bus placement and 300MHz OPP
--

commit 86878cdbb9d7bba4aeea8079cca2e39342692dee
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 provider nodes
(csiphy0..3) and a shared csiphy_opp_table to arch/arm64/boot/dts/qcom/lemans.dtsi,
while leaving the existing CSIPHY resources on the camss node unchanged.

> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 695eae1b72569..a92a06a5d4865 100644
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
> @@ -5166,6 +5166,154 @@ cci3_i2c1: i2c-bus@1 {
>  			};
>  		};
>  
> +		csiphy0: phy@ac9c000 {
> +			compatible = "qcom,sa8775p-csi2-phy";
> +			reg = <0x0 0x0ac9c000 0x0 0x2000>;

[Severity: Medium]
Does this depend on a binding and driver series that has not been merged yet?

The compatible string qcom,sa8775p-csi2-phy (used on csiphy0, csiphy1,
csiphy2, and csiphy3) is not documented anywhere under
Documentation/devicetree/bindings/, and no driver in drivers/phy/ or
drivers/media/ matches it. Currently,
Documentation/devicetree/bindings/media/qcom,sa8775p-camss.yaml defines the
CSIPHY resources inside the qcom,sa8775p-camss node.

In addition, the commit message mentions that camss_detect_legacy_phy()
selects the non-legacy path when a sensor is wired through one of these
nodes, but camss_detect_legacy_phy() does not exist in the tree. In
drivers/media/platform/qcom/camss/camss.c, camss_parse_ports(),
camss_subdev_notifier_complete(), and camss_find_sensor_pad() expect camss
ports to connect directly to a MEDIA_ENT_F_CAM_SENSOR subdevice:

drivers/media/platform/qcom/camss/camss.c:camss_find_sensor_pad() {
	while (1) {
		pad = &entity->pads[0];
		if (!(pad->flags & MEDIA_PAD_FL_SINK))
			return NULL;

		pad = media_pad_remote_pad_first(pad);
		if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
			return NULL;

		entity = pad->entity;

		if (entity->function == MEDIA_ENT_F_CAM_SENSOR)
			return pad;
	}
}

Will this cause dtbs_check failures and prevent boards that enable csiphy0..3
from probing a PHY driver or linking the media pipeline?

[Severity: Medium]
Should csiphy0..csiphy3 also include a #phy-cells property?

Because these nodes are generic PHY providers,
Documentation/devicetree/bindings/phy/phy-bindings.txt requires #phy-cells on
each provider node, and other phy@... nodes in
arch/arm64/boot/dts/qcom/lemans.dtsi specify #phy-cells = <0>. In
drivers/phy/phy-core.c, _of_phy_get() looks up #phy-cells when resolving a
PHY phandle:

drivers/phy/phy-core.c:_of_phy_get() {
	ret = of_parse_phandle_with_args(np, "phys", "#phy-cells",
		index, &args);
	if (ret)
		return ERR_PTR(-ENODEV);
}

Without #phy-cells on csiphy0..csiphy3, won't _of_phy_get() fail with
-ENODEV and dtbs_check report schema validation errors?

> +
> +			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> +				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> +				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
> +			clock-names = "core",
> +				      "timer",
> +				      "csiphy_rx";
> +
> +			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;

[Severity: High]
When a board enables both camss and one of csiphy0..csiphy3, won't the
duplicate MMIO and interrupt assignments cause probe failures with -EBUSY?

Here, csiphy0..csiphy3 claim MMIO regions 0xac9c000, 0xac9e000, 0xaca0000,
and 0xaca2000 (size 0x2000 each) and GIC_SPI interrupts 477, 478, 479, and
448, while the camss node (isp@ac78000) in
arch/arm64/boot/dts/qcom/lemans.dtsi retains the exact same MMIO ranges and
interrupts for csiphy0..csiphy3.

In drivers/media/platform/qcom/camss/camss.c, sa8775p_resources defines all 4
CSIPHY entries, and camss_probe() -> camss_init_subdevices() unconditionally
initializes every one of them:

drivers/media/platform/qcom/camss/camss.c:camss_init_subdevices() {
	for (i = 0; i < camss->res->csiphy_num; i++) {
		ret = msm_csiphy_subdev_init(camss, &camss->csiphy[i],
					     &res->csiphy_res[i],
					     res->csiphy_res[i].csiphy.id);
}

msm_csiphy_subdev_init() then requests exclusive ownership of the memory
region and a non-shared interrupt for each CSIPHY:

drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init() {
	csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
	if (IS_ERR(csiphy->base))
		return PTR_ERR(csiphy->base);
	...
	ret = devm_request_irq(dev, csiphy->irq, csiphy->res->hw_ops->isr,
			       IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN,
			       csiphy->irq_name, csiphy);
}

Won't this conflict whenever a standalone csiphy0..csiphy3 driver and camss
are both active?

[ ... ]

> +		csiphy_opp_table: opp-table-csiphy {
> +			compatible = "operating-points-v2";
> +
> +			opp-300000000 {
> +				opp-hz = /bits/ 64 <300000000>;
> +			};
> +
> +			opp-400000000 {
> +				opp-hz = /bits/ 64 <400000000>;
> +			};
> +		};
> +
>  		camss: isp@ac78000 {
>  			compatible = "qcom,sa8775p-camss";

[Severity: Medium]
Are the placement and frequencies of csiphy_opp_table valid for SA8775P?

First, csiphy_opp_table (opp-table-csiphy) is placed directly inside soc@0
(which has compatible = "simple-bus" with #address-cells = <2> and
#size-cells = <2>) without a unit address, reg, or ranges property, whereas
shared OPP tables in arch/arm64/boot/dts/qcom/lemans.dtsi (such as
qup_opp_table_100mhz) are placed under the root node or inside consumer
device nodes. Also, phy@ac9c000..phy@aca2000 are placed before isp@ac78000
even though 0xac9c000 > 0xac78000.

Second, csiphy_opp_table includes opp-300000000 (300 MHz), and csiphy0..3
list CAM_CC_CSIPHY0..3_CLK as the first clock in clocks (which the OPP core
scales by default). In drivers/clk/qcom/camcc-sa8775p.c, both
cam_cc_cphy_rx_clk_src (parent of CAM_CC_CSIPHY0..3_CLK and
CAM_CC_CSID_CSIPHY_RX_CLK) and cam_cc_csi0..3phytimer_clk_src use
ftbl_cam_cc_cphy_rx_clk_src, which only supports 400 MHz:

drivers/clk/qcom/camcc-sa8775p.c:
static const struct freq_tbl ftbl_cam_cc_cphy_rx_clk_src[] = {
	F(400000000, P_CAM_CC_PLL0_OUT_ODD, 1, 0, 0),
	{ }
};

Should csiphy_opp_table be moved out of soc@0 (with phy@ac9c000..phy@aca2000
ordered after isp@ac78000), and is the 300 MHz OPP supported by the SA8775P
CAMCC clock driver?

[ ... ]

>

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

[PATCH 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.

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

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

diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 395d32d36844..166861146074 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -5562,6 +5562,120 @@ 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>,
+				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
+			clock-names = "core",
+				      "timer",
+				      "csiphy_rx";
+
+			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>,
+				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
+			clock-names = "core",
+				      "timer",
+				      "csiphy_rx";
+
+			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>,
+				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
+			clock-names = "core",
+				      "timer",
+				      "csiphy_rx";
+
+			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>;
+				};
+			};
+		};
+
+		csiphy_opp_table: opp-table-csiphy {
+			compatible = "operating-points-v2";
+
+			opp-300000000 {
+				opp-hz = /bits/ 64 <300000000>;
+			};
+
+			opp-400000000 {
+				opp-hz = /bits/ 64 <400000000>;
+			};
+		};
+
 		camss: isp@ac78000 {
 			compatible = "qcom,qcs8300-camss";
 
-- 
2.34.1

Re: [PATCH 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 csiphy compatible and camss conflict
- [Medium] arm64: dts: qcom: monaco: missing #phy-cells on csiphy0..2 provider nodes
- [Medium] arm64: dts: qcom: monaco: unsupported 300 MHz OPP in csiphy_opp_table
- [Low] arm64: dts: qcom: monaco: csiphy_opp_table placed inside simple-bus soc@0
--

commit 6a19d429f6610cefdfd6dfc21d55e9665c60129f
Author: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>

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

This commit adds standalone qcom,qcs8300-csi2-phy device tree nodes
(csiphy0..2) and an associated operating points table (csiphy_opp_table)
to arch/arm64/boot/dts/qcom/monaco.dtsi.

> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index cfe39f923224f..3d173a017122e 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -5563,6 +5563,120 @@ 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>,
> +				 <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>;
> +			clock-names = "core",
> +				      "timer",
> +				      "csiphy_rx";
> +
> +			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;

[Severity: High]
How are csiphy0, csiphy1, and csiphy2 expected to bind and coexist with the
camss node when enabled by a board or overlay?

First, the compatible string "qcom,qcs8300-csi2-phy" does not appear to be
documented under Documentation/devicetree/bindings/ or matched by any driver
in drivers/phy/ or drivers/media/, which will cause dtbs_check failures and
leave the nodes unbound.

Second, the commit message mentions that camss_detect_legacy_phy() selects
the non-legacy path while leaving the CSIPHY resources in the camss node
(isp@ac78000) intact, but camss_detect_legacy_phy() does not exist in the
tree. Instead, camss_probe() -> camss_init_subdevices() in
drivers/media/platform/qcom/camss/camss.c unconditionally initializes all
CSIPHY entries in qcs8300_resources:

drivers/media/platform/qcom/camss/camss.c:camss_init_subdevices() {
	for (i = 0; i < camss->res->csiphy_num; i++) {
		ret = msm_csiphy_subdev_init(camss, &camss->csiphy[i],
					     &res->csiphy_res[i],
					     res->csiphy_res[i].csiphy.id);
}

And msm_csiphy_subdev_init() in
drivers/media/platform/qcom/camss/camss-csiphy.c exclusively requests the
same MMIO regions (0xac9c000, 0xac9e000, 0xaca0000) and non-shared interrupts
(GIC_SPI 477..479):

drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init() {
	csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
	if (IS_ERR(csiphy->base))
		return PTR_ERR(csiphy->base);
	...
	ret = devm_request_irq(dev, csiphy->irq, csiphy->ops->isr,
			       IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN,
			       csiphy->irq_name, csiphy);
}

Wouldn't enabling any of csiphy0..2 alongside camss result in -EBUSY MMIO and
IRQ resource conflicts unless the dependent driver and binding patches are
present?

> +
> +			operating-points-v2 = <&csiphy_opp_table>;
> +
> +			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +			power-domain-names = "top";
> +
> +			status = "disabled";

[Severity: Medium]
Should csiphy0, csiphy1, and csiphy2 also include the #phy-cells property?

Because these nodes are named phy@... and described as generic-PHY provider
nodes, the phy-provider.yaml schema requires #phy-cells, and at runtime
_of_phy_get() in drivers/phy/phy-core.c requires it when resolving a phys
phandle:

drivers/phy/phy-core.c:_of_phy_get() {
	ret = of_parse_phandle_with_args(np, "phys", "#phy-cells",
		index, &args);
	if (ret)
		return ERR_PTR(-ENODEV);
}

Without #phy-cells on csiphy0..2, won't dtbs_check fail and _of_phy_get()
return ERR_PTR(-ENODEV) for any consumer referencing these providers?

[ ... ]

> +		csiphy_opp_table: opp-table-csiphy {
> +			compatible = "operating-points-v2";
> +
> +			opp-300000000 {
> +				opp-hz = /bits/ 64 <300000000>;
> +			};
> +
> +			opp-400000000 {
> +				opp-hz = /bits/ 64 <400000000>;
> +			};
> +		};
> +
>  		camss: isp@ac78000 {
>  			compatible = "qcom,qcs8300-camss";
>  

[Severity: Medium]
Is the 300 MHz entry (opp-300000000) in csiphy_opp_table supported by the
QCS8300 CAMCC clock driver?

In drivers/clk/qcom/camcc-sa8775p.c, the parent RCGs for these clocks
(cam_cc_cphy_rx_clk_src and cam_cc_csi0phytimer_clk_src through
cam_cc_csi2phytimer_clk_src) all use ftbl_cam_cc_cphy_rx_clk_src, which only
defines a 400 MHz frequency entry:

drivers/clk/qcom/camcc-sa8775p.c:
static const struct freq_tbl ftbl_cam_cc_cphy_rx_clk_src[] = {
	F(400000000, P_CAM_CC_PLL0_OUT_ODD, 1, 0, 0),
	{ }
};

Similarly, csiphy_res_8300 in drivers/media/platform/qcom/camss/camss.c only
lists 400000000 Hz for the QCS8300 CSIPHY clocks. Will requesting the 300 MHz
OPP fail clock rate lookup or round up to 400 MHz?

[Severity: Low]
Also, should csiphy_opp_table be placed under the root node (alongside
cpu0_opp_table and qup_opp_table) rather than directly inside soc@0, and
should phy@ac9c000..phy@aca0000 be placed after isp@ac78000 to maintain
unit-address ordering?

Because soc@0 is a simple-bus node with #address-cells = <2> and
#size-cells = <2>, placing opp-table-csiphy inside soc@0 without reg or
ranges triggers the check_simple_bus_reg() warning in scripts/dtc/checks.c
and fails simple-bus schema validation.

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

[PATCH 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.

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

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 347815e5983e..20b43b7625b6 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -5151,6 +5151,178 @@ 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>;
+				};
+			};
+		};
+
+		csiphy_opp_table: opp-table-csiphy {
+			compatible = "operating-points-v2";
+
+			opp-300000000 {
+				opp-hz = /bits/ 64 <300000000>;
+			};
+
+			opp-400000000 {
+				opp-hz = /bits/ 64 <400000000>;
+			};
+		};
+
 		camss: isp@acb3000 {
 			compatible = "qcom,sc7280-camss";
 
-- 
2.34.1

Re: [PATCH 3/3] arm64: dts: qcom: kodiak: add CSI2 D-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: kodiak: duplicate CSIPHY MMIO and IRQ with camss node
- [Medium] arm64: dts: qcom: kodiak: undocumented qcom,sc7280-csi2-phy compatible
- [Medium] arm64: dts: qcom: kodiak: missing #phy-cells in csiphy0..4 provider nodes
- [Low] arm64: dts: qcom: kodiak: opp-table-csiphy placed inside simple-bus soc@0
--

commit 8059004601c54f69c5b842a91e910a3594ccac37
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 qcom,sc7280-csi2-phy device tree nodes
(csiphy0 through csiphy4) and a shared opp-table-csiphy operating points
table to arch/arm64/boot/dts/qcom/kodiak.dtsi, disabled by default.

> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index f2da3706d5c88..bdac6b149aee8 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5151,6 +5151,178 @@ cci1_i2c1: i2c-bus@1 {
>  			};
>  		};
>  
> +		csiphy0: phy@ace0000 {
> +			compatible = "qcom,sc7280-csi2-phy";
> +			reg = <0x0 0x0ace0000 0x0 0x2000>;

[Severity: Medium]
Is there a Devicetree binding schema or driver series that this patch depends
on?

Neither Documentation/devicetree/bindings/ nor drivers/ in the tree contains
the compatible string qcom,sc7280-csi2-phy (repeated on csiphy0 through
csiphy4), and camss_detect_legacy_phy() referenced in the commit message does
not exist in drivers/media/platform/qcom/camss/. Running dtbs_check fails on
the undocumented compatible string, and enabling any of csiphy0..csiphy4 at
runtime leaves the platform device unbound.

> +
> +			clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> +				 <&camcc CAM_CC_CSI0PHYTIMER_CLK>;
> +			clock-names = "core",
> +				      "timer";
> +
> +			interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;

[Severity: High]
Will enabling any of csiphy0 through csiphy4 alongside camss cause a resource
conflict (-EBUSY) during probe?

The standalone csiphy0..csiphy4 nodes declare the same MMIO ranges
(0x0ace0000, 0x0ace2000, 0x0ace4000, 0x0ace6000, and 0x0ace8000) and GIC_SPI
interrupts (477, 478, 479, 448, and 122) that remain listed in the sibling
camss node (isp@acb3000):

arch/arm64/boot/dts/qcom/kodiak.dtsi:
		camss: isp@acb3000 {
			compatible = "qcom,sc7280-camss";

			reg = <0x0 0x0acb3000 0x0 0x1000>,
			      <0x0 0x0acba000 0x0 0x1000>,
			      <0x0 0x0acc1000 0x0 0x1000>,
			      <0x0 0x0acc8000 0x0 0x1000>,
			      <0x0 0x0accf000 0x0 0x1000>,
			      <0x0 0x0ace0000 0x0 0x2000>,
			      <0x0 0x0ace2000 0x0 0x2000>,
			      <0x0 0x0ace4000 0x0 0x2000>,
			      <0x0 0x0ace6000 0x0 0x2000>,
			      <0x0 0x0ace8000 0x0 0x2000>,

During camss_probe() -> camss_init_subdevices(), the CAMSS driver
unconditionally iterates over all camss->res->csiphy_num entries:

drivers/media/platform/qcom/camss/camss.c:camss_init_subdevices() {
	for (i = 0; i < camss->res->csiphy_num; i++) {
		ret = msm_csiphy_subdev_init(camss, &camss->csiphy[i],
					     &res->csiphy_res[i],
					     res->csiphy_res[i].csiphy.id);
}

And msm_csiphy_subdev_init() claims exclusive ownership of each memory region
and non-shared interrupt line:

drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init() {
	csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
	if (IS_ERR(csiphy->base))
		return PTR_ERR(csiphy->base);
	...
	ret = devm_request_irq(dev, csiphy->irq, csiphy->res->hw_ops->isr,
			       IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN,
			       csiphy->irq_name, csiphy);
}

> +
> +			operating-points-v2 = <&csiphy_opp_table>;
> +
> +			power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +			power-domain-names = "top";
> +
> +			status = "disabled";

[Severity: Medium]
Should csiphy0 through csiphy4 include #phy-cells = <0>?

Because these nodes are named phy@ace0000 through phy@ace8000 and act as
generic-PHY providers, phy-provider.yaml requires #phy-cells during
dtbs_check, and _of_phy_get() in drivers/phy/phy-core.c requires #phy-cells
when resolving a PHY phandle:

drivers/phy/phy-core.c:_of_phy_get() {
	ret = of_parse_phandle_with_args(np, "phys", "#phy-cells",
		index, &args);
	if (ret)
		return ERR_PTR(-ENODEV);
}

[ ... ]

> +		csiphy_opp_table: opp-table-csiphy {
> +			compatible = "operating-points-v2";
> +
> +			opp-300000000 {
> +				opp-hz = /bits/ 64 <300000000>;
> +			};
> +
> +			opp-400000000 {
> +				opp-hz = /bits/ 64 <400000000>;
> +			};
> +		};
> +
>  		camss: isp@acb3000 {
>  			compatible = "qcom,sc7280-camss";
>  

[Severity: Low]
Should csiphy_opp_table: opp-table-csiphy be placed under the root node
(alongside qspi_opp_table and qup_opp_table) rather than inside soc: soc@0,
and should phy@ace0000..phy@ace8000 be ordered after isp@acb3000?

Because soc: soc@0 has compatible = "simple-bus", placing opp-table-csiphy
without a reg or ranges property inside it triggers dtc simple_bus_reg
warnings (under W=1) and simple-bus.yaml schema validation errors in
dtbs_check. Also, unit addresses 0x0ace0000..0x0ace8000 sort after
isp@acb3000.

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