Re: [PATCH v6 1/3] arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing `msi-map` property in `pcie0` and `pcie1` breaks GIC ITS MSI translation.
- [Low] Hardcoded literal `0` used instead of `GIC_SPI` macro in `interrupt-map`.
--

--- Patch [1]: [PATCH v6 1/3] arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes ---
commit f31bbbba6b5914ad12f809fe8f6dd440484e6594
Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>

arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes

Eliza supports two PCIe instances: one 8GT/s x1 (PCIe0) and one 8GT/s x2
(PCIe1). Add PCIe controller and PHY nodes for both instances, and update
the GCC clock references to use the newly added PHY nodes instead of
placeholder zeros.

> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> index 357e8066c1768..f802398bc7b27 100644
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
[ ... ]
> @@ -1784,6 +1784,369 @@ mmss_noc: interconnect@1780000 {
[ ... ]
> +		pcie0: pcie@1c00000 {
[ ... ]
> +			iommu-map = <0x0 &apps_smmu 0x1480 0x1>,
> +				    <0x100 &apps_smmu 0x1481 0x1>;
> +
[Severity: High]
Does pcie0 need an msi-map property defined alongside iommu-map to map PCIe
requester IDs to GIC ITS device IDs?

> +			interrupt-map = <0 0 0 1 &intc 0 0 0 564 IRQ_TYPE_LEVEL_HIGH>,
[Severity: Low]
This isn't a bug, but should the third 0 following the parent unit address
use the GIC_SPI macro instead of a literal 0 for the interrupt type?

> +					<0 0 0 2 &intc 0 0 0 565 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 3 &intc 0 0 0 566 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 4 &intc 0 0 0 567 IRQ_TYPE_LEVEL_HIGH>;
[ ... ]
> +		pcie1: pcie@1c08000 {
[ ... ]
> +			iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
> +				    <0x100 &apps_smmu 0x1401 0x1>;
> +
[Severity: High]
Does pcie1 also need an msi-map property defined alongside iommu-map to map
PCIe requester IDs to GIC ITS device IDs?

> +			interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>,
[Severity: Low]
This isn't a bug, but should the third 0 following the parent unit address
use the GIC_SPI macro instead of a literal 0 for the interrupt type?

> +					<0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>,
> +					<0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>;
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-eliza_evk-v6-0-40ece2d33114@oss.qualcomm.com?part=1