On Fri, Mar 26, 2021 at 05:26:52PM +0530, Sumit Garg wrote:

On Fri, 26 Mar 2021 at 16:25, Sudeep Holla [off-list ref] wrote:

quoted

On Fri, Mar 26, 2021 at 10:35:23AM +0530, Sumit Garg wrote:

quoted

Hi Sudeep,

Apologies for catching up late on this patch-set.

On Thu, 25 Mar 2021 at 20:05, Sudeep Holla [off-list ref] wrote:

quoted

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