Hi Tom,
On Thu, 19 Jan 2023 at 09:57, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 19, 2023 at 09:54:29AM -0700, Simon Glass wrote:
Hi Sudeep,
On Thu, 19 Jan 2023 at 09:46, Sudeep Holla sudeep.holla@arm.com wrote:
Hi Abdellatif,
On Thu, Jan 19, 2023 at 04:31:57PM +0000, Abdellatif El Khlifi wrote:
Hi Simon, Tom,
The FF-A transport is a SW bus and is not associated to any HW peripheral or undiscoverable base address.
There is only 1 way of discovering the FF-A bus and it's through the FF-A SW interfaces. The FF-A spec [1] describes this in details.
Discovering means gathering information about the FF-A framework such as: the FF-A version, supported features, secure partitions number and attributes.
Please refer to the following paragraphs for more details: [2], [3], [4], [5]
The core driver provided by this patchset implements the Setup and discovery interfaces in addition to direct messaging.
The driver provides ffa_bus_discover() API that allows to discover the FF-A bus as described by the spec and in the FF-A driver readme [6].
We expect and highly recommend FF-A users to always discover the FF-A bus using ffa_bus_discover() API.
Thanks for the details. But IIRC this discussion is not about the FF-A bus and device(partitions) discovery, but the support for FF-A itself. The discussion is about where to have a device node to represent the existence of FF-A support on a platform. If we are talking about individual partitions (devices) in the device tree, then that is pure stupidity as it goes out of since with the firmware the moment a partition is added or removed in the firmware.
IIUC, the whole discussion was around whether to use FFA_VERSION as the discovery mechanism for existence of FF-A support on a platform or you have a device node to specify the same.
No, with respect, that is not quite the situation here.
Just to be clear, even if it is decided to add a device node, the FFA_VERSION must be used to detect the presence of FF-A support and return error otherwise. DT node presence is just to satisfy the design and must be treated as no auto-confirmation for the presence of FF-A support. We are just arguing the device node presence is just redundant, but as mentioned before it is up to U-Boot community to make a call on what is best.
U-Boot driver model design already supports this. You can have a device that binds (from DT) but will not probe because it is not present / wrong version. Perhaps this was missed in the conversion to Linux:
https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#dri...
So there is nothing clever needed here at all and anything you do just adds confusion and bad precedent.
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.
One of the reasons that I find this all so frustrating is that it is circular logic:
1. Device-tree bindings are controlled by Linux; U-Boot cannot upstream bindings 2. We can only have upstreamed bindings in any device tree
We have invented a whole u-boot.dtsi feature in U-Boot to hold modifications from Linux. Board vendors have been suffering with this for years.
It is not fair and it really needs to stop. I am doing what I can to upstream some basic U-Boot bindings and I hope that will work and can lead to a healthier relationship here.
Regards, Simon