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

[neil.armstrong at linaro.org]

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?

I have no opinion on that, I don't think the call type is significant here.

Neil

> 
> [..]
> 
> Regards,
> Simon