From: sashiko-bot@kernel.org
To: "Sushrut Shree Trivedi" <sushrut.trivedi@oss.qualcomm.com>
Cc: linux-phy@lists.infradead.org, linux-pci@vger.kernel.org,
neil.armstrong@linaro.org, olteanv@gmail.com, robh@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
vkoul@kernel.org
Subject: Re: [PATCH v2 5/5] arm64: dts: qcom: shikra: Add PCIe PHY and controller nodes
Date: Mon, 31 Aug 2026 07:41:08 +0000 [thread overview]
Message-ID: <20260831074109.4B49A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831-shikra-upstream-v2-5-406661d75afa@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `interrupt-map` property is malformed because it provides an incorrect number of cells for the parent interrupt specifier.
- [Low] The `pcie_phy` node violates the 'qcom,shikra-qmp-gen2x1-pcie-phy' DT binding schema by defining 6 clocks and using an invalid clock name 'phy_aux'.
--
commit 6b2a25b57b5360f808aceb407d09c81df6f4cd71
Author: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
arm64: dts: qcom: shikra: Add PCIe PHY and controller nodes
This commit adds the PCIe controller and PHY nodes for the single 5GT/s x1
link instance on Shikra. It limits the maximum link speed to PCIe Gen2 to
match the PHY capabilities and avoid link-up failures.
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 92d22e3b6931c..9e1810c715099 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
[ ... ]
> @@ -1013,6 +1013,163 @@ tsens0: thermal-sensor@4411000 {
> #thermal-sensor-cells = <1>;
> };
>
> + pcie: pcie@45e8000 {
> + device_type = "pci";
> + compatible = "qcom,shikra-pcie";
[ ... ]
> + interrupt-map = <0 0 0 1 &intc 0 0 0 499 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 0 500 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 0 501 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 0 502 IRQ_TYPE_LEVEL_HIGH>;
[Severity: High]
Does this interrupt-map provide an incorrect number of cells for the parent
interrupt specifier?
The kernel parser expects 4 cells for the parent interrupt specifier because
&intc has #interrupt-cells = <4> and lacks #address-cells (defaulting to 0
for the parent address). However, 5 cells (0 0 0 499 IRQ_TYPE_LEVEL_HIGH)
are provided here.
Will this misalignment cause phandle resolution to fail for subsequent
entries, parsing cells like 2 or 4 as phandles and breaking PCIe interrupt
routing on this platform?
[ ... ]
> + pcie_phy: phy@45ee000 {
> + compatible = "qcom,shikra-qmp-gen2x1-pcie-phy";
> + reg = <0x0 0x045ee000 0x0 0x1000>;
> +
> + clocks = <&gcc GCC_PCIE_AUX_CLK>,
> + <&gcc GCC_PCIE_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_CLKREF_EN>,
> + <&gcc GCC_PCIE_RCHNG_PHY_CLK>,
> + <&gcc GCC_PCIE_PIPE_CLK>,
> + <&gcc GCC_PCIE_SLEEP_CLK>;
> + clock-names = "aux",
> + "cfg_ahb",
> + "ref",
> + "refgen",
> + "pipe",
> + "phy_aux";
[Severity: Low]
Does this node violate the qcom,shikra-qmp-gen2x1-pcie-phy DT binding schema?
The schema qcom,sc8280xp-qmp-pcie-phy.yaml limits the maximum number of clocks
to 5 for qcom,shikra-qmp-gen2x1-pcie-phy and does not allow the phy_aux clock
name.
While the driver optionally fetches this clock so the hardware still functions,
will this cause dtbs_check schema validation to fail?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260831-shikra-upstream-v2-0-406661d75afa@oss.qualcomm.com?part=5
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Sushrut Shree Trivedi" <sushrut.trivedi@oss.qualcomm.com>
Cc: linux-phy@lists.infradead.org, linux-pci@vger.kernel.org,
neil.armstrong@linaro.org, olteanv@gmail.com, robh@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
vkoul@kernel.org
Subject: Re: [PATCH v2 5/5] arm64: dts: qcom: shikra: Add PCIe PHY and controller nodes
Date: Mon, 31 Aug 2026 07:41:08 +0000 [thread overview]
Message-ID: <20260831074109.4B49A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831-shikra-upstream-v2-5-406661d75afa@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `interrupt-map` property is malformed because it provides an incorrect number of cells for the parent interrupt specifier.
- [Low] The `pcie_phy` node violates the 'qcom,shikra-qmp-gen2x1-pcie-phy' DT binding schema by defining 6 clocks and using an invalid clock name 'phy_aux'.
--
commit 6b2a25b57b5360f808aceb407d09c81df6f4cd71
Author: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
arm64: dts: qcom: shikra: Add PCIe PHY and controller nodes
This commit adds the PCIe controller and PHY nodes for the single 5GT/s x1
link instance on Shikra. It limits the maximum link speed to PCIe Gen2 to
match the PHY capabilities and avoid link-up failures.
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 92d22e3b6931c..9e1810c715099 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
[ ... ]
> @@ -1013,6 +1013,163 @@ tsens0: thermal-sensor@4411000 {
> #thermal-sensor-cells = <1>;
> };
>
> + pcie: pcie@45e8000 {
> + device_type = "pci";
> + compatible = "qcom,shikra-pcie";
[ ... ]
> + interrupt-map = <0 0 0 1 &intc 0 0 0 499 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 0 500 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 0 501 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 0 502 IRQ_TYPE_LEVEL_HIGH>;
[Severity: High]
Does this interrupt-map provide an incorrect number of cells for the parent
interrupt specifier?
The kernel parser expects 4 cells for the parent interrupt specifier because
&intc has #interrupt-cells = <4> and lacks #address-cells (defaulting to 0
for the parent address). However, 5 cells (0 0 0 499 IRQ_TYPE_LEVEL_HIGH)
are provided here.
Will this misalignment cause phandle resolution to fail for subsequent
entries, parsing cells like 2 or 4 as phandles and breaking PCIe interrupt
routing on this platform?
[ ... ]
> + pcie_phy: phy@45ee000 {
> + compatible = "qcom,shikra-qmp-gen2x1-pcie-phy";
> + reg = <0x0 0x045ee000 0x0 0x1000>;
> +
> + clocks = <&gcc GCC_PCIE_AUX_CLK>,
> + <&gcc GCC_PCIE_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_CLKREF_EN>,
> + <&gcc GCC_PCIE_RCHNG_PHY_CLK>,
> + <&gcc GCC_PCIE_PIPE_CLK>,
> + <&gcc GCC_PCIE_SLEEP_CLK>;
> + clock-names = "aux",
> + "cfg_ahb",
> + "ref",
> + "refgen",
> + "pipe",
> + "phy_aux";
[Severity: Low]
Does this node violate the qcom,shikra-qmp-gen2x1-pcie-phy DT binding schema?
The schema qcom,sc8280xp-qmp-pcie-phy.yaml limits the maximum number of clocks
to 5 for qcom,shikra-qmp-gen2x1-pcie-phy and does not allow the phy_aux clock
name.
While the driver optionally fetches this clock so the hardware still functions,
will this cause dtbs_check schema validation to fail?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260831-shikra-upstream-v2-0-406661d75afa@oss.qualcomm.com?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-08-31 7:41 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 7:26 [PATCH v2 0/5] PCI: qcom: Add PCIe support for Shikra SoC Sushrut Shree Trivedi
2026-08-31 7:26 ` Sushrut Shree Trivedi
2026-08-31 7:26 ` [PATCH v2 1/5] dt-bindings: phy: sc8280xp-qmp-pcie: Document Shikra PCIe phy Sushrut Shree Trivedi
2026-08-31 7:26 ` Sushrut Shree Trivedi
2026-08-31 7:29 ` sashiko-bot
2026-08-31 7:29 ` sashiko-bot
2026-09-01 8:35 ` Krzysztof Kozlowski
2026-09-01 8:35 ` Krzysztof Kozlowski
2026-09-10 14:53 ` Manivannan Sadhasivam
2026-09-10 14:53 ` Manivannan Sadhasivam
2026-09-11 7:52 ` Bartosz Golaszewski
2026-09-11 7:52 ` Bartosz Golaszewski
2026-08-31 7:26 ` [PATCH v2 2/5] dt-bindings: PCI: qcom,shikra-pcie: Document the Shikra PCIe Controller Sushrut Shree Trivedi
2026-08-31 7:26 ` Sushrut Shree Trivedi
2026-08-31 7:36 ` sashiko-bot
2026-08-31 7:36 ` sashiko-bot
2026-09-01 8:42 ` Krzysztof Kozlowski
2026-09-01 8:42 ` Krzysztof Kozlowski
2026-09-21 13:47 ` Sushrut Shree Trivedi
2026-09-21 13:47 ` Sushrut Shree Trivedi
2026-09-21 14:21 ` Krzysztof Kozlowski
2026-09-21 14:21 ` Krzysztof Kozlowski
2026-08-31 7:26 ` [PATCH v2 3/5] PCI: qcom: Add support for Shikra Sushrut Shree Trivedi
2026-08-31 7:26 ` Sushrut Shree Trivedi
2026-08-31 7:29 ` sashiko-bot
2026-08-31 7:29 ` sashiko-bot
2026-08-31 7:26 ` [PATCH v2 4/5] phy: qcom: qmp-pcie: Add QMP PCIe PHY " Sushrut Shree Trivedi
2026-08-31 7:26 ` Sushrut Shree Trivedi
2026-08-31 7:34 ` sashiko-bot
2026-08-31 7:34 ` sashiko-bot
2026-09-10 14:54 ` Manivannan Sadhasivam
2026-09-10 14:54 ` Manivannan Sadhasivam
2026-09-11 7:52 ` Bartosz Golaszewski
2026-09-11 7:52 ` Bartosz Golaszewski
2026-08-31 7:26 ` [PATCH v2 5/5] arm64: dts: qcom: shikra: Add PCIe PHY and controller nodes Sushrut Shree Trivedi
2026-08-31 7:26 ` Sushrut Shree Trivedi
2026-08-31 7:41 ` sashiko-bot [this message]
2026-08-31 7:41 ` sashiko-bot
2026-09-02 8:46 ` [PATCH v2 0/5] PCI: qcom: Add PCIe support for Shikra SoC Konrad Dybcio
2026-09-02 8:46 ` Konrad Dybcio
2026-09-21 13:52 ` Sushrut Shree Trivedi
2026-09-21 13:52 ` Sushrut Shree Trivedi
2026-09-13 10:56 ` (subset) " Vinod Koul
2026-09-13 10:56 ` Vinod Koul
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=20260831074109.4B49A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sushrut.trivedi@oss.qualcomm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.