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

[Sudeep Holla]

Hi Simon,

On Thu, Jan 19, 2023 at 11:04:16AM -0700, Simon Glass wrote:
[...]

>
> Well we already have the code, right...?
>

Correct, that what we would like to see.

> The entire device tree is optional. We could just use platform data or
> even C function calls to set up devices. We could call a C function
> for each board which builds a device tree early in boot. Etc... As I
> remember it, no one wanted to use DT and it was only Linus Torvalds'
> refusal to accept another ARM pull request that made people move away
> from platform data and other ad-hoc mechanisms. I'll note that U-Boot
> adopted DT on ARM in 2011, the same year as Linux [1] [2]. Since then
> huge strides have been made in many ways, e.g. loads of useful
> bindings and Rob Herring's validation stuff.
>

OK here is where I differ from your understanding. DT for mainly to replace
platform specific data. And though firmware is *platform specific*,
the firmware interface itself is not and can be compared to architecture
features. Do we define all Arm architecture specific features in the
DT, the answer is clearly no, unless there is something missed in the
architecture specification and too late to add anything to support
platforms in the wild.

Similarly, the some of these standard firmware interfaces are to avoid
such platform description in DT or ACPI. There are self discoverable like
some of the architecture features. It is just in software rather than the
hardware.

> IMO the problem here is exactly because of the point I mentioned. I
> suspect the reason no one wants to add a compatible string for the
> top-level FF-A device is that it will be rejected by Linux and they
> don't want another case of PTSD (I am willing to take that on if it
> helps). I'm sorry that we are in this situation, but it is not going
> to be fixed by ignoring the problem. It is causing all sorts of
> work-arounds [3], is bad for project interoperability (and therefore
> the open source industry as a whole), wastes a huge amount of time in
> discussion and gives device tree a bad name[4]. It really, really
> needs to stop.

I am not sure if that is the reason for ACPI adoption TBH. IMO both
have their own advantage and disadvantage. The idea is to try to minimise
the deviation between the two(not on a wider scope though). The firmware
interfaces like FF-A avoids the needs for any description of the feature
in DT or ACPI all together and hence avoids any such deviation problems.

>
> Can we all agree to work together on this and see device tree as a
> shared technology and resource, across firmware and OS? Could this be
> the last thread on this topic?
>

With the mention of ACPI now I just can't think how do you propose to
use DT as shared tech/ resource across f/w and OS when ACPI is used.

For sure if something is not discoverable, they need to be described in
DT and hence in ACPI too, but FF-A is not one such feature and I have no
justification to add it in ACPI other than "DT has it, so lets add even
if it is unnecessary".

In summary, look at FF-A as software architecture feature that can be
discovered and not as a platform specific feature that needs platform
specific data from DT or ACPI.

--
Regards,
Sudeep