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

[Tom Rini]

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

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230119/4d3f6ba5/attachment.sig>