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

[Tom Rini]

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?

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).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220802/3751588e/attachment.sig>