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

[Alexey Romanov]

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
> <avromanov at salutedevices.com> wrote:
> >
> > 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.
> 
> 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