Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
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

  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