All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Komal Bajaj" <komal.bajaj@oss.qualcomm.com>
Cc: linux-phy@lists.infradead.org, krzk+dt@kernel.org,
	devicetree@vger.kernel.org, neil.armstrong@linaro.org,
	olteanv@gmail.com, conor+dt@kernel.org, robh@kernel.org,
	vkoul@kernel.org
Subject: Re: [PATCH 2/4] arm64: dts: qcom: Introduce Shikra SoC base dtsi
Date: Wed, 13 May 2026 04:06:22 +0000	[thread overview]
Message-ID: <20260513040623.03F36C2BCC7@smtp.kernel.org> (raw)
In-Reply-To: <20260512-shikra-dt-v1-2-716438330dd0@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Invalid PPI interrupt numbers (1, 2, 3, 0) are specified for the ARMv8 generic timer instead of the architecturally required numbers (13, 14, 11, 10).
- [Medium] The `sdhc_1` node incorrectly uses RPMh interconnect tags (`QCOM_ICC_TAG_ALWAYS`, `QCOM_ICC_TAG_ACTIVE_ONLY`) on an RPM-based interconnect topology.
- [Medium] The USB SuperSpeed wakeup interrupt (`ss_phy_irq`) directly references the GIC instead of routing through the MPM, breaking system wake-up from deep sleep.
- [Low] The `sdhc_1` node uses the undeclared macro `RPMHPD_CX` for its `power-domains` property, which will cause a Device Tree compiler syntax error.
--

commit e2ee94ef3a5741f2cb9aae14dbef52c5f4a760f1
Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Subject: arm64: dts: qcom: Introduce Shikra SoC base dtsi

This commit adds initial device tree support for the Qualcomm Shikra SoC, an
IoT-focused platform featuring a Cortex-A55 and Cortex-A78C cluster. It
configures RPM-based power and clock management alongside various peripherals
like USB, eMMC, and the generic timer.

> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> new file mode 100644
> index 0000000000000..262c488add1ec
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi

[ ... ]

