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.
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.
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.
Thanks,
Stuart
