[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFo05Hyw9gdEBx7zQq_6P58ittHHsZQLuqmeR1AChyHSHw@mail.gmail.com>
Date: Fri, 25 Oct 2024 01:07:18 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Seshu Madhavi Puppala <quic_spuppala@...cinc.com>, Eric Biggers <ebiggers@...nel.org>
Cc: 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 0/2] Avoid reprogram all keys to Inline Crypto Engine
for MMC runtime suspend resume
On Wed, 23 Oct 2024 at 23:31, Eric Biggers <ebiggers@...nel.org> wrote:
>
> On Sun, Oct 06, 2024 at 07:25:28PM +0530, Seshu Madhavi Puppala wrote:
> > Crypto reprogram all keys is called for each MMC runtime
> > suspend/resume in current upstream design.
>
> Is that correct? I thought that similar to what is done for UFS, the key
> reprogramming happens only after the MMC controller is reset. I thought that is
> different from a runtime suspend.
Looks like Seshu is not really worried about the host's runtime
suspend, but the card's runtime suspend.
Perhaps there are some out of tree code involved here that makes use
of MMC_CAP_AGGRESSIVE_PM, which is what allows the card to be runtime
suspended?
>
> If it's in fact triggering more often, maybe that is what needs to be fixed?
We could extend the runtime PM autosusend timeout for the card, if
that makes sense.
Kind regards
Uffe
Powered by blists - more mailing lists