Re: [RFC PATCH] firmware: scmi: Make SCMI arch independent

On Fri, Jul 10, 2026 at 09:03:32AM +0200, Michal Simek wrote:
> 
> 
> On 7/9/26 17:56, Cristian Marussi wrote:
> > On Thu, Jul 09, 2026 at 03:27:00PM +0200, Michal Simek wrote:
> > > On heterogenious systems like AMD/Xilinx FPGA there is a need to talk to
> > > SCMI server from different architectures than ARM that's why remove
> > > ARM/ARM64 Kconfig dependency with also remove ARM from description and
> > > rename folder to reflect it.
> > 
> > While I understand dropping the dependency on ARM (I always wanted to do
> > that and test if it worked at all on some otehr archs with QEMU), I am
> > not sure about the whole renaming party ? why is needed just for
> > cosmetic reasons ? it is at the end an arm originated protocol so I dont
> > see it as a being wrong to be named as such even though used by other
> > archs...I have not really strong opinion on this...
> 
> I have been in CC on U-Boot RPMI patches which got to my attention because
> I don't want to have another interface for MB-V(riscv-) running in
> programmable logic and have another server in the system doing the same
> thing.
> 

Ah that's interesting. I wasn't aware of that. I still agree with the move
in principle, but how does that align with these:

drivers/clk/clk-rpmi.c
drivers/irqchip/irq-riscv-rpmi-sysmsi.c
include/linux/mailbox/riscv-rpmi-message.h
drivers/mailbox/riscv-sbi-mpxy-mbox.c(Should be fine as it is just transport)

Now I feel we need some alignment before making $subject move.

> Based on that we had discussed about it with Vincent and Souvik (we missed
> you there) about using SCMI on non ARM platform and both of them didn't see
> the concern to be marked as ARM only protocol.
> Truth is that some of protocols have ARM in description, file names, etc but
> some of them not. That's why I think it is good time to sync it up and
> enable
> running this protocol on other SOCs.
> 
> > ... my concern really is ... wont this full scale rename simply generate
> > a lot of un-needed churn for future fixes and/or backporting ?
> I don't think it is going to be a big problem because it is just git mv
> which git is able to gracefully handle.
> 

Otherwise it may end up being unnecessary churn though I completely agree
with the git/backporting aspects. Just don't want to churn things up until
we have some plan and further changes/users of this move.

-- 
Regards,
Sudeep