[PATCH v5 1/7] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding

[Rob Herring]

On Fri, Mar 26, 2021 at 05:26:52PM +0530, Sumit Garg wrote:
> On Fri, 26 Mar 2021 at 16:25, Sudeep Holla <sudeep.holla at arm.com> wrote:
> >
> > On Fri, Mar 26, 2021 at 10:35:23AM +0530, Sumit Garg wrote:
> > > Hi Sudeep,
> > >
> > > Apologies for catching up late on this patch-set.
> > >
> > > On Thu, 25 Mar 2021 at 20:05, Sudeep Holla <sudeep.holla at arm.com> wrote:
> > > >
> > > > Since the FF-A v1.0 specification doesn't list the UUID of all the
> > > > partitions in the discovery API, we need to specify the UUID of the
> > > > partitions that need to be accessed by drivers within the kernel.
> > > >
> > >
> > > Wouldn't we be able to implement auto-discovery of ffa partitions? I
> > > think enumeration of ffa partitions on FFA bus should be quite similar
> > > to enumeration of TAs on TEE bus (see [1]). Otherwise we need to put
> > > these redundant DT entries for every ffa partition which IMHO would
> > > bloat up device trees for every platform.
> > >
> >
> > Any suggestions on how to ? Clearly spec doesn't have that provision, I
> > had raised this point in the past. Jens has similar concern and he did
> > ask the same[1]. As I replied to him in that thread[2].
> >
> > I am open to suggestion on how to auto-discover, currently as I see spec
> > doesn't support it.
> >
> 
> Thanks for sharing links to prior discussions and I can see that
> currently spec doesn't support it. But from an implementation
> perspective, I can't find any reason that we can't support
> auto-discover. Have a look at below proposed simple FFA ABI:
> 
> FFA_LIST_PARTITIONS
> 
> - No input params.
> - Returns an array of secure partition UUIDs to which this non-secure
> virtual/physical FF-A instance is allowed to communicate with.
> 
> I think with auto-discovery, one of the major benefits is that if the
> OEM is using a common platform to cater to multiple use-cases which
> rely on different secure partitions then OEM doesn't have to bother
> about shipping separate DTs.

+1

DT should not be the dumping ground for everything forgotten to be made 
discoverable. There's not much we can do about h/w, but firmware is 
different and can be changed. In other threads (e.g. PCI config space 
SMC calls), fixing in firmware is the proposed answer. So let's do that 
here.

Maybe if there are implementations shipping and changing is too late 
(yet not too late to use a new binding), then I'd feel differently. But 
being in a spec or not alone is not enough reason alone to accept this. 
It's obvious the spec did not have wide enough review.

Rob