Re: [PATCH 2/2] arm64: dts: qcom: Add base HAMOA-IOT-COME board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unused PCIe controllers (pcie4, pcie5, pcie6a) are left enabled in the ComE carrier board, causing boot delays and power waste.
--

commit 5654913fbfd858b8d2bf4684318b0d7145c8a5b6
Author: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com>

arm64: dts: qcom: Add base HAMOA-IOT-COME board

This commit adds the device tree for the HAMOA-IOT-COME platform, which
consists of a SoM mounted on a carrier board. It includes initial support
for components like UART, Regulators, USB, PCIe, Pinctrl, and UFS.

> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-come.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-come.dts
> new file mode 100644
> index 0000000000000..99c47cd953b83
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-come.dts
[ ... ]
> +&pcie3_port0 {
> +	vpcie12v-supply = <&vreg_pcie_12v>;
> +	vpcie3v3-supply = <&vreg_pcie_3v3>;
> +	vpcie3v3aux-supply = <&vreg_pcie_3v3_aux>;
> +
> +	reset-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
> +};

[Severity: Medium]
The included hamoa-iot-som.dtsi enables pcie4, pcie5, and pcie6a with
status = "okay", but this carrier board does not disable them or provide
the required reset-gpios routing.

Will this result in the pcie-qcom driver powering on their PHYs and timing
out during link training?

It appears dw_pcie_wait_for_link() will loop and time out after 900ms per
controller without a connected device or toggled reset signal. This causes
boot delays of nearly 2.7 seconds and leaves unused PHYs powered on.

Should these unused controllers be explicitly disabled here with
status = "disabled"?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630071022.3256-1-yuanjie.yang@oss.qualcomm.com?part=2