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

[Simon Glass]

Hi Sudeep,

On Thu, 19 Jan 2023 at 09:46, Sudeep Holla <sudeep.holla at 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#driver-lifecycle

So there is nothing clever needed here at all and anything you do just
adds confusion and bad precedent.

Regards,
Simon