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

[Sudeep Holla]

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