[PATCH v1 1/2] drivers: firmware: introduce Meson Secure Monitor driver

[Alexey Romanov]

Hi,

On Tue, Aug 22, 2023 at 10:24:23AM +0200, neil.armstrong at linaro.org wrote:
> On 21/08/2023 21:11, Simon Glass wrote:
> > Hi Neil,
> > 
> > On Mon, 21 Aug 2023 at 03:16, neil.armstrong at linaro.org
> > <neil.armstrong at 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 at 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
> 

-- 
Thank you,
Alexey