Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

Sudeep Holla
2023-01-24T11:30:47Z

Hi Simon,

On Mon, Jan 23, 2023 at 09:32:19AM -0700, Simon Glass wrote:
> Hi Sudeep,
>
> I'd like to see DT defined across firmware and OS, not just be a Linux
> thing.

Fair enough.

> It is a better approach than having little fiefdoms everywhere
> with their own config mechanisms.
>

Agreed.

> It seems that you have lots of build-time config in the ARM
> components.

Not really. I think I have not conveyed the setup details properly.
Let me try to explain with 2 hopefully simple examples:

1. Consider a system with a power controller running its own firmware and
OS(or any other application software including U-Boot) interacting with
it to get the required power resource access/modification.

One such thing is CPU operating points(OPP). Typically on old systems,
these are listing in the DT and OSPM drives them completely. Now on the
newer systems like the one I am presenting, ideally we need to get the
list of OPP from the f/w at runtime and use the information to drive it.

Suppose we have these information statically built into DT, then if the
firmware is upgraded and there is change in the OPP set or if the f/w
detects some configuration(bios/similar) that requires change in the
OPP set presented to the OSPM(or any other users), then the static info
built in the DT is stale or wrong. And hence the use of DT in such a
configuation or system is not correct unless DT is populated on the fly
interacting with the firmware before DT is consumed by the users.

This was one example which I was referring when I said I don't want to
use the DT info over live firmware information.

2. Now the FF-A case, if the list of partitions on the system is listed in
the DT and there is change in that list due to various reasons(firmware
upgrade, reconfiguration, resource disabled for a specific reason,...etc)
then the list will be stale when presented to the user(OSPM/Linux/U-Boot)
if it is not updated on the fly before the DT data is consumed.

Since in both the cases the firmware provides interface to the users to get
the information at runtime, I am against using the DT as source of
information.

--
Regards,
Sudeep