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

[Sudeep Holla]

On Tue, Jan 24, 2023 at 03:44:53PM -0700, Simon Glass wrote:
> Hi Sudeep,
> 
> On Tue, 24 Jan 2023 at 04:30, Sudeep Holla <sudeep.holla at arm.com> wrote:
> >
> > Hi Simon,
> >

[...]

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

Well, I understand the firmware component itself can fetch these data from
the DT, but not all firmware are built with DT support to start with(for
simple reasons like they need to run with very limited ram in orders of few
kB).

Even if they did, they might have independent DT blob with the data
required for the firmware to function.

The holy grail of system DT is yet to see the reality IMO.

And this rebuild is very much needed during development and updating
DT for the data makes no sense to me when the Linux kernel can query the
same through standard interfaces defined by the firmware. There can be
no argument to no use the interface to fetch the data runtime as it will
be most accurate than any other data. DT may have more data or data that
firmware decided not to support runtime for various reasons(I think I
mentioned couple earlier). So, strict no to static data from the DT and
even if some boot code updates it, I trust getting it from the firmware
if and when possible. The interface has been added considering all these.
It is agnostic of firmware designs and implementation. Assuming DT support
in the firmware just makes these unnecessarily hard.

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

Completely agreed in terms of design, but in reality not all implementations
want to follow that for reasons of their own.

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

Again agreed, but this is something we are enforcing in the Linux kernel
and U-Boot. It is not universal and IMO it may never be. The firmware
interfaces are defined to cope up with these and they are bound to stay.
DT can never replace it. Further like ACPI, these firmware interface
don't just provide static data, it also supports run-time. So there is
some advantage and are here to stay. Preferring DT data for sake of
uniformity and simplicity are not going to sway the wind away from these
interface to the DT. I am definitely not for it for all the reasons I have
already mentioned.

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

No I understand all these and advantages you have been mentioning. But
there is also other side of the story and that's what I have been trying
to group as firmware interface.

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

Yes definitely and I agree as mentioned quite a few times above. But that
doesn't change a bit as already mentioned.

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

If you strongly believe that, then you need to speak with architects who
are designing and standardising these interfaces taking with the various
Arm silicon vendors/partners. I am also sure your employer is one of them
and have their means to get in touch with the right people.

> As firmware gets more complex,

Indeed, they are already getting complex and it is necessitating the
need for such interfaces as we are dealing with dynamic component as well
not just static to use DT as standard and unified mechanism.

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

Well that would be ideal and I would have agreed with that few years back
but not now as I have seen the evolution in the firmware space(that I am
involved and visible to me) and involved in the development of some of these
interface.

Main point based on these discussion is that you are looking at just the
static data needed and how DT can be used. The interfaces are also dealing
with the dynamic configurations and while at it they better deal with
static data as well instead of using alternatives like DT. I am not against
DT for the reasons you think it must be used, it is just that here it is
not sufficient.

--
Regards,
Sudeep