Hi Abdellatif, On Thu, 19 Jan 2023 at 09:32, Abdellatif El Khlifi <abdellatif.elkhl...@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 <tr...@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.elkhl...@arm.com/#Z31doc:arch:arm64.ffa.rst > [7] FF-A MM comms: > https://lore.kernel.org/all/20221122131751.22747-10-abdellatif.elkhl...@arm.com/ > > > > -- > > Tom > >