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

Thu Jan 19 17:41:12 CET 2023

Hi Abdellatif,

On Thu, 19 Jan 2023 at 09:32, Abdellatif El Khlifi
<abdellatif.elkhlifi at arm.com> wrote:
>
> On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote:
> > On Wed, Jan 18, 2023 at 01:46:54PM +0000, Sudeep Holla wrote:
> > > On Wed, Jan 18, 2023 at 12:49 PM Tom Rini <trini at konsulko.com> wrote:
> > >
> > > >
> > > > I guess the problem comes down to, can we have one discovery method that
> > > > everyone shares, or do we have to let everyone invent a new discovery
> > > > method every time?
> > >
> > >
> > > No one needs to invent any discovery method every time if the firmware
> > > specification
> > > provides one and as Rob mentioned many times in the thread, all new firmware
> > > specification must provide one and we are trying to make sure that is
> > > the case with all new
> > > specs from Arm.
> > >
> > >
> > > > FF-A, Op-tee, U-Boot, coreboot, barebox (and
> > > > everyone else I'm unintentionally forgetting) could just discover these
> > > > things via device tree.
> > >
> > >
> > > I leave that to the individual projects to decide and agree but
> > > fundamentally if
> > > the specification provides a way to discover, not sure why we are even
> > > discussing
> > > an alternative method here.
> > >
> > >
> > > > Or, we could all write our own code to perform
> > > > the discovery.
> > >
> > >
> > > For what reason ? I can understand if there is no discovery mechanism but
> > > that's not the
> > > case in $subject.
> > >
> > >
> > > > And when RISC-V comes along with similar functionality,
> > > > we could probe their device tree and see they've implemented the same
> > > > concept, but a little differently, but still have the discovery portion
> > > > be in the device tree. To which it sounds like your answer is "not in
> > > > the device tree".
> > > >
> > >
> > > I see U-boot seem to have made a decision to create DT node for each and
> > > everything
> > > that needs to be added to DM which seems bit unfortunate but I don't
> > > understand the
> > > history/motive/background for it but I respect the decision if it is
> > > already made.
> > >
> > > These firmware interfaces are standard on all Arm platforms and can be
> > > discovered
> > > based on PSCI/SMCCC. Not using the same and use DT node needs unnecessary
> > > addition of DT nodes for all the f/w i/f on all the platforms that need the
> > > support when
> > > one can be just discovered.
> > >
> > > Sorry for the sudden appearance on this thread, I was avoiding getting into
> > > this but thought
> > > I will at least express my opinion and also the way the firmware
> > > specifications from Arm is
> > > expected to be evolved from now on. With that I will leave it to you and
> > > other U-boot
> > > maintainers and the community in general to decide the right course in this
> > > case.
> >
> > To be clear, if the position is that "this is what everyone else will
> > use, really" then yes, we'll follow this in U-Boot.
>
> 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.

Can you add a DT node for the 'FF-A SW interfaces' and attach some
sort of top-level driver to that? Perhaps simple-bus, or your own
thing? You don't need to add compatible strings for subnodes (devices
that are discoverable within that).

If you don't want to submit the compatible string to Linux, I will do
it. If it has to have a 'u-boot,' prefix then so be it, but I don't
see why that is necessary, since Linux can ignore it if it likes.

We have been talking about this for far too long, IMO. Would you like
me to send a patch? It is something like this:

ff-a {
    compatible = "arm,ff-a";
};

>
> 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.
>
> A use case is provided which is the EFI MM communication [7].
>
> ffa_bus_discover() does the following:
>
> - creates, binds and probes the arm_ffa device
> - at probe level, discovery FF-A interfaces are called to try to discover the FF-A framework
> - when all discovery interfaces succeed, probing is successful and FF-A bus is ready to use
> - if one of the discovery interfaces fails, the arm_ffa device is removed from the DM and
>   FF-A bus can not be used

This is not how things are supposed to work in U-Boot. Please read the
documentation which is here:

https://u-boot.readthedocs.io/en/latest/develop/driver-model/index.html

So referencing above:

1, No, the binding of the ff-a device should happen automatically from the DT
2. probing ff-a causes the other devices to be bound (as with PCI,
USB, every other bus in U-Boot)
3. Yes
4. No, you must not unbind it. It just sits there unprobed and cannot
be used. We might want to have a command that looks at what is wrong
with it. Probing the device should produce an error, as with every
other device in U-Boot

I am happy to discuss this on a call if we really cannot do this by
email. Or I can send a patch...but please read the documentation and
avoid adding special cases for this interface.

Regards,
Simon

>
>
> Cheers
> Abdellatif
>
> [1]: FF-A spec version 1.0, https://developer.arm.com/documentation/den0077/latest/
>
> [2] 2.8 Partition identification and discovery
>
>     All FF-A components can discover the identities and properties of other partitions through the FFA_PARTITION_INFO_GET
>     interface. Once discovered, the IDs must be used in the messaging interfaces to identify the target of a message.
>
> [3] 4.2.2.2 Buffer discovery and setup
>
>     This version of the Framework enables discovery and setup of RX/TX buffer pairs between FF-A components as
>     follows.
>
>     ...
>
>     2. An endpoint could allocate the buffer pair and use the FFA_RXTX_MAP interface to map it with the
>     Hypervisor or SPM as applicable.
>
> [4] 4.2.2.3 Buffer attributes
>
>     An endpoint must discover the minimum size and alignment boundary for the RX/TX buffers by passing the
>     function ID of the FFA_RXTX_MAP ABI as input in the FFA_FEATURES interface (see 8.2 FFA_FEATURES).
>
> [5] 6.1.1 Common compliance requirements
>
>     - It must be possible for the FF-A components at an FF-A instance to discover the presence and version number
>     of their Framework implementations through the FFA_VERSION interface (see 8.1 FFA_VERSION).
>
>     - All FF-A components must implement support for Setup and discovery interfaces described in Chapter 8
>     Setup and discovery interfaces. These interfaces are as follows.
>
>     FFA_VERSION.
>     FFA_FEATURES.
>     FFA_RX_RELEASE.
>     FFA_RXTX_MAP.
>     FFA_RXTX_UNMAP.
>     FFA_PARTITION_INFO_GET.
>     FFA_ID_GET.
>
>     - It must be possible for an FF-A component, at the lower EL at an FF-A instance to use the FFA_FEATURES
>     interface (see 8.2 FFA_FEATURES) to discover if an FF-A interface is implemented by the FF-A component
>     at the higher EL.
>
> [6] FF-A support readme: https://lore.kernel.org/all/20221122131751.22747-4-abdellatif.elkhlifi@arm.com/#Z31doc:arch:arm64.ffa.rst
> [7] FF-A MM comms: https://lore.kernel.org/all/20221122131751.22747-10-abdellatif.elkhlifi@arm.com/
> >
> > --
> > Tom
>
>