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 <[email protected]>
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/[email protected]?part=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.