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

[Simon Glass]

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.

>
> >
> > I have no opinion on that, I don't think the call type is significant here.
> >
> > Neil
> >
> > >
> > > [..]
> > >
> > > Regards,
> > > Simon
> >
>
> --
> Thank you,
> Alexey

Regards,
Simon