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

[Sudeep Holla]

On Thu, Jan 19, 2023 at 10:22:07AM -0700, Simon Glass wrote:
> Hi Sudeep,
> 
> On Thu, 19 Jan 2023 at 10:09, Sudeep Holla <sudeep.holla at arm.com> wrote:
> >
> > On Thu, Jan 19, 2023 at 11:57:44AM -0500, Tom Rini wrote:
> > >
> > > But it's also true that at run-time, within U-Boot, we can modify the
> > > device tree we have, with live tree yes? So, the whole series in
> > > question here can be done without modifying the base DT and getting in
> > > to the further discussions that doing so entails. The assertion is that
> > > the software discoverable bus here is sufficient to not need DT, so, OK,
> > > lets go.
> >
> > OK, may be I am not up-to-date on the U-Boot. IIUC, the modifications
> > done in the DT by U-Boot is mostly for consumption by the next stage
> > loader/OS and not for self-consumption. But if it is for self consumption,
> > then good. It helps especially for the subnodes(as Simon referred) or the
> > partitions that can be discovered at run-time using FF-A interface.
> 
> It's really just dodging the issue though, because you need a
> compatible string and you might as well add it to the DT in the source
> as do it at runtime.
>

Well that is one of the argument assuming DT node is a must. But adding
DT node requirement when it is not needed can be seen an issue itself if
one has to play devil's advocate here.

> >
> > As mentioned I am not again DT, it is just not needed and especially
> > for subnodes it could result in inconsistency b/w what is in DT and
> > what the firmware provides. As mentioned in previous response, having a
> > simple node that Simon provided as example earlier is fine by me if that
> > is the only option to make progress as I just feel it is redundant and
> > one can say not scalable(but that is debatable again 😄).
>
> Gosh, how many of these things are you going to add? I believe the
> inconsistency argument is dealt with by the bind/probe explanation. It
> may be redundant in Linux but I doubt it would hurt there either.
>

Not really. Currently the number of partitions is static and all of them
are bundled into on or few binaries. But we could have dynamic partitions
in the future. More over it is pain to update the DT for each possible
configuration especially during development where you want to experiment
things around. Having to deal with the DT for every small change in the
config is just annoying. Yes one could have universal list of partitions
and defer it to be dealt at probe/bind, but not sure if it is possible
to have such a universal list during development. We may have it handy
for production but we also want to ease development here.

In short, I have had quite a lot of issues with DT and firmware
inconsistency due to duplication of same data at the beginning and the
things diverged. So I am simply not ready to go back there and I am sure
quite a few in the kernel community have their fingers bitten because of
such inconsistency created by *unnecessary static addition of data* to
the DT. So, let me be clear, I wouldn't use the information from the
DT if I can get more accurate one dynamically from the firmware in the
kernel driver.

-- 
Regards,
Sudeep