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

[Sudeep Holla]

Hi Simon,

(sorry we just crossed the emails)

On Thu, Jan 19, 2023 at 09:41:12AM -0700, Simon Glass wrote:
>
> 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).
>

Thanks for putting this nicely. I just wrote the same thing probably in
not so simpler way. But I agree with you as Abdellatif last email talks
more around sub-nodes or child device nodes (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";
> };
>

Makes sense if DT node is the only way. It should be as simple as this
and presence of this must not imply presence of FF-A feature on the
platform. The driver must check using FFA_VERSION

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

Agreed on all points(assuming DT way here). Especially the last point,
there is no point is rolling back if one partion/device initialisation
fails or is not bound.

--
Regards,
Sudeep