All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org,
	Satya Tangirala <satyat@google.com>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Asutosh Das <asutoshd@codeaurora.org>,
	Rob Herring <robh+dt@kernel.org>,
	Neeraj Soni <neersoni@codeaurora.org>,
	Barani Muthukumaran <bmuthuku@codeaurora.org>,
	Peng Zhou <peng.zhou@mediatek.com>,
	Stanley Chu <stanley.chu@mediatek.com>,
	Konrad Dybcio <konradybcio@gmail.com>
Subject: Re: [PATCH v4 1/9] mmc: add basic support for inline encryption
Date: Wed, 20 Jan 2021 23:45:51 -0800	[thread overview]
Message-ID: <YAkxLx4JiAtSlx1E@sol.localdomain> (raw)
In-Reply-To: <YAdGbqU12cbJr78K@sol.localdomain>

On Tue, Jan 19, 2021 at 12:52:00PM -0800, Eric Biggers wrote:
> > To free up the data structures, blk_ksm_destroy() is called from
> > mmc_free_host().
> > 
> > To me, this can be made more consistent. For example, it looks like
> > blk_ksm_destroy() could be called, even if blk_ksm_init() hasn't been
> > called (depending on the probe error path of the mmc host).
> 
> blk_ksm_destroy() is a no-op on an all-zeroed struct, so it's fine to call it
> unnecessarily.  We could call it unconditionally, if that would be clearer.
> 
> > There are a couple of options to better deal with this.
> > 1) Extend the blk_ksm interface with a devm_blk_ksm_init() function
> > (thus let it deal with lifecycle problems for us) and simply drop the
> > call to blk_ksm_destroy().
> 
> This would require adding APIs to devm to support zeroing buffers on free and to
> use kvmalloc() instead of kmalloc().  It looks like these new APIs wouldn't be
> useful for many drivers (since almost everyone else just wants regular kmalloc
> with no special behavior on free), so they don't seem worth adding yet.

Actually devres is more flexible than I thought; it's possible to register
custom actions to be executed.  I'll send out a patchset that adds
devm_blk_ksm_init() and converts the UFS driver to use it.

- Eric

  reply	other threads:[~2021-01-21  7:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-04 18:45 [PATCH v4 0/9] eMMC inline encryption support Eric Biggers
2021-01-04 18:45 ` [PATCH v4 1/9] mmc: add basic support for inline encryption Eric Biggers
2021-01-15  9:22   ` Ulf Hansson
2021-01-15 17:56     ` Eric Biggers
2021-01-18 14:21       ` Ulf Hansson
2021-01-19 20:51         ` Eric Biggers
2021-01-21  7:45           ` Eric Biggers [this message]
2021-01-21  9:18           ` Eric Biggers
2021-01-21 13:08             ` Ulf Hansson
2021-01-04 18:45 ` [PATCH v4 2/9] mmc: cqhci: rename cqhci.c to cqhci-core.c Eric Biggers
2021-01-04 18:45 ` [PATCH v4 3/9] mmc: cqhci: initialize upper 64 bits of 128-bit task descriptors Eric Biggers
2021-01-04 18:45 ` [PATCH v4 4/9] mmc: cqhci: add support for inline encryption Eric Biggers
2021-01-04 18:45 ` [PATCH v4 5/9] mmc: cqhci: add cqhci_host_ops::program_key Eric Biggers
2021-01-04 18:45 ` [PATCH v4 6/9] firmware: qcom_scm: update comment for ICE-related functions Eric Biggers
2021-01-04 18:45 ` [PATCH v4 7/9] dt-bindings: mmc: sdhci-msm: add ICE registers and clock Eric Biggers
2021-01-04 18:45 ` [PATCH v4 8/9] arm64: dts: qcom: sdm630: add ICE registers and clocks Eric Biggers
2021-01-04 18:45 ` [PATCH v4 9/9] mmc: sdhci-msm: add Inline Crypto Engine support Eric Biggers

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=YAkxLx4JiAtSlx1E@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=agross@kernel.org \
    --cc=asutoshd@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=bmuthuku@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=neersoni@codeaurora.org \
    --cc=peng.zhou@mediatek.com \
    --cc=robh+dt@kernel.org \
    --cc=satyat@google.com \
    --cc=stanley.chu@mediatek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.