All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Gaurav Kashyap <quic_gaurkash@quicinc.com>
Cc: linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-block@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, thara.gopinath@linaro.org,
	asutoshd@codeaurora.org
Subject: Re: [PATCH 1/4] ufs: move ICE functionality to a common library
Date: Thu, 4 Nov 2021 16:05:32 -0700	[thread overview]
Message-ID: <YYRnPN6e2/YMS9Zt@gmail.com> (raw)
In-Reply-To: <20211103231840.115521-2-quic_gaurkash@quicinc.com>

On Wed, Nov 03, 2021 at 04:18:37PM -0700, Gaurav Kashyap wrote:
> The Inline Crypto Engine functionality is not limited to
> ufs and it can be used by other storage controllers like emmc
> which have the HW capabilities. It would be better to move this
> functionality to a common location.

I think you should be a bit more concrete here: both sdhci-msm and ufs-qcom
already have ICE support, and this common library allows code to be shared.

> Moreover, when wrapped key functionality is added, it would
> reduce the effort required to add it for all storage
> controllers.
> 
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  drivers/scsi/ufs/ufs-qcom-ice.c   | 172 ++++--------------------------
>  drivers/soc/qcom/Kconfig          |   7 ++
>  drivers/soc/qcom/Makefile         |   1 +
>  drivers/soc/qcom/qti-ice-common.c | 135 +++++++++++++++++++++++
>  drivers/soc/qcom/qti-ice-regs.h   | 145 +++++++++++++++++++++++++
>  include/linux/qti-ice-common.h    |  26 +++++
>  6 files changed, 334 insertions(+), 152 deletions(-)
>  create mode 100644 drivers/soc/qcom/qti-ice-common.c
>  create mode 100644 drivers/soc/qcom/qti-ice-regs.h
>  create mode 100644 include/linux/qti-ice-common.h

This should be split up into two patches: one that adds the library, and one
that converts ufs-qcom to use it.  There should also be a third patch that
converts sdhci-msm to use it.

> +static void get_ice_mmio_data(struct ice_mmio_data *data,
> +			      const struct ufs_qcom_host *host)
> +{
> +	data->ice_mmio = host->ice_mmio;
> +}

I think the struct ice_mmio_data should just be a field of struct ufs_qcom_host.
Then you wouldn't have to keep initializing a new one.

> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 79b568f82a1c..39f223ed8cdd 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -209,4 +209,11 @@ config QCOM_APR
>  	  application processor and QDSP6. APR is
>  	  used by audio driver to configure QDSP6
>  	  ASM, ADM and AFE modules.
> +
> +config QTI_ICE_COMMON
> +	tristate "QTI common ICE functionality"
> +	depends on SCSI_UFS_CRYPTO && SCSI_UFS_QCOM
> +	help
> +	  Enable the common ICE library that can be used
> +	  by UFS and EMMC drivers for ICE functionality.

"Libraries" should not be user-selectable.  Instead, they should be selected by
the kconfig options that need them.  That also means that the "depends on"
clause should not be here.

So it should look more like:

config QTI_ICE_COMMON
	tristate
	help
	  Enable the common ICE library that can be used
	  by UFS and EMMC drivers for ICE functionality.

If the library itself has dependencies (perhaps ARCH_QCOM?), then add those.

> +
> +int qti_ice_init(const struct ice_mmio_data *mmio)
> +{
> +	return qti_ice_supported(mmio);
> +}
> +EXPORT_SYMBOL(qti_ice_init);

Please use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.

The exported functions could also use kerneldoc comments.

> diff --git a/include/linux/qti-ice-common.h b/include/linux/qti-ice-common.h
> new file mode 100644
> index 000000000000..433422b34a7d
> --- /dev/null
> +++ b/include/linux/qti-ice-common.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef _QTI_ICE_COMMON_H
> +#define _QTI_ICE_COMMON_H
> +
> +#include <linux/types.h>
> +#include <linux/device.h>
> +
> +#define AES_256_XTS_KEY_SIZE    64

Is the definition of AES_256_XTS_KEY_SIZE needed in this header?  It's not
properly "namespaced", so it's sort of the odd thing out in this header.

- Eric

  reply	other threads:[~2021-11-04 23:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 23:18 [PATCH 0/4] Adds wrapped key support for inline storage encryption Gaurav Kashyap
2021-11-03 23:18 ` [PATCH 1/4] ufs: move ICE functionality to a common library Gaurav Kashyap
2021-11-04 23:05   ` Eric Biggers [this message]
2021-11-03 23:18 ` [PATCH 2/4] qcom_scm: scm call for deriving a software secret Gaurav Kashyap
2021-11-04 23:31   ` Eric Biggers
2021-11-03 23:18 ` [PATCH 3/4] soc: qcom: add HWKM library for storage encryption Gaurav Kashyap
2021-11-04 23:46   ` Eric Biggers
2021-11-03 23:18 ` [PATCH 4/4] soc: qcom: add wrapped key support for ICE Gaurav Kashyap
2021-11-05  0:08   ` Eric Biggers
2021-11-04 22:49 ` [PATCH 0/4] Adds wrapped key support for inline storage encryption Eric Biggers
2021-12-08  0:09   ` Gaurav Kashyap
2021-12-08  0:23     ` Eric Biggers
2021-12-08 18:13       ` Gaurav Kashyap

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=YYRnPN6e2/YMS9Zt@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=asutoshd@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=quic_gaurkash@quicinc.com \
    --cc=thara.gopinath@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.