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