Platforms that support FF-A direct message request v2 can implement Secure Partitions (SPs) that host multiple services. When the TPM service shares its SP with other services, message requests from the driver may fail with a BUSY response if another service is currently active.
To improve robustness in such scenarios, we need to introduce retry logic in the driver. When a BUSY error is received, the driver will re-attempt the TPM request until it succeeds or a run-time configurable timeout(default: 2000 ms) is reached. This ensures reliable TPM access under shared-SP conditions. Add a module parameter, `busy_timeout_ms`, which specifies the maximum amount of time (in milliseconds) to retry on BUSY before giving up. This change builds on top of commit a85b55ee64a5, which introduced support for TPM service communication using the FF-A direct message v2 path, in accordance with section 3.3 of the TPM Service Command Response Buffer Interface specification. https://developer.arm.com/documentation/den0138/latest/ This was tested with an FF-A based fTPM currently not publicly available. There are plans to open source the fTPM. Changes in v6: - Typo fixes in function name. - Introduce __tpm_crb_ffa_try_send_receive. - Modify tpm_crb_ffa_send_receive to use the new function with retry logic. - Use memzero() macro instead of memset() for clearing buffers. Prachotan Bathi (2): tpm_crb_ffa: Fix typos in function name tpm_crb_ffa: handle tpm busy return code drivers/char/tpm/tpm_crb_ffa.c | 70 ++++++++++++++++++++++++++-------- 1 file changed, 55 insertions(+), 15 deletions(-) -- 2.43.0
