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

[Simon Glass]

Hi Sudeep,

On Tue, 24 Jan 2023 at 04:30, Sudeep Holla <sudeep.holla at arm.com> wrote:
>
> 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.

So you need to rebuild the firmware component to update the
information? That's not nice.

These parameters need to be factored out of the code. The best way to
do that is to put them in the DT. The DT should configure all of
firmware. It should not be necessary to rebuild all the code to update
a few parameters in the build.

Also these parameters should not be 'buried' in the code. I'd really
like you to consider the difference between code and data, with the
(configurable) data being in DT.

>
> 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.

U-Boot can set this up in the DT if that is what you want, but I think
you are confusing two things:

- what is available to use (i.e. drivers or code that is compiled in)
- what we actually want to use and how each piece if configured (this
should be handled at runtime)

Imagine your code is a Linux kernel. We don't hard-code these sorts of
settings in Linux.

>
> 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.

Well we should figure out a time or place to talk about this, as I
believe this is heading down the wrong path. As firmware gets more
complex, we need a unified configuration mechanism and proper
visibility into each component and what it is doing. They need to act
as a unified whole, not as a collection of blobs that might conflict.

Regards,
Simon