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

Simon Glass sjg at google.com
Mon Aug 21 21:11:58 CEST 2023

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?

Perhaps we should have a UCLASS_SVC (supervisor call) or something
like that, rather than continuing with firmware?



More information about the U-Boot mailing list