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: <716e0d28-1735-45ac-9339-cde1cf14a8a1@ti.com>
Date: Fri, 4 Oct 2024 06:52:01 -0500
From: Andrew Davis <afd@...com>
To: Nishanth Menon <nm@...com>, Bryan Brattlof <bb@...com>
CC: 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

On 10/4/24 6:26 AM, Nishanth Menon wrote:
> On 16:06-20241003, Bryan Brattlof wrote:
>> 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.
> 
> They can define their own overlays.
> 
>>
>> Would an overlay be appropriate for this?
> 
> Why is this any different from existing boards? Are you suggesting a
> change for all existing boards as well?
> 

Yes, I believe that is what is being suggested, and I agree with it.
It would also help with all these non-SK boards we now have, they
would simply apply the same overlay when using the firmware that
requires these carveouts.

I've been thinking on doing that for a while, but I wanted to keep
the same pattern just for this one last series. Then we can attempt
to refactor next.

Andrew