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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.