[PATCH 0/6] introduce Arm FF-A support

Wed Aug 3 12:14:12 CEST 2022

On Tue, Aug 02, 2022 at 08:22:19AM -0400, Tom Rini wrote:
> On Mon, Aug 01, 2022 at 08:28:08PM +0100, Sudeep Holla wrote:
> > On Mon, Aug 01, 2022 at 01:13:23PM -0600, Simon Glass wrote:
> > > On Wed, 13 Apr 2022 at 10:46, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > How is it both discoverable and doesn't have a device tree node, in the
> > > > kernel?
> > >
> > > Also, if it is discoverable, we can still use U-Boot to discover it
> > > and then pass the info to Linux in the DT.
> > >
> > 
> > Why ? Linux can discover the presence of the feature with a simple SMCCC
> > based query. We don't need any DT bindings for this particular feature.
> > Not sure if you are talking in general or in the context of $subject
> > feature in the kernel.
> > 
> > > I am seeing several series which don't have 'proper' DT bindings in
> > > Linux. First I heard it was for legacy reasons, but now I am hearing
> > > something different. For U-Boot, we really do need to have DT bindings
> > > for devices. All this ad-hoc creation of stuff makes things hard to
> > > discover, adds to code size and makes things like of-platdata
> > > impossible.
> > >
> > 
> > I may not have the complete picture here. If you are saying that every
> > feature in the u-boot needs DT for some reason, then that's U-boot's
> > limitation or restriction. But just the presence of node means nothing
> > until the corresponding feature is queried and confirmed to be present
> > in the firmware. That is very important as we can't skip the query stage
> > just because of presence of some DT node for this.
> > 
> > > Furthermore, if the bindings affect U-Boot, then the U-Boot project
> > > should have a say in what is being done there, not just be downstream
> > > of all such changes.
> > >
> > 
> > I still think you talking about some issue in general and it doesn't
> > apply in this case. The new firmware interfaces are designed to be
> > discoverable which is the main advantage over any non discoverable
> > hardware and/or firmware interface. One main advantage I see is that we
> > don't need any DT bindings which makes the firmware upgrades must simpler
> > as the users can query the interface and know exactly what they need
> > instead of relying on DT node which may get stale if not updated with the
> > firmware update. I am not sure if whatever I am writing here is relevant
> > to what your concerns are as I think I haven't understood them fully.
> 
> Part of the problem I think here is who does have a more complete
> picture of things? Saying there's a DT binding available is generally
> the firmware interface for discovering something exists somewhere else
> (excepting buses that define a discovery protocol).  Except not in this
> case where there's a different interface. So who defined that interface
> and where is it specified? What's already been accepted upstream to
> other projects?
> 
> We're on I think v4 of this series now, and it was this email here that
> explained that an SMCCC call is how Linux finds out this exists (or
> doesn't exist).
> 
> -- 
> Tom

Hi guys,

All your feedbacks are valuable and more than welcome. Thanks for all of you.

Sorry for any confusion, I'd like to highlight the following points:

1/ FF-A spec:

cover letter v1 already states that this work provides support for Arm Firmware Framework for Armv8-A v1.0 (please see [A])

Also, in the v1 patchset the documentation of the main config enabling the driver states that we are using the FF-A spec and the link is provided:

in ARM_FFA_TRANSPORT config:
+	  This driver is based on FF-A specification v1.0 and uses SMC32
+	  calling convention.
+
+	  FF-A specification:
+
+	  https://developer.arm.com/documentation/den0077/a/?lang=en

Please refer to [B] for more details.

2/ Linux:

The linux kernel driver has been referred to for showing that in linux FF-A is considered as a data bus and not just as a FW interface.

3/ FF-A bus discovery in u-boot:

In patchset v1 the FF-A bus was probed through a device tree node. Then, we got feedbacks from the device tree maintainer stating this won't be accepted.

This is why v2 version comes into the picture by making FF-A bus discoverable using device_{bind, probe} API

FF-A bus discovery in u-boot succeeds when all these operations are successful:

- querying the FF-A framework version
- querying from secure world the u-boot endpoint ID
- querying from secure world the supported features of the specified FF-A calls
- mapping the RX/TX buffers
- querying from secure world all the partitions information

These are done at ffa_probe level.

+/**
+ * ffa_probe - The driver probe function
+ * @dev:	the arm_ffa device
+ *
+ * Probing is done at boot time and triggered by the uclass device discovery.
+ * At probe level the following actions are done:
+ *	- setting the conduit
+ *	- querying the FF-A framework version
+ *	- querying from secure world the u-boot endpoint ID
+ *	- querying from secure world the supported features of the specified FF-A calls
+ *	- mapping the RX/TX buffers
+ *	- querying from secure world all the partitions information

In patchset v2 , ffa_bus_discover has been introduced and documented in the header (please refer to [D] and check the documentation of the functions: ffa_bus_discover , ffa_probe, ffa_get_device)

+	/* The FF-A bus discovery succeeds when probing is successful */
+	ret = device_probe(ffa_priv_data.dev);

4/ Feedbacks from Linaro:

We got new feedbacks from Linaro and we agreed to align the driver interfaces with those used in the kernel driver. Furthermore, we got a new requirement to make the driver independent from EFI. v3 patchset addresses that.

5/ in v3 cover letter, the full history of what each version brings are listed (please see [C])

6/ A detailed readme document has recently been written and will be added in the upcoming v4 patchset

cover letter 1:
[A] https://lore.kernel.org/all/20220329151659.16894-1-abdellatif.elkhlifi@arm.com/

kconfig of the driver:
[B] https://lore.kernel.org/all/20220329151659.16894-2-abdellatif.elkhlifi@arm.com/#Z31drivers:arm-ffa:Kconfig

cover letter 3:
[C] https://lore.kernel.org/all/20220801172053.20163-1-abdellatif.elkhlifi@arm.com/

patch introducing FF-A discovery:
[D] https://lore.kernel.org/all/20220415122803.16666-2-abdellatif.elkhlifi@arm.com/