> +		sdhc_1: mmc@4744000 {
> +			compatible = "qcom,shikra-sdhci", "qcom,sdhci-msm-v5";
> +
> +			reg = <0x0 0x04744000 0x0 0x1000>,
> +			      <0x0 0x04745000 0x0 0x1000>;

[ ... ]

> +			interconnects = <&system_noc MASTER_SDCC_1 QCOM_ICC_TAG_ALWAYS
> +					&mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
> +					<&mem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ACTIVE_ONLY
> +					&config_noc SLAVE_SDCC_1 QCOM_ICC_TAG_ACTIVE_ONLY>;

Since the Shikra SoC utilizes an RPM-based architecture, should this node use
interconnect tags from qcom,rpm-icc.h (such as RPM_ALWAYS_TAG) instead? 
Passing RPMh interconnect tags from qcom,icc.h to an RPM interconnect provider
might result in unhandled parameters or silent bandwidth request failures.

> +			interconnect-names = "sdhc-ddr",
> +					     "cpu-sdhc";
> +
> +			power-domains = <&rpmpd RPMHPD_CX>;

Does this power-domains assignment use an undeclared macro? RPMHPD_CX belongs
to RPMh-based power domains, while this platform relies on RPMPD. This looks
like it will cause a dtc syntax error during the build.

[ ... ]

> +		usb_1: usb@4e00000 {
> +			compatible = "qcom,shikra-dwc3", "qcom,snps-dwc3";
> +			reg = <0x0 0x04e00000 0x0 0xfc100>;

[ ... ]

> +			interrupts-extended = <&intc GIC_SPI 255 IRQ_TYPE_LEVEL_HIGH>,
> +					      <&intc GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>,
> +					      <&intc GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
> +					      <&intc GIC_SPI 254 IRQ_TYPE_LEVEL_HIGH>,
> +					      <&intc GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "dwc_usb3",
> +					  "pwr_event",
> +					  "qusb2_phy",
> +					  "hs_phy_irq",
> +					  "ss_phy_irq";

The mpm node correctly maps pin 12 to GIC SPI 422 for the DWC3 ss_phy_irq.
Could routing this directly to the GIC here instead of hierarchically through
the mpm (e.g., <&mpm 12 IRQ_TYPE_LEVEL_HIGH>) prevent the hardware from
waking up from low-power states upon USB activity?

[ ... ]

> +	timer {
> +		compatible = "arm,armv8-timer";
> +
> +		interrupts = <GIC_PPI 1 IRQ_TYPE_LEVEL_LOW>,
> +			     <GIC_PPI 2 IRQ_TYPE_LEVEL_LOW>,
> +			     <GIC_PPI 3 IRQ_TYPE_LEVEL_LOW>,
> +			     <GIC_PPI 0 IRQ_TYPE_LEVEL_LOW>;
> +	};

Are these PPI interrupt numbers correct for the ARMv8 generic timer? The
architecturally defined numbers are typically 13 for Secure, 14 for Non-secure,
11 for Virtual, and 10 for Hypervisor. Using invalid hardware IRQ lines here
could prevent the kernel from receiving scheduler ticks and stall the boot.

> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com?part=2

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Komal Bajaj" <komal.bajaj@oss.qualcomm.com>
Cc: linux-phy@lists.infradead.org, krzk+dt@kernel.org,
	devicetree@vger.kernel.org, neil.armstrong@linaro.org,
	olteanv@gmail.com, conor+dt@kernel.org, robh@kernel.org,
	vkoul@kernel.org
Subject: Re: [PATCH 2/4] arm64: dts: qcom: Introduce Shikra SoC base dtsi
Date: Wed, 13 May 2026 04:06:22 +0000	[thread overview]
Message-ID: <20260513040623.03F36C2BCC7@smtp.kernel.org> (raw)
In-Reply-To: <20260512-shikra-dt-v1-2-716438330dd0@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Invalid PPI interrupt numbers (1, 2, 3, 0) are specified for the ARMv8 generic timer instead of the architecturally required numbers (13, 14, 11, 10).
- [Medium] The `sdhc_1` node incorrectly uses RPMh interconnect tags (`QCOM_ICC_TAG_ALWAYS`, `QCOM_ICC_TAG_ACTIVE_ONLY`) on an RPM-based interconnect topology.
- [Medium] The USB SuperSpeed wakeup interrupt (`ss_phy_irq`) directly references the GIC instead of routing through the MPM, breaking system wake-up from deep sleep.
- [Low] The `sdhc_1` node uses the undeclared macro `RPMHPD_CX` for its `power-domains` property, which will cause a Device Tree compiler syntax error.
--

commit e2ee94ef3a5741f2cb9aae14dbef52c5f4a760f1
Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Subject: arm64: dts: qcom: Introduce Shikra SoC base dtsi

This commit adds initial device tree support for the Qualcomm Shikra SoC, an
IoT-focused platform featuring a Cortex-A55 and Cortex-A78C cluster. It
configures RPM-based power and clock management alongside various peripherals
like USB, eMMC, and the generic timer.

> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> new file mode 100644
> index 0000000000000..262c488add1ec
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi

[ ... ]

> +		sdhc_1: mmc@4744000 {
> +			compatible = "qcom,shikra-sdhci", "qcom,sdhci-msm-v5";
> +
> +			reg = <0x0 0x04744000 0x0 0x1000>,
> +			      <0x0 0x04745000 0x0 0x1000>;

[ ... ]

> +			interconnects = <&system_noc MASTER_SDCC_1 QCOM_ICC_TAG_ALWAYS
> +					&mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
> +					<&mem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ACTIVE_ONLY
> +					&config_noc SLAVE_SDCC_1 QCOM_ICC_TAG_ACTIVE_ONLY>;

Since the Shikra SoC utilizes an RPM-based architecture, should this node use
interconnect tags from qcom,rpm-icc.h (such as RPM_ALWAYS_TAG) instead? 
Passing RPMh interconnect tags from qcom,icc.h to an RPM interconnect provider
might result in unhandled parameters or silent bandwidth request failures.

> +			interconnect-names = "sdhc-ddr",
> +					     "cpu-sdhc";
> +
> +			power-domains = <&rpmpd RPMHPD_CX>;

Does this power-domains assignment use an undeclared macro? RPMHPD_CX belongs
to RPMh-based power domains, while this platform relies on RPMPD. This looks
like it will cause a dtc syntax error during the build.

[ ... ]

> +		usb_1: usb@4e00000 {
> +			compatible = "qcom,shikra-dwc3", "qcom,snps-dwc3";
> +			reg = <0x0 0x04e00000 0x0 0xfc100>;

[ ... ]

> +			interrupts-extended = <&intc GIC_SPI 255 IRQ_TYPE_LEVEL_HIGH>,
> +					      <&intc GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>,
> +					      <&intc GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
> +					      <&intc GIC_SPI 254 IRQ_TYPE_LEVEL_HIGH>,
> +					      <&intc GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "dwc_usb3",
> +					  "pwr_event",
> +					  "qusb2_phy",
> +					  "hs_phy_irq",
> +					  "ss_phy_irq";

The mpm node correctly maps pin 12 to GIC SPI 422 for the DWC3 ss_phy_irq.
Could routing this directly to the GIC here instead of hierarchically through
the mpm (e.g., <&mpm 12 IRQ_TYPE_LEVEL_HIGH>) prevent the hardware from
waking up from low-power states upon USB activity?

[ ... ]

> +	timer {
> +		compatible = "arm,armv8-timer";
> +
> +		interrupts = <GIC_PPI 1 IRQ_TYPE_LEVEL_LOW>,
> +			     <GIC_PPI 2 IRQ_TYPE_LEVEL_LOW>,
> +			     <GIC_PPI 3 IRQ_TYPE_LEVEL_LOW>,
> +			     <GIC_PPI 0 IRQ_TYPE_LEVEL_LOW>;
> +	};

Are these PPI interrupt numbers correct for the ARMv8 generic timer? The
architecturally defined numbers are typically 13 for Secure, 14 for Non-secure,
11 for Virtual, and 10 for Hypervisor. Using invalid hardware IRQ lines here
could prevent the kernel from receiving scheduler ticks and stall the boot.

> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com?part=2

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-05-13  4:06 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12  4:08 [PATCH 0/4] arm64: dts: qcom: Add initial device tree support for Shikra Komal Bajaj
2026-05-12  4:08 ` Komal Bajaj
2026-05-12  4:08 ` [PATCH 1/4] dt-bindings: arm: qcom: Document Shikra and its EVK boards Komal Bajaj
2026-05-12  4:08   ` Komal Bajaj
2026-05-15  8:51   ` Krzysztof Kozlowski
2026-05-15  8:51     ` Krzysztof Kozlowski
2026-05-17 17:01     ` Komal Bajaj
2026-05-17 17:01       ` Komal Bajaj
2026-05-12  4:08 ` [PATCH 2/4] arm64: dts: qcom: Introduce Shikra SoC base dtsi Komal Bajaj
2026-05-12  4:08   ` Komal Bajaj
2026-05-13  4:06   ` sashiko-bot [this message]
2026-05-13  4:06     ` sashiko-bot
2026-05-17 18:54     ` Komal Bajaj
2026-05-17 18:54       ` Komal Bajaj
2026-05-19  9:49     ` Komal Bajaj
2026-05-19  9:49       ` Komal Bajaj
2026-05-15 10:37   ` Konrad Dybcio
2026-05-15 10:37     ` Konrad Dybcio
2026-05-17 18:25     ` Komal Bajaj
2026-05-17 18:25       ` Komal Bajaj
2026-05-12  4:08 ` [PATCH 3/4] arm64: dts: qcom: Add Shikra CQM SoM platform Komal Bajaj
2026-05-12  4:08   ` Komal Bajaj
2026-05-13  4:28   ` sashiko-bot
2026-05-13  4:28     ` sashiko-bot
2026-05-13 12:01     ` Dmitry Baryshkov
2026-05-13 12:01       ` Dmitry Baryshkov
2026-05-13 14:29       ` Rakesh Kota
2026-05-13 14:29         ` Rakesh Kota
2026-05-13 15:14         ` Dmitry Baryshkov
2026-05-13 15:14           ` Dmitry Baryshkov
2026-05-14 10:39           ` Kamal Wadhwa
2026-05-14 10:39             ` Kamal Wadhwa
2026-05-17 17:18             ` Dmitry Baryshkov
2026-05-17 17:18               ` Dmitry Baryshkov
2026-05-18 11:49               ` Kamal Wadhwa
2026-05-18 11:49                 ` Kamal Wadhwa
2026-05-13 13:31     ` Rakesh Kota
2026-05-13 13:31       ` Rakesh Kota
2026-05-12  4:08 ` [PATCH 4/4] arm64: dts: qcom: Add Shikra CQM and CQS EVK boards Komal Bajaj
2026-05-12  4:08   ` Komal Bajaj
2026-05-13 12:04   ` Dmitry Baryshkov
2026-05-13 12:04     ` Dmitry Baryshkov
2026-05-17 19:06     ` Komal Bajaj
2026-05-17 19:06       ` Komal Bajaj

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=20260513040623.03F36C2BCC7@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=komal.bajaj@oss.qualcomm.com \
    --cc=krzk+dt@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=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.