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

[Sumit Garg <sumit.garg@linaro.org>]

On Fri, 26 Mar 2021 at 16:25, Sudeep Holla <sudeep.holla@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@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.

-Sumit

> --
> Regards,
> Sudeep
>
> [1] https://lore.kernel.org/linux-arm-kernel/20201216134659.GA4146223@jade/
> [2] https://lore.kernel.org/linux-arm-kernel/20210113092236.pnabzaufzuzwprmw@bogus/