From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Neeraj Soni <neeraj.soni@oss.qualcomm.com>,
Debraj Mukhopadhyay <quic_dmukhopa@quicinc.com>,
Eric Biggers <ebiggers@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Adrian Hunter <adrian.hunter@intel.com>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, kernel@quicinc.com,
Neeraj Soni <quic_neersoni@quicinc.com>,
Ram Prakash Gupta <quic_rampraka@quicinc.com>,
Nitin Rawat <quic_nitirawa@quicinc.com>,
Sachin Gupta <quic_sachgupt@quicinc.com>,
Bhaskar Valaboju <quic_bhaskarv@quicinc.com>,
Gaurav Kashyap <quic_gaurkash@quicinc.com>,
Sarthak Garg <quic_sartgarg@quicinc.com>
Subject: Re: [PATCH v3] mmc: Avoid reprogram all keys to Inline Crypto Engine for MMC runtime suspend resume
Date: Thu, 8 Jan 2026 10:43:39 +0100 [thread overview]
Message-ID: <9a07d235-d1be-447b-ae89-75aa418cb69c@oss.qualcomm.com> (raw)
In-Reply-To: <42797330-868a-bfcd-e0bb-b5f0dd3eeb16@oss.qualcomm.com>
On 1/6/26 7:49 AM, Neeraj Soni wrote:
> Hi,
>
> Aplogies for replying so late to the queries.
>
> On 7/18/2025 5:35 PM, Konrad Dybcio wrote:
>> On 7/18/25 1:02 PM, Debraj Mukhopadhyay wrote:
>>> Crypto reprogram all keys is called for each MMC runtime
>>> suspend/resume in current upstream design. If this is implemented
>>> as a non-interruptible call to TEE for security, the cpu core is
>>> blocked for execution while this call executes although the crypto
>>> engine already has the keys. For example, glitches in audio/video
>>> streaming applications have been observed due to this. Add the flag
>>> MMC_CAP2_CRYPTO_NO_REPROG as part of host->caps2 to control reprogramming
>>> keys to crypto engine for socs which dont require this feature.
>>>
>>> Signed-off-by: Seshu Madhavi Puppala <quic_spuppala@quicinc.com>
>>> Co-developed-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
>>> Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
>>> Co-developed-by: Sarthak Garg <quic_sartgarg@quicinc.com>
>>> Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
>>> Signed-off-by: Debraj Mukhopadhyay <quic_dmukhopa@quicinc.com>
>>>
>>> ---
[...]
>>> @@ -459,6 +459,11 @@ struct mmc_host {
>>> #define MMC_CAP2_CRYPTO 0
>>> #endif
>>> #define MMC_CAP2_ALT_GPT_TEGRA (1 << 28) /* Host with eMMC that has GPT entry at a non-standard location */
>>> +#ifdef CONFIG_MMC_CRYPTO
>>> +#define MMC_CAP2_CRYPTO_NO_REPROG (1 << 29) /* Host handles inline crypto key reprogramming */
>>> +#else
>>> +#define MMC_CAP2_CRYPTO_NO_REPROG 0
>>> +#endif
>> This (and the crypto ifdef for MMC_CAP2_CRYPTO) looks like unnecessary
>> churn - crypto functions should never be called if the config is disabled
>> in the first place
> Do you suggest to remove #ifdef? I am not sure why #ifdef is used with MMC_CAP2_CRYPTO
> (may be to reuse the bits if config is not defined) but for MMC_CAP2_CRYPTO_NO_REPROG we
> followed the approach used for MMC_CAP2_CRYPTO.
We got plenty of bits, let's not waste the time of a programmer trying
to figure out whether his particular combination of configs is going to
collide with the reuse, I'd argue the ifdef is unnecessary
Konrad
next prev parent reply other threads:[~2026-01-08 9:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-18 11:02 [PATCH v3] mmc: Avoid reprogram all keys to Inline Crypto Engine for MMC runtime suspend resume Debraj Mukhopadhyay
2025-07-18 12:05 ` Konrad Dybcio
2025-07-18 12:57 ` Ulf Hansson
2026-01-06 5:44 ` Neeraj Soni
2026-01-06 6:49 ` Neeraj Soni
2026-01-08 9:43 ` Konrad Dybcio [this message]
2026-01-09 6:36 ` Neeraj Soni
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=9a07d235-d1be-447b-ae89-75aa418cb69c@oss.qualcomm.com \
--to=konrad.dybcio@oss.qualcomm.com \
--cc=adrian.hunter@intel.com \
--cc=ebiggers@kernel.org \
--cc=kernel@quicinc.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=neeraj.soni@oss.qualcomm.com \
--cc=quic_bhaskarv@quicinc.com \
--cc=quic_dmukhopa@quicinc.com \
--cc=quic_gaurkash@quicinc.com \
--cc=quic_neersoni@quicinc.com \
--cc=quic_nitirawa@quicinc.com \
--cc=quic_rampraka@quicinc.com \
--cc=quic_sachgupt@quicinc.com \
--cc=quic_sartgarg@quicinc.com \
--cc=ulf.hansson@linaro.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