From: Eric Biggers <ebiggers@kernel.org>
To: Barani Muthukumaran <bmuthuku@qti.qualcomm.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Andy Gross <agross@kernel.org>, Avri Altman <avri.altman@wdc.com>,
"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
Can Guo <cang@codeaurora.org>,
Elliot Berman <eberman@codeaurora.org>,
Jaegeuk Kim <jaegeuk@kernel.org>,
John Stultz <john.stultz@linaro.org>,
Satya Tangirala <satyat@google.com>
Subject: Re: [RFC PATCH v3 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
Date: Fri, 13 Mar 2020 10:37:44 -0700 [thread overview]
Message-ID: <20200313173744.GA55327@gmail.com> (raw)
In-Reply-To: <BY5PR02MB6577DA7FD4425C8D7F318E2BFFFA0@BY5PR02MB6577.namprd02.prod.outlook.com>
On Fri, Mar 13, 2020 at 05:05:35PM +0000, Barani Muthukumaran wrote:
> Hi Eric,
>
> The crypto_variant_ops exposed were not a guess, we had worked with Satya to
> add the functionality that is required.
As far as I can tell, my patch works fine with just the new ->program_key()
variant op.
Note that I'm also taking advantage of some of the existing, non-crypto-specific
variant ops. For example, I didn't need to add a ->crypto_resume() operation
because there's already ufs_hba_variant_ops::resume().
I understand that the old downstream ICE code defined and used a lot of crypto
variant ops, which did give the impression that a lot more would be needed. But
ultimately I found that most of them were unnecessary or could be replaced with
the existing non-crypto-specific variant ops.
> Can we define the below crypto_variant_ops that exposes the same functionality
> you have added, this allows us to extend this in the future in a seamless
> manner. As an example QC implementation uses 'debug', 'suspend' and we can add
> that when we upstream the implementation in the next few weeks once our
> validation is complete. Thanks.
>
> struct ufs_hba_crypto_variant_ops {
> int (*hba_init_crypto)(struct ufs_hba *hba,
> const struct keyslot_mgmt_ll_ops *ksm_ops);
> void (*enable)(struct ufs_hba *hba);
> int (*resume)(struct ufs_hba *hba);
> int (*program_key(struct ufs_hba *hba,
> const union ufs_crypto_cfg_entry *cfg, int slot);
> };
To re-iterate, upstream doesn't add hooks with no in-tree users.
It's great to hear that you'll be sending out a patchset soon. Just send out
the hooks you need along with them, so that they can all be properly reviewed.
- Eric
next prev parent reply other threads:[~2020-03-13 17:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 17:12 [RFC PATCH v3 0/4] Inline crypto support on DragonBoard 845c Eric Biggers
2020-03-12 17:12 ` [RFC PATCH v3 1/4] firmware: qcom_scm: Add support for programming inline crypto keys Eric Biggers
2020-03-12 17:12 ` [RFC PATCH v3 2/4] arm64: dts: sdm845: add Inline Crypto Engine registers and clock Eric Biggers
2020-03-12 17:12 ` [RFC PATCH v3 3/4] scsi: ufs: add program_key() variant op Eric Biggers
2020-03-12 17:12 ` [RFC PATCH v3 4/4] scsi: ufs-qcom: add Inline Crypto Engine support Eric Biggers
2020-03-12 18:21 ` Barani Muthukumaran
2020-03-12 19:05 ` Eric Biggers
2020-03-13 17:05 ` Barani Muthukumaran
2020-03-13 17:37 ` Eric Biggers [this message]
2020-03-19 10:33 ` Christoph Hellwig
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=20200313173744.GA55327@gmail.com \
--to=ebiggers@kernel.org \
--cc=agross@kernel.org \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=bjorn.andersson@linaro.org \
--cc=bmuthuku@qti.qualcomm.com \
--cc=cang@codeaurora.org \
--cc=eberman@codeaurora.org \
--cc=jaegeuk@kernel.org \
--cc=john.stultz@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=satyat@google.com \
/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;
as well as URLs for NNTP newsgroup(s).