[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241023212834.GB3736641@google.com>
Date: Wed, 23 Oct 2024 21:28:34 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Seshu Madhavi Puppala <quic_spuppala@...cinc.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>,
Adrian Hunter <adrian.hunter@...el.com>, linux-mmc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
quic_rampraka@...cinc.com, quic_nitirawa@...cinc.com,
quic_sachgupt@...cinc.com, quic_bhaskarv@...cinc.com,
quic_neersoni@...cinc.com, quic_gaurkash@...cinc.com
Subject: Re: [PATCH RFC v3 1/2] mmc: core: Add vendor hook to control
reprogram keys to Crypto Engine
On Sun, Oct 06, 2024 at 07:25:29PM +0530, Seshu Madhavi Puppala wrote:
> Add mmc_host_ops hook avoid_reprogram_allkeys to control
> reprogramming keys to Inline Crypto Engine by vendor as some
> vendors might not require this feature.
>
> Signed-off-by: Seshu Madhavi Puppala <quic_spuppala@...cinc.com>
> Co-developed-by: Ram Prakash Gupta <quic_rampraka@...cinc.com>
> Signed-off-by: Ram Prakash Gupta <quic_rampraka@...cinc.com>
> ---
> drivers/mmc/core/crypto.c | 8 +++++---
> drivers/mmc/host/sdhci.c | 6 ++++++
> include/linux/mmc/host.h | 7 +++++++
> 3 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/crypto.c b/drivers/mmc/core/crypto.c
> index fec4fbf16a5b..4168f7d135ff 100644
> --- a/drivers/mmc/core/crypto.c
> +++ b/drivers/mmc/core/crypto.c
> @@ -14,9 +14,11 @@
>
> void mmc_crypto_set_initial_state(struct mmc_host *host)
> {
> - /* Reset might clear all keys, so reprogram all the keys. */
> - if (host->caps2 & MMC_CAP2_CRYPTO)
> - blk_crypto_reprogram_all_keys(&host->crypto_profile);
> + if (host->ops->avoid_reprogram_allkeys && !host->ops->avoid_reprogram_allkeys()) {
> + /* Reset might clear all keys, so reprogram all the keys. */
> + if (host->caps2 & MMC_CAP2_CRYPTO)
> + blk_crypto_reprogram_all_keys(&host->crypto_profile);
> + }
This should be a simple flag, not an indirect function call which is
inefficient.
It could be a bit in mmc_host_ops, though based on the existing code maybe a new
bit in MMC_CAP2_* would be more appropriate.
- Eric
Powered by blists - more mailing lists