Re: [PATCH v2 2/5] arm64: dts: qcom: ipq9574: add the IMEM node

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: IMEM reg size exposes inaccessible memory to genalloc
--

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

arm64: dts: qcom: ipq9574: add the IMEM node

This commit adds the IMEM node to the device tree to extract debugging
information. The commit message notes the region is 32KB overall, but
only the initial 4KB is accessible by all masters in the SoC.

> diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
> index 771a595856459..f7cc6f274ca91 100644
> --- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi
> +++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi

[ ... ]

> @@ -757,6 +757,13 @@ usb_0_qmpphy: phy@7d000 {
>  			status = "disabled";
>  		};
>  
> +		sram@8600000 {
> +			compatible = "qcom,ipq9574-imem", "mmio-sram";
> +			reg = <0x08600000 0x8000>;

[Severity: Medium]
Does this reg property expose inaccessible memory to the generic SRAM pool?

The commit message states that only the initial 4KB of this 32KB region
is accessible. However, because the node uses the mmio-sram compatible
string, sram_probe() in drivers/misc/sram.c will automatically add all
unreserved regions within the full 32KB (0x8000) space to the kernel's
generic SRAM pool via gen_pool_add_virt().

If any driver allocates from this pool and attempts to access the upper
28KB, could it trigger a fatal Synchronous External Abort (SError) due to
the hardware protections on the inaccessible region?

Is there a way to describe only the accessible 4KB portion in the reg
property, or mark the inaccessible portion as reserved, so the allocator
state remains safe?

> +
> +			no-memory-wc;
> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002-imem_restart_reason-v2-0-61703c6362e3@oss.qualcomm.com?part=2