On Mon, Jan 23, 2023 at 09:32:28AM -0700, Simon Glass wrote: > Hi Rob, > > On Mon, 23 Jan 2023 at 08:13, Rob Herring <r...@kernel.org> wrote: > > > > On Fri, Jan 20, 2023 at 4:04 PM Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Rob, > > > > > > On Thu, 19 Jan 2023 at 11:11, Rob Herring <r...@kernel.org> wrote: > > > > > > > > On Thu, Jan 19, 2023 at 10:41 AM Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > 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). > > > > > > > > We already have that. It's just called 'arm,psci'. FF-A is not the > > > > top-level thing. SMCCC is. That's unfortunately called PSCI in DT > > > > because SMCCC grew out of PSCI. Evolution is ugly... > > > > > > > > It's like this: > > > > > > > > SMCCC > > > > +--PSCI > > > > +--TRNG > > > > +--FF-A > > > > +--SCMI (sometimes) > > > > +--OP-TEE > > > > +--...Whatever Arm comes up with next... > > > > > > OK well that sounds OK. > > > > > > So what is the problem here? We have an SMCCC top-level thing in the > > > DT and everything else can be bound from that, right? Are people on > > > this thread not aware of this...or am I still missing something? > > > > > > Can you point to the SMCCC driver in U-Boot? Is this > > > bind_smccc_features(), i.w.c. it looks like it does what I want...why > > > does this thread exist? > > > > I imagine the u-boot structure for all this has evolved like the > > bindings where each feature was developed independently. From my brief > > look at it, initialization of all the above features would need to be > > reworked to work as described. > > OK, then perhaps this is making more sense to me now. > > Abdellatif, can you please look at the above? We should have one > top-level node in the DT and have that driver bind the child devices. > > Regards, > Simon
Hi Simon, Rob, I'd like to suggest the creation of a root node called arm_smccc as shown below. This node is the parent of all nodes using SMC calls like FF-A, PSCI, optee, ... The first child to be integrated in the arm_smccc root node is FF-A. Hopefully, in the future the other features such as PSCI could be integrated under arm_smccc as well. Th root node looks like this: firmware { arm_smccc { compatible = "arm,smccc-1.2"; arm_ffa { compatible = "arm,ffa"; method = "smc"; }; psci { compatible = "arm,psci"; method = "smc"; }; optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; }; What do you think guys ? Kind regards, Abdellatif