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

[Michal Simek]

On 10/14/26 13:52, Palmer Dabbelt wrote:
> On Fri, 10 Jul 2026 01:59:04 PDT (-0700), sudeep.holla at kernel.org wrote:
>> On Fri, Jul 10, 2026 at 10:46:15AM +0200, Michal Simek wrote:
>>>
>>>
>>> On 7/10/26 10:38, Sudeep Holla wrote:
>>>> On Fri, Jul 10, 2026 at 09:42:09AM +0200, Michal Simek wrote:
>>>>>
>>>>>
>>>>> On 7/10/26 09:35, Sudeep Holla wrote:
>>>>>> 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)
>>>>>
>>>>> I am having separate discussion on u-boot mailing list about RPMI and it's
>>>>> usage on non riscv architectures because one raised argument was that it is
>>>>> community driver spec compare to SCMI which is owned by ARM. But IMHO only
>>>>> for riscv.
>>>>>
>>>>
>>>> IIRC in LPC 2024, we did discuss opening up SCMI so that RISCV could use it as
>>>> is instead of copying quite a lot from SCMI for RPMI in some closed groups.
>>>>
>>>> Here is the summary we got from couple of RISC-V vendors at the time:
>>>> "
>>>> RPMI is comparable to Arm SCMI, but it includes RISC-V-specific services such
>>>> as HART State Management, CPPC, Management Mode, and RAS Agent. The SBI MPXY
>>>> extension enables secure and non-secure system partitions to exchange RPMI
>>>> messages, allows an M-mode RPMI transport to be shared with S-mode, and lets
>>>> hypervisors virtualize RPMI for guests or VMs.
>>>>
>>>> RPMI development is already well advanced, with much of the client-driver work
>>>> implemented in OpenSBI. Supervisor software can access selected RPMI services
>>>> through SBI MPXY. A permissively licensed reference implementation, librpmi,
>>>> is also available for platform vendors.
>>>>
>>>> RPMI was created after evaluating Arm SCMI, mainly to support RISC-V-specific
>>>> requirements.
>>>> "
>>>>
>>>> I didn't pursue it any further following some of these followup discussions
>>>> post LPC 2024.
>>>
>>> interesting. It looks like that they even didn't try to ARM about it.
>>>
>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> As I wrote above AMD/Xilinx platform with SCMI server where ARM RPU/APUs
>>>>> (with multiple VMs) and Microblaze-V in programmable logic acting as
>>>>> separate agents is going to be the first user. And for being able to run
>>>>> SCMI on Linux running on Microblaze-V I need enable SCMI on non ARM
>>>>> architecture.
>>>>>
>>>>
>>>> Ah OK, if the plan is to just use SCMI as is and having "ARM/arm" name is
>>>> a blocker, then sure we can get that done. Hope you are aware of and already
>>>> considered some of the RISC-V specifics listed above and ruled out any of
>>>> those as concerns to use SCMI on RISC-V platforms.
>>>
>>> I know that we can't maintain SCMI and RPMI servers running on the same chip
>>> doing the same things. We don't have space for it and make no sense to
>>> duplicate testing on it too.
>>>
>>
>> That is very valid and compelling reason to re-use and agree with your
>> assessment. If you can make it work, go for it 😉.
> 
> Ya, it'd be great if we could stop duplicating specs in RISC-V land,
> it's just a big time sink.  So
> 
> Acked-by: Palmer Dabbelt <palmer at dabbelt.com>
> 
> if that helps any.

After rc1 I will send new patch series with more patches to clean this.
Will keep you in CC.

Thanks,
Michal