Re: [PATCH 0/4] Add support for the TPM FF-A start method

[Sudeep Holla]

On Fri, Feb 21, 2025 at 12:29:03PM -0600, Stuart Yoder wrote:
>
>
> On 2/21/25 8:02 AM, Sudeep Holla wrote:
> > Hi Sumit,
> >
> > On Fri, Feb 21, 2025 at 07:16:35PM +0530, Sumit Garg wrote:
> > > On Mon, Feb 17, 2025 at 10:56:58AM -0600, Stuart Yoder wrote:
> > > >
> > > > I don't see how changing TPM discovery to be via FF-A directly
> > > > would improve maintainability.
> > >
> > > You are considering ACPI at this point but when people want to use this
> > > TPM over FF-A on a platform using DT then it will require corresponding
> > > DT bindings. After that each platform has to enable TPM over FF-A in
> > > their corresponding ACPI/DT. All that won't be needed with auto
> > > discovery over FF-A.
>
> Yes, we would need a new DT binding.
>

Not sure how that would look like, so I will hold off my comments on this
topic. But we really should strive towards auto-discovery as much as possible.

> > I hear you and completely agree. However, someone thought it was a good idea
> > to align with other start methods and duplicate information in the TCG ACPI
> > specification. This is definitely a bad idea, as it may contradict the
> > firmware. All we needed was a simple flag to indicate whether FF-A is the
> > start method.
>
> Do you mean a flag exposed via ACPI?  If you do FF-A based discovery you
> don't even need that.  Everything could be determined via an FF-A
> interface.
>
> > It sounds like a classic case of misalignment between specification authors
> > and practical implementation needs. Instead of a simple flag to indicate FF-A
> > as the start method, duplicating information in the TCG ACPI specification
> > seems unnecessary and potentially problematic—especially if it risks
> > conflicting with firmware behavior.
>
> There is a lot of history, but I think it was simply that ACPI
> advertisement of an FF-A based TPM seemed like the approach
> with the least friction. And Linux is not the only target OS.
>

I guess so. I understand sometimes we need to consider multiple target OS.

> > Anyway, I can't comment on how we ended up here, but this seems to be the reality.
>
> I don't think we are locked into ACPI (or DT) only discovery.
> It's possible that with a modest delta on top of this patch series
> that the tpm_crb driver could also probe based on FF-A.
>
> The CRB over FF-A spec (DEN0138) could be extended in a backwards
> compatible way to expose additional info like the base address of the
> CRB.
>

Ideally, we should manage with dynamic buffers. But I do understand the
reasons why we may need static curve outs. I prefer the ffa client driver
take care of that without needing to build FF-A bindings just for that.

I will wait and see how all these shape up (soon ?)

--
Regards,
Sudeep