Hi,
On Tue, Aug 22, 2023 at 10:24:23AM +0200, neil.armstrong@linaro.org wrote:
On 21/08/2023 21:11, Simon Glass wrote:
Hi Neil,
On Mon, 21 Aug 2023 at 03:16, neil.armstrong@linaro.org neil.armstrong@linaro.org wrote:
Hi,
On 16/07/2023 01:40, Simon Glass wrote:
Hi,
On Thu, 13 Jul 2023 at 23:30, AKASHI Takahiro takahiro.akashi@linaro.org wrote:
On Tue, Jul 11, 2023 at 01:13:29PM -0600, Simon Glass wrote:
+AKASHI Takahiro
Me?
Yes, I'm asking for your help to try to clean this stuff up.
The thread is long and hard to answer directly, but as AKASHI said there's no point to add a SMC class since it's only the message passing instruction, and there's no point using remoteproc since the firmware runs on a separate secure state of the same CPU.
And I don't see how we can actually define a finite set of ops because none of the secure firmware interfaces has even similar functions.
So a new UCLASS for each firmware interface should be added, not sure this is scalable or required since those firmwares are mainly SoC or vendor specific, except the PSCI or other ARM specific interfaces of course.
So I think UCLASS_FIRMWARE is good enough since it avoids using UCLASS_MISC, but it should be probably documented somewhere that the ops are implementation defined.
Yes it needs docs...but what exactly is the 'firmware' uclass? I assumed it was for loading firmware into a device, but it seems that it is something else?
Nop, it's based on the same "firmware" naming as Linux, which is an interface with a system control firmware like PSCI, SCPI... not to interact with loadable co-processors.
Systems do have multiple interfaces implemented like PSCI, SCPI, OPTEE and other vendor specific ones like Alexey is changing, all via the same instruction call.
Perhaps we should have a UCLASS_SVC (supervisor call) or something like that, rather than continuing with firmware?
You propose to create UCLASS with an interface consisting of functions of something like: ->smc_call(), ->hvc_call()? In this case, it seems ARM specific.
Or UCLASS with only one callback, different for different archs, which will call the hypervisor or something like that. In my understanding, this add-on are redundant.
I still think UCLASS firmware is the best fit for my Secure Monitor implementation at the moment.
I have no opinion on that, I don't think the call type is significant here.
Neil
[..]
Regards, Simon