Re: [PATCH v10 2/3] arm64: dts: qcom: ipq5424: Add the IMEM node

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The device tree node maps the full 112KB IMEM region, exposing inaccessible memory to the generic SRAM allocator.
--

commit d275aea75b5a17a008a9020c79777d0cc37ddedc
Author: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>

arm64: dts: qcom: ipq5424: Add the IMEM node

This commit adds the IMEM node to the device tree for the IPQ5424 SoC to
extract debugging information. It defines the IMEM region as 112KB, noting
that only the first 4KB is accessible by all masters.

> diff --git a/arch/arm64/boot/dts/qcom/ipq5424.dtsi b/arch/arm64/boot/dts/qcom/ipq5424.dtsi
> --- a/arch/arm64/boot/dts/qcom/ipq5424.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq5424.dtsi
[ ... ]
> +		sram@8600000 {
> +			compatible = "qcom,ipq5424-imem", "mmio-sram";
> +			reg = <0 0x08600000 0 0x1c000>;
> +			ranges = <0 0 0x08600000 0x1c000>;

Could mapping the full 112KB region cause XPU violations?

The commit message notes that only the initial 4KB is accessible by all
masters in the SoC. Since this node uses the mmio-sram compatible, the
generic SRAM driver will map the entire 0x1c000 region and add the
unreserved portion to a gen_pool for dynamic allocation.

If a driver requests memory from this pool, could it receive an address
within the restricted region and trigger an SError upon access?

Additionally, is there a risk of speculative execution or memory debugging
tools accessing the restricted region and causing a kernel panic?

Should the reg and ranges sizes be limited strictly to the safely
accessible 4KB (0x1000) region?

> +
> +			no-memory-wc;
> +
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513-wdt_reset_reason-v10-0-cebda08ab1ef@oss.qualcomm.com?part=2