Re: [PATCH v3 3/3] arm64: dts: qcom: eliza-evk: Add PCIe1 with TC9563 PCIe switch

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Medium] The downstream PCI-to-PCI bridge nodes specify overlapping and invalid bus-range properties.
- [Low] Missing `compatible = "pciclass,0604"` in the downstream PCI bridge nodes.

Pre-existing issues:
- [High] The addition of two child nodes (`pci@0,0` and `pci@0,1`) under the DSP3 port (`pcie@3,0`) triggers a deterministic out-of-bounds array access in the existing `pci-pwrctrl-tc9563` driver, leading to memory corruption and a kernel panic during probe.
--

--- Patch [3]: [PATCH v3 3/3] arm64: dts: qcom: eliza-evk: Add PCIe1 with TC9563 PCIe switch ---
commit 3a7dcae4b740553fda1daf6d1b08f87c99ab83eb
Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>

arm64: dts: qcom: eliza-evk: Add PCIe1 with TC9563 PCIe switch

This patch adds the TC9563 PCIe switch to the Eliza EVK device tree on PCIe1.
It sets up the I2C management interface, overrides the base iommu-map, and
configures the reset GPIO.

> diff --git a/arch/arm64/boot/dts/qcom/eliza-evk.dtsi b/arch/arm64/boot/dts/qcom/eliza-evk.dtsi
> index 6d76715ccffbe..fb44e7a349a5d 100644
> --- a/arch/arm64/boot/dts/qcom/eliza-evk.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza-evk.dtsi

[ ... ]

> @@ -99,6 +119,99 @@ pcieport0_ep: endpoint {
>  	};
>  };
>  

[ ... ]

> +&pcie1port0 {
> +	wake-gpios = <&tlmm 53 GPIO_ACTIVE_LOW>;
> +	/* Same GPIO is used for both PERST# and resx-gpio */
> +
> +	tc9563: pcie@0,0 {
> +		compatible = "pci1179,0623";
> +		reg = <0x10000 0x0 0x0 0x0 0x0>;

[ ... ]

> +		resx-gpios = <&tlmm 54 GPIO_ACTIVE_LOW>;
> +
> +		pcie@1,0 {
> +			reg = <0x20800 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +

[Severity: Low]
Should these downstream PCI bridge nodes include the
compatible = "pciclass,0604" string? The same patch adds it to the upstream
port pcie1port0 to satisfy schema validation checks.

> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x3 0xff>;

[Severity: Medium]
Do these sibling PCI-to-PCI bridge nodes specify overlapping bus-range
properties? Since they are sibling bridges, they cannot route overlapping
downstream bus ranges, but they all specify 0xff as the subordinate bus.

> +		};
> +
> +		pcie@2,0 {
> +			reg = <0x21000 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x4 0xff>;
> +		};
> +
> +		pcie@3,0 {
> +			reg = <0x21800 0x0 0x0 0x0 0x0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			device_type = "pci";
> +			ranges;
> +			bus-range = <0x5 0xff>;
> +
> +			pci@0,0 {
> +				reg = <0x50000 0x0 0x0 0x0 0x0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				device_type = "pci";
> +				ranges;
> +			};
> +
> +			pci@0,1 {

[Severity: High]
This is a pre-existing issue, but does adding these two child nodes under the
DSP3 port trigger an out-of-bounds access in the pci-pwrctrl-tc9563 driver?

Looking at drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c in tc9563_pwrctrl_probe(),
the driver iterates over the child nodes:

	for_each_child_of_node_scoped(child, child1) {
		port++;
		ret = tc9563_pwrctrl_parse_device_dt(tc9563,
						child1, port);

Without checking bounds against the array size TC9563_MAX (5), will this
increment port to 5 and access tc9563->cfg[5] out of bounds, overwriting
adjacent structure members and causing a kernel panic during probe?

> +				reg = <0x50100 0x0 0x0 0x0 0x0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				device_type = "pci";
> +				ranges;
> +			};
> +		};
> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-eliza_evk-v3-0-92b10038f13d@oss.qualcomm.com?part=3