[PATCH 0/6] introduce Arm FF-A support

[Sudeep Holla]

On Tue, Aug 02, 2022 at 08:22:19AM -0400, Tom Rini wrote:
> On Mon, Aug 01, 2022 at 08:28:08PM +0100, Sudeep Holla wrote:
> > On Mon, Aug 01, 2022 at 01:13:23PM -0600, Simon Glass wrote:
> > > On Wed, 13 Apr 2022 at 10:46, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > How is it both discoverable and doesn't have a device tree node, in the
> > > > kernel?
> > >
> > > Also, if it is discoverable, we can still use U-Boot to discover it
> > > and then pass the info to Linux in the DT.
> > >
> > 
> > Why ? Linux can discover the presence of the feature with a simple SMCCC
> > based query. We don't need any DT bindings for this particular feature.
> > Not sure if you are talking in general or in the context of $subject
> > feature in the kernel.
> > 
> > > I am seeing several series which don't have 'proper' DT bindings in
> > > Linux. First I heard it was for legacy reasons, but now I am hearing
> > > something different. For U-Boot, we really do need to have DT bindings
> > > for devices. All this ad-hoc creation of stuff makes things hard to
> > > discover, adds to code size and makes things like of-platdata
> > > impossible.
> > >
> > 
> > I may not have the complete picture here. If you are saying that every
> > feature in the u-boot needs DT for some reason, then that's U-boot's
> > limitation or restriction. But just the presence of node means nothing
> > until the corresponding feature is queried and confirmed to be present
> > in the firmware. That is very important as we can't skip the query stage
> > just because of presence of some DT node for this.
> > 
> > > Furthermore, if the bindings affect U-Boot, then the U-Boot project
> > > should have a say in what is being done there, not just be downstream
> > > of all such changes.
> > >
> > 
> > I still think you talking about some issue in general and it doesn't
> > apply in this case. The new firmware interfaces are designed to be
> > discoverable which is the main advantage over any non discoverable
> > hardware and/or firmware interface. One main advantage I see is that we
> > don't need any DT bindings which makes the firmware upgrades must simpler
> > as the users can query the interface and know exactly what they need
> > instead of relying on DT node which may get stale if not updated with the
> > firmware update. I am not sure if whatever I am writing here is relevant
> > to what your concerns are as I think I haven't understood them fully.
> 
> Part of the problem I think here is who does have a more complete
> picture of things? Saying there's a DT binding available is generally
> the firmware interface for discovering something exists somewhere else
> (excepting buses that define a discovery protocol).  Except not in this
> case where there's a different interface. So who defined that interface
> and where is it specified? What's already been accepted upstream to
> other projects?
>

Understood and agreed. Definitely need more background to sell some new
feature.

> We're on I think v4 of this series now, and it was this email here that
> explained that an SMCCC call is how Linux finds out this exists (or
> doesn't exist).
>

Ah that explains some of the confusion. Sorry I was not fully involved
in u-boot support in general and didn't pay much attention to the previous
versions. I would have presented the pointer to the specification to
start with instead of just the reference to the kernel implementation
as that might be biasing as well as the requirements may differ between
u-boot and the kernel.

Anyways, here is the specification[1]. Also in general, there are quite a
few new firmware interface based on SMCCC in the recent years and most of
them take care to ensure they can be discovered.

-- 
Regards,
Sudeep

[1] https://developer.arm.com/documentation/den0077/latest