From: Jarkko Sakkinen <jarkko@kernel.org>
To: Prachotan Bathi <prachotan.bathi@arm.com>
Cc: Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
Stuart Yoder <stuart.yoder@arm.com>,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/1] tpm_crb_ffa: handle tpm busy return code
Date: Tue, 17 Jun 2025 17:40:24 +0300 [thread overview]
Message-ID: <aFF-WNSolTdV9PZG@kernel.org> (raw)
In-Reply-To: <20250613233132.4167653-2-prachotan.bathi@arm.com>
On Fri, Jun 13, 2025 at 06:31:32PM -0500, Prachotan Bathi wrote:
> For CRB over FF-A interface, if the firmwre TPM or TPM service [1] shares
> its Secure Partition (SP) with another service, message requests may
> fail with a -EBUSY error. Platforms supporting direct message request v2[1]
> can support secure partitions that support multiple services.
>
> To handle this, replace the single check and call with a retry loop
> that attempts the TPM message send operation until it succeeds or a
> configurable timeout is reached. The retry mechanism introduces a
> module parameter (`busy_timeout`, default: 2000ms) to control how long
> to keep retrying on -EBUSY responses. Between retries, the code waits
> briefly (50-100 microseconds) to avoid busy-waiting and handling
> TPM BUSY conditions more gracefully.
>
> [1] TPM Service Command Response Buffer Interface Over FF-A
> https://developer.arm.com/documentation/den0138/latest/
>
> Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com>
> ---
> drivers/char/tpm/tpm_crb_ffa.c | 74 +++++++++++++++++++++++-----------
> 1 file changed, 50 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> index 4ead61f01299..e47e110bac9e 100644
> --- a/drivers/char/tpm/tpm_crb_ffa.c
> +++ b/drivers/char/tpm/tpm_crb_ffa.c
> @@ -10,6 +10,8 @@
> #define pr_fmt(fmt) "CRB_FFA: " fmt
>
> #include <linux/arm_ffa.h>
> +#include <linux/delay.h>
> +#include <linux/moduleparam.h>
> #include "tpm_crb_ffa.h"
>
> /* TPM service function status codes */
> @@ -178,6 +180,17 @@ int tpm_crb_ffa_init(void)
> }
> EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
>
> +static unsigned int busy_timeout = 2000;
> +/**
> + * busy_timeout - Maximum time to retry before giving up on busy
> + *
> + * This parameter defines the maximum time in milliseconds to retry
> + * sending a message to the TPM service before giving up.
> + */
> +module_param(busy_timeout, uint, 0644);
> +MODULE_PARM_DESC(busy_timeout,
> + "Maximum time to retry before giving up on busy");
> +
> static int __tpm_crb_ffa_send_recieve(unsigned long func_id,
there's BTW a typo ;-) s/recieve/receive
Not your fault but maybe it would make sense to correct that anyhow...
> unsigned long a0,
> unsigned long a1,
> @@ -191,34 +204,47 @@ static int __tpm_crb_ffa_send_recieve(unsigned long func_id,
Maybe this would be less exhausting if you instead would work out the
existing function something like __tpm_crb_ffa_try_send_receive() and
call that in a loop? It would be then similar organization as with
tpm_transmit().
>
> msg_ops = tpm_crb_ffa->ffa_dev->ops->msg_ops;
>
> - if (ffa_partition_supports_direct_req2_recv(tpm_crb_ffa->ffa_dev)) {
> - memset(&tpm_crb_ffa->direct_msg_data2, 0x00,
> - sizeof(struct ffa_send_direct_data2));
> + ktime_t start;
> + ktime_t stop;
> +
> + start = ktime_get();
> + stop = ktime_add(start, ms_to_ktime(busy_timeout));
> +
> + do {
> + if (ffa_partition_supports_direct_req2_recv(tpm_crb_ffa->ffa_dev)) {
> + memset(&tpm_crb_ffa->direct_msg_data2, 0x00,
> + sizeof(struct ffa_send_direct_data2));
nit: could use memzero() instead.
>
> - tpm_crb_ffa->direct_msg_data2.data[0] = func_id;
> - tpm_crb_ffa->direct_msg_data2.data[1] = a0;
> - tpm_crb_ffa->direct_msg_data2.data[2] = a1;
> - tpm_crb_ffa->direct_msg_data2.data[3] = a2;
> + tpm_crb_ffa->direct_msg_data2.data[0] = func_id;
> + tpm_crb_ffa->direct_msg_data2.data[1] = a0;
> + tpm_crb_ffa->direct_msg_data2.data[2] = a1;
> + tpm_crb_ffa->direct_msg_data2.data[3] = a2;
>
> - ret = msg_ops->sync_send_receive2(tpm_crb_ffa->ffa_dev,
> + ret = msg_ops->sync_send_receive2(tpm_crb_ffa->ffa_dev,
> &tpm_crb_ffa->direct_msg_data2);
> - if (!ret)
> - ret = tpm_crb_ffa_to_linux_errno(tpm_crb_ffa->direct_msg_data2.data[0]);
> - } else {
> - memset(&tpm_crb_ffa->direct_msg_data, 0x00,
> - sizeof(struct ffa_send_direct_data));
> -
> - tpm_crb_ffa->direct_msg_data.data1 = func_id;
> - tpm_crb_ffa->direct_msg_data.data2 = a0;
> - tpm_crb_ffa->direct_msg_data.data3 = a1;
> - tpm_crb_ffa->direct_msg_data.data4 = a2;
> -
> - ret = msg_ops->sync_send_receive(tpm_crb_ffa->ffa_dev,
> - &tpm_crb_ffa->direct_msg_data);
> - if (!ret)
> - ret = tpm_crb_ffa_to_linux_errno(tpm_crb_ffa->direct_msg_data.data1);
> - }
> + if (!ret)
> + ret = tpm_crb_ffa_to_linux_errno(tpm_crb_ffa->direct_msg_data2.data[0]);
> + } else {
> + memset(&tpm_crb_ffa->direct_msg_data, 0x00,
> + sizeof(struct ffa_send_direct_data));
>
> + tpm_crb_ffa->direct_msg_data.data1 = func_id;
> + tpm_crb_ffa->direct_msg_data.data2 = a0;
> + tpm_crb_ffa->direct_msg_data.data3 = a1;
> + tpm_crb_ffa->direct_msg_data.data4 = a2;
> +
> + ret = msg_ops->sync_send_receive(tpm_crb_ffa->ffa_dev,
> + &tpm_crb_ffa->direct_msg_data);
> + if (!ret)
> + ret = tpm_crb_ffa_to_linux_errno(tpm_crb_ffa->direct_msg_data.data1);
> + }
> + if (ret == -EBUSY)
> + pr_err("TPM says busy, trying again, value, ret: %d\n",
> + ret);
This is not an error condition but instead a legit condition, as far as
kernel is considered. Please, remove pr_err().
> + else
> + break;
> + usleep_range(50, 100);
> + } while (ktime_before(ktime_get(), stop));
>
> return ret;
> }
> --
> 2.43.0
>
BR, Jarkko
prev parent reply other threads:[~2025-06-17 14:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 23:31 [PATCH v4 0/1] tpm_crb_ffa: handle tpm busy return code Prachotan Bathi
2025-06-13 23:31 ` [PATCH v4 1/1] " Prachotan Bathi
2025-06-14 5:22 ` Paul Menzel
2025-06-17 14:40 ` Jarkko Sakkinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aFF-WNSolTdV9PZG@kernel.org \
--to=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
--cc=prachotan.bathi@arm.com \
--cc=stuart.yoder@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).