Hi Simon, On Tue, Aug 22, 2023 at 12:56:32PM -0600, Simon Glass wrote: > Hi Alexey, > > On Tue, 22 Aug 2023 at 06:59, Alexey Romanov > <avroma...@salutedevices.com> wrote: > > > > Hi, > > > > On Tue, Aug 22, 2023 at 10:24:23AM +0200, neil.armstr...@linaro.org wrote: > > > On 21/08/2023 21:11, Simon Glass wrote: > > > > Hi Neil, > > > > > > > > On Mon, 21 Aug 2023 at 03:16, neil.armstr...@linaro.org > > > > <neil.armstr...@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.aka...@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. > > Yes, but we have a lot of arch-specific interfaces. > > > > > 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. > > OK. > > > > > I still think UCLASS firmware is the best fit for my Secure Monitor > > implementation at the moment. > > How about you create a UCLASS_MESON_SM then? > > I don't really like the idea of a uclass with no standard API. One > goal is to help people understand things and can't see that helping.
OK. Will do it in v2. > > > > > > > > > I have no opinion on that, I don't think the call type is significant > > > here. > > > > > > Neil > > > > > > > > > > > [..] > > > > > > > > Regards, > > > > Simon > > > > > > > -- > > Thank you, > > Alexey > > Regards, > Simon -- Thank you, Alexey
