linux-kernel - Re: [PATCH 0/2] TI: K3: Switch MCU R5F cluster into Split mode

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] [day] [month] [year] [list]

Message-ID: <0fe3f172-5a88-4f1d-9eb2-7b748f9f6743@ti.com>
Date: Tue, 27 May 2025 23:44:59 +0530
From: "Kumar, Udit" <u-kumar1@...com>
To: Andrew Davis <afd@...com>, Nishanth Menon <nm@...com>,
        Beleswar Prasad
 Padhi <b-padhi@...com>
CC: <vigneshr@...com>, <kristo@...nel.org>, <robh@...nel.org>,
        <krzk+dt@...nel.org>, <conor+dt@...nel.org>, <hnagalla@...com>,
        <jm@...com>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
        <u-kumar1@...com>
Subject: Re: [PATCH 0/2] TI: K3: Switch MCU R5F cluster into Split mode


On 5/23/2025 6:46 PM, Andrew Davis wrote:
> On 5/23/25 6:48 AM, Nishanth Menon wrote:
>> On 14:27-20250523, Beleswar Prasad Padhi wrote:
>>> Hi Nishanth,
>>>
>>> On 5/22/2025 9:23 PM, Nishanth Menon wrote:
>>>> On 13:04-20250522, Beleswar Padhi wrote:
>>>>> Several TI K3 SoCs like J7200, J721E, J721S2, J784S4 and J742S2 
>>>>> have a
>>>>> R5F cluster in the MCU domain which is configured for LockStep 
>>>>> mode at
>>>>> the moment. Switch this R5F cluster to Split mode by default in all
>>>>> corresponding board level DTs to maximize the number of R5F cores.
>>>> Why? I can read the patch to understand what you are trying to do, but
>>>> the rationale needs to be explained.
>>>
>>>
>>> [..]
>> I suggest the following:
>> * SoC dts files - use a common standard for remote proc - lockstep makes
>>    sense as it is right now
>> * Modification to board specific dts files - call them out as board
>>    files specific patches to flip over to split mode - while considering
>>    the possibilities that users may NOT upgrade kernel and bootloader at
>>    the same time and the existence of EFI based dtb handover from
>>    bootloader to kernel - which means, kernel should be able to 
>> handle the
>>    same combinations correctly. Also handle the carveouts correctly for
>>    the new processors - at least state the strategy - overlays etc.. 
>> Come
>>    to think of it, I think we should fix up the carveout strategy for
>>    user programmable remote cores first before attempting all this new
>>    processor additions.
>
> +1
>
> The core issue here is that split vs lockstep is a *configuration*, which
> means it doesn't belong in DT in the first place. This is the reason 
> to keep
> config out of DT, why should what mode my R5 core starts in be based 
> on what
> board I'm using? It hard-codes what should be configurable decisions.

configurable decisions is bootloader build .

and you know what you are building then change DT as well.


>
> Same issue with carveouts, so IMHO all of the: carveouts, mailbox 
> selection,
> timer reserved status, and mode selection belong in an overlay. It 
> doesn't
> fix the issues, but at least it isolates it.
>
Its usage model, and split mode is enabled at board level.

as default, split mode is used, in case lock-step is needed then change 
DT in custom build too.


Also, Patch 1/2 should be posted as different patch.


> Andrew
>
>> * Split out the fixes patches separately out - no reason to mix it up
>>    with the rest of the refactoring.
>> * Fix your commit messages and subject lines to indicate clearly what is
>>    impacted, rationale, backward compatibility status
>>
>> [1] 
>> https://lore.kernel.org/all/20250522071828.285462-7-b-padhi@ti.com/#Z31dts:upstream:src:arm64:ti:k3-j7200-mcu-wakeup.dtsi
>> [2] https://lore.kernel.org/all/20250522073426.329344-2-b-padhi@ti.com/
>>