On Wed, Jan 25, 2023 at 10:00:58AM -0600, Rob Herring wrote:
> On Tue, Jan 24, 2023 at 9:56 AM Abdellatif El Khlifi
> <abdellatif.elkhl...@arm.com> wrote:
> >
> > 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.
>
> So now instead of 1 binding being added, you are proposing 2 new
> bindings ("arm,smccc-1.2" and "arm,ffa")?
>
> Not only that, we'd have to support both the old way for all the
> existing platforms and the new way.
>
> > Th root node looks like this:
> >
> > firmware {
> > arm_smccc {
> >
> > compatible = "arm,smccc-1.2";
>
> Stop here. That's all that needs to be in the DT. The rest is
> discoverable. If we could redesign everything, then this is what we
> would have. A node saying we have SMCCC. But we can't just redesign
> everything. However, we already have such a node with the PSCI node
> because PSCI implies SMCCC.
>
> What u-boot needs is a driver for "arm,smccc-1.2" that then
> instantiates FFA, PSCI, TRNG, etc. without DT. Except that it would
> match on "arm,psci" instead of "arm,smccc-1.2".
>
> Rob
Thanks Rob. I already suggested something similar in a newer message,
please have a look [1]. But the approach I'm suggesting is without using a PSCI
node anymore.
Hopefully, the community would be interested in updating the older discovery
designs
to use the one and only DT node: arm_smccc.
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.
firmware {
arm_smccc {
compatible = "arm,smccc-1.2";
};
};
As a proof of concept, we can provide a first example with FF-A. Other SW
features (e.g: PSCI, optee, future ones, ...) can be added later on and
replace the older way of discovery.
Future SW features using SMC can be discovered by arm_smccc as well.
We can document this approach in U-Boot/Linux so future developments
will follow this approach.
[1]:
https://lore.kernel.org/all/20230125105511.ga31...@e121910.cambridge.arm.com/
Kind regards,
Abdellatif
