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.
