On Wed, Jan 25, 2023 at 10:55:11AM +0000, Abdellatif El Khlifi wrote:
Hi Simon, Rob, Sudeep
I'm tweaking my previous suggestion regarding the creation of a new arm_smccc root node..
This node is the parent of all SW features using SMC calls like FF-A, PSCI, optee, ...
However, no child node is created in the DT. The SW features are seen as architecture features and can be discovered by querying through SMC calls.
So, when probed the arm_smccc device driver tries to discover the SW features (FF-A, PSCI, optee, ...) by calling xxx_discover() API for each feature ( e.g: ffa_discover() ).
The xxx_discover() creates U-Boot device(s) for the feature and set arm_smccc as the parent.
"dm tree" command should show:
SMCCC +--PSCI +--TRNG +--FF-A +--SCMI (sometimes) +--OP-TEE +--...Whatever Arm comes up with next...
As Sudeep suggested, we only need this node:
firmware { arm_smccc { compatible = "arm,smccc-1.2"; }; };
What do you think guys ? Are you happy with this approach ?
This looks good to me. No objections binding per se.
However if you look at Rob's earlier comments, due to the way all these firmware specs evolved and hence the corresponding binding, though PSCI uses SMCCC like all other specs in the above list/tree, the PSCI binding was introduced along with its implementation in the kernel. Also the fact that until SMCCC v1.1, there was no version query feature in SMCCC and PSCI_FEATURE was used instead. It is handled in the same way in the kernel today.
Not sure if that is the reason Rob suggested just using PSCI node like we do in the kernel today.
As I mentioned I am not against your suggestion as it would be the best way to start if we were doing it today, but we have legacy to handle. Let us see what is Rob's opinion. If we decide not to use PSCI like in the kernel and add this new SMCCC, we may have to handle that in the kernel and also preferably add checks in DTC to not have PSCI node if SMCCC is present or something on that lines.
-- Regards, Sudeep