Hi, On Tue, Aug 22, 2023 at 10:24:23AM +0200, [email protected] wrote: > 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?
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 > -- Thank you, Alexey
