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? Perhaps we should have a UCLASS_SVC (supervisor call) or something like that, rather than continuing with firmware? [..] Regards, Simon