From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: neil.armstrong@linaro.org, robh@kernel.org, olteanv@gmail.com,
conor+dt@kernel.org, vkoul@kernel.org, media-ci@linuxtv.org,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v19 10/12] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
Date: Thu, 08 Oct 2026 07:38:36 +0000 [thread overview]
Message-ID: <sashiko-outbox-163772@kernel.org> (raw)
In-Reply-To: <20261008-kaanapali-camss-v19-10-b2c583ef50e0@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dts: missing SoC-internal OF graph links between camss and standalone csiphy nodes
--
commit a63685b077e80fcbb61d58b04d437addeb277a93
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
This commit describes the CAMSS and CSIPHY blocks on the Kaanapali SoC.
It adds 6 CSIPHYs, 3 TPGs, 3 CSIDs, 2 CSID Lites, 3 VFEs, and 2 VFE Lites
to enable camera pipelines on board device trees.
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index e48a179d07220..7e5106865e7ee 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
[ ... ]
> @@ -3597,6 +3598,307 @@ usb_dp_qmpphy_dp_in: endpoint {
> };
> };
>
> + camss: isp@9253000 {
> + compatible = "qcom,kaanapali-camss";
[ ... ]
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + };
> +
> + port@1 {
> + reg = <1>;
> + };
[Severity: High]
Will the CAMSS driver be able to find the CSIPHY devices with these empty
port definitions?
The CAMSS driver (msm_csiphy_subdev_init in camss-csiphy.c) discovers its
PHYs by traversing the OF graph using of_graph_get_endpoint_by_regs on the
camss node's ports, following it to the remote endpoint's parent, and calling
devm_phy_get_by_of_node.
Because these ports lack endpoint definitions linking back to the CSIPHY
outputs, the lookup will return NULL and silently skip PHY initialization.
This leaves the phy uninitialized and prevents the PHYs from powering on
during streaming.
[ ... ]
> + };
> + };
> +
> + csiphy0: phy@9523000 {
> + compatible = "qcom,kaanapali-csi2-phy";
> + reg = <0x0 0x09523000 0x0 0x2000>;
> +
> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
[Severity: High]
Does this standalone csiphy0 node also need a ports structure to define its
CAMSS output endpoint?
Without a ports definition in the csiphy nodes, the OF graph traversal from
the camss node cannot resolve the remote endpoint, breaking the internal
SoC routing required to initialize the PHYs.
Since these are hardwired SoC-internal connections between the PHY output
and the CAMSS input, shouldn't they be defined here in the .dtsi rather
than forcing downstream board .dts files to manually construct the internal
SoC routing?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008-kaanapali-camss-v19-0-b2c583ef50e0@oss.qualcomm.com?part=10
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-10-08 7:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 7:14 [PATCH v19 00/12] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2026-10-08 7:14 ` [PATCH v19 01/12] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY Hangxiang Ma
2026-10-08 7:14 ` [PATCH v19 02/12] phy: qcom-mipi-csi2: Parametrise the common status register offset Hangxiang Ma
2026-10-08 22:08 ` bod
2026-10-08 7:14 ` [PATCH v19 03/12] phy: qcom-mipi-csi2: Add Kaanapali support Hangxiang Ma
2026-10-08 22:32 ` bod
2026-10-08 7:14 ` [PATCH v19 04/12] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2026-10-08 7:14 ` [PATCH v19 05/12] media: qcom: camss: Add Kaanapali compatible Hangxiang Ma
2026-10-08 7:29 ` sashiko-bot
2026-10-08 7:14 ` [PATCH v19 06/12] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
2026-10-08 7:30 ` sashiko-bot
2026-10-08 22:38 ` bod
2026-10-08 7:14 ` [PATCH v19 07/12] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
2026-10-08 7:32 ` sashiko-bot
2026-10-08 7:14 ` [PATCH v19 08/12] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
2026-10-08 7:33 ` sashiko-bot
2026-10-08 22:50 ` bod
2026-10-09 2:59 ` Hangxiang Ma
2026-10-09 8:39 ` Bryan O'Donoghue
2026-10-09 11:36 ` Hangxiang Ma
2026-10-08 7:14 ` [PATCH v19 09/12] media: qcom: camss: tpg: Add support for v2.4.0 TPG Hangxiang Ma
2026-10-08 7:27 ` sashiko-bot
2026-10-08 7:14 ` [PATCH v19 10/12] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions Hangxiang Ma
2026-10-08 7:38 ` sashiko-bot [this message]
2026-10-09 8:40 ` Bryan O'Donoghue
2026-10-09 8:45 ` hangxiang.ma
2026-10-08 7:14 ` [PATCH v19 11/12] arm64: dts: qcom: kaanapali: Add CCI controller nodes Hangxiang Ma
2026-10-08 16:16 ` Loic Poulain
2026-10-09 4:06 ` Hangxiang Ma
2026-10-08 7:14 ` [PATCH v19 12/12] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl Hangxiang Ma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-163772@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hangxiang.ma@oss.qualcomm.com \
--cc=linux-phy@lists.infradead.org \
--cc=media-ci@linuxtv.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox