From: David Laight <david.laight.linux@gmail.com>
To: Colin Ian King <coking@nvidia.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>,
Sumit Garg <sumit.garg@kernel.org>,
op-tee@lists.trustedfirmware.org,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][next] optee: make read-only array attr static const
Date: Sat, 17 Jan 2026 14:10:31 +0000 [thread overview]
Message-ID: <20260117141031.1514faf2@pumpkin> (raw)
In-Reply-To: <20260109154442.421248-1-coking@nvidia.com>
On Fri, 9 Jan 2026 15:44:42 +0000
Colin Ian King <coking@nvidia.com> wrote:
> Don't populate the read-only array attr on the stack at run
> time, instead make it static const.
For a 4 byte array initialising on stack is likely to generate faster code.
In particular it avoid a very likely data-cache miss for the rodata.
The on-stack array access might even shorter code than accessing a global
array on some architectures.
The compiler might, of course, decide to unroll the loop and not instantiate
the array at all (in either case).
Indeed, just unrolling the loop as:
if (params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT) goto bad;
if (params[1].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT) goto bad;
if (params[2].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT) goto bad;
if (params[3].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT) goto bad;
is likely to be pretty near optimal.
(Collecting the bytes and doing a single 32bit compare may be better.)
Of course this won't be a massively hot path - so the code choice won't
make a measurable difference.
David
>
> Signed-off-by: Colin Ian King <coking@nvidia.com>
> ---
> drivers/tee/optee/rpc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
> index 97fc5b14db0c..1758eb7e6e8b 100644
> --- a/drivers/tee/optee/rpc.c
> +++ b/drivers/tee/optee/rpc.c
> @@ -43,7 +43,7 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
> struct i2c_msg msg = { };
> size_t i;
> int ret = -EOPNOTSUPP;
> - u8 attr[] = {
> + static const u8 attr[] = {
> TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
> TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
> TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT,
prev parent reply other threads:[~2026-01-17 14:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 15:44 [PATCH][next] optee: make read-only array attr static const Colin Ian King
2026-01-12 11:26 ` Sumit Garg
2026-01-12 14:46 ` ryan foster
[not found] ` <DS0PR12MB8294F8C07E39842AC16CBA21AF81A@DS0PR12MB8294.namprd12.prod.outlook.com>
2026-01-16 9:14 ` Sumit Garg
2026-01-17 11:33 ` Jens Wiklander
2026-01-12 15:15 ` Dan Carpenter
2026-01-17 14:10 ` David Laight [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=20260117141031.1514faf2@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=coking@nvidia.com \
--cc=jens.wiklander@linaro.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=op-tee@lists.trustedfirmware.org \
--cc=sumit.garg@kernel.org \
/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