linux-kernel - Re: [PATCH v12 2/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241003210606.2k7wyssklwfziod4@bryanbrattlof.com>
Date: Thu, 3 Oct 2024 16:06:06 -0500
From: Bryan Brattlof <bb@...com>
To: Andrew Davis <afd@...com>
CC: Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
        Tero
 Kristo <kristo@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof
 Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v12 2/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc
 node

Hi Andrew!

On October  3, 2024 thus sayeth Andrew Davis:
> From: Hari Nagalla <hnagalla@...com>
> 
> The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
> domain. This core can be used by non safety applications as a remote
> processor. When used as a remote processor with virtio/rpmessage IPC,
> two carveout reserved memory nodes are needed. The first region is used
> as a DMA pool for the rproc device, and the second region will furnish
> the static carveout regions for the firmware memory.
> 
> The current carveout addresses and sizes are defined statically for
> each rproc device. The M4F processor does not have an MMU, and as such
> requires the exact memory used by the firmware to be set-aside.
> 
> Signed-off-by: Hari Nagalla <hnagalla@...com>
> Signed-off-by: Andrew Davis <afd@...com>
> ---
>  .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> index 44ff67b6bf1e4..6957b3e44c82f 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
> @@ -56,6 +56,18 @@ linux,cma {
>  			linux,cma-default;
>  		};
>  
> +		mcu_m4fss_dma_memory_region: m4f-dma-memory@...00000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9cb00000 0x00 0x100000>;
> +			no-map;
> +		};
> +
> +		mcu_m4fss_memory_region: m4f-memory@...00000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00 0x9cc00000 0x00 0xe00000>;
> +			no-map;
> +		};
> +

The only issue I have here is this takes away memory from people who do 
not use these firmware or causes them to work around this patch if they 
choose to have different carveouts.

Would an overlay be appropriate for this?

~Bryan