On 21/08/2023 21:11, Simon Glass wrote:
Hi Neil,
On Mon, 21 Aug 2023 at 03:16, [email protected]
<[email protected]> wrote:
Hi,
On 16/07/2023 01:40, Simon Glass wrote:
Hi,
On Thu, 13 Jul 2023 at 23:30, AKASHI Takahiro
<[email protected]> 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?
I have no opinion on that, I don't think the call type is significant here.
Neil
[..]
Regards,
Simon
