[PATCH] firmware: scmi: Drop mmu_set_region_dcache_behaviour() misuse

[Marek Vasut]

On 10/30/25 1:36 PM, Bryan Brattlof wrote:
> On October 29, 2025 thus sayeth Anshul Dalal:
>> On Tue Oct 28, 2025 at 8:46 PM IST, Marek Vasut wrote:
>>> On 10/28/25 3:37 PM, Marek Vasut wrote:
>>>> On 10/28/25 9:25 AM, Peng Fan wrote:
>>>>
>>>> Hello Peng,
>>>>
>>>>>> Subject: [PATCH] firmware: scmi: Drop
>>>>>> mmu_set_region_dcache_behaviour() misuse
>>>>>>
>>>>>> MMU region cache behavior configuration for SCMI/SMT mailboxes is
>>>>>> platform specific. Even on ARM systems, the mailbox memory may not
>>>>>> even be located in any cacheable MMU region and may instead reside
>>>>>> in some SRAM. Remove this non-generic cache behavior configuration
>>>>>> code from generic code path.
>>>>>>
>>>>>> It is unlikely that any platform is affected by this change if it did
>>>>>> configure its MMU regions correctly on start up. Platforms which might
>>>>>> be affected are i.MX94/95 and STM32MP.
>>>>>>
>>>>>
>>>>> If the memory is mapped before running SCMI stuff, it is ok.
>>>>> But if memory is dynamic mapped at run time, there might be issue.
>>>>
>>>> I wonder ... should ARM/ARM64 define CONFIG_HAVE_ARCH_IOREMAP and
>>>> implement actual ioremap() function which changes these cacheable
>>>> properties accordingly ?
>>>>
>>>>> I saw TI platforms has some changes to use dynamic mappings,
>>>>> I have not read the details, TBH.
>>>>
>>>> Can we put the TI people on CC here ?
>>>
>>> +CC Anshul
>>
>> This change shouldn't affect any current TI platforms since we don't
>> make use of SCMI on K3 devices.
>>
>> I'll CC folks working on upcoming devices in case they have any
>> thoughts.
>>
>> +CC Dhruva, Bryan, Kamlesh
> 
> It's my expectation is the shared buffer would always be in some
> internal SRAM which shouldn't need to be mapped.

I think the buffer can be in DRAM, if the DRAM controller supports some 
protected regions/filtering, but it would be susceptible to rowhammer or 
similar attacks.

> Not only does it keep
> the buffer secure on platforms that care about that but it also speeds
> up the access latencies between the different binaries.
> 
> IMHO it makes sense to rip this out and let the few architectures that
> need to do some MMU maintenance do it themselves.
It seems Alice from NXP found some breakage on MX8ULP , I have yet to 
reply to that, but maybe this is fixable on architecture/mmu table 
level, I'll reply to that email shortly.

If we have breakage here, I think we either need to consider:
- some weak function to fix up dynamically allocated areas (?)
- make ioremap() configure the cacheable properties of mapped memory

The second option is more generic obviously, but I am unsure whether 
this is the right way to go about it.