All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: linux-scsi@vger.kernel.org,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	Kuohong Wang <kuohong.wang@mediatek.com>,
	Kim Boojin <boojin.kim@samsung.com>,
	Stanley Chu <stanley.chu@mediatek.com>
Subject: Re: [PATCH v3 3/3] scsi: ufs: Add inline encryption support to UFS
Date: Mon, 6 Jul 2020 12:29:31 -0700	[thread overview]
Message-ID: <20200706192931.GA833@sol.localdomain> (raw)
In-Reply-To: <20200706191016.2012191-4-satyat@google.com>

On Mon, Jul 06, 2020 at 07:10:16PM +0000, Satya Tangirala wrote:
> Wire up ufshcd.c with the UFS Crypto API, the block layer inline
> encryption additions and the keyslot manager.
> 
> Many existing inline crypto devices require some additional behaviour not
> specified in the UFSHCI v2.1 specification - as such the vendor specific
> drivers will need to be updated where necessary to make it possible to use
> those devices. Some of these changes have already been proposed upstream,
> such as for the Qualcomm 845 SoC at
> https://lkml.kernel.org/linux-scsi/20200501045111.665881-1-ebiggers@kernel.org/
> and for ufs-mediatek at
> https://lkml.kernel.org/linux-scsi/20200304022101.14165-1-stanley.chu@mediatek.com/
> 
> This patch has been tested on the db845c, sm8150-mtp and sm8250-mtp
> (which have Qualcomm chipsets) and on some mediatek chipsets using these
> aforementioned vendor specific driver updates.
> 
> Signed-off-by: Satya Tangirala <satyat@google.com>
> Reviewed-by: Eric Biggers <ebiggers@google.com>
> Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
> ---
>  drivers/scsi/ufs/ufshcd-crypto.c | 30 ++++++++++++++------
>  drivers/scsi/ufs/ufshcd-crypto.h | 41 +++++++++++++++++++++++++--
>  drivers/scsi/ufs/ufshcd.c        | 48 +++++++++++++++++++++++++++-----
>  drivers/scsi/ufs/ufshcd.h        |  6 ++++
>  4 files changed, 107 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
> index 65a3115d2a2d..c13cf42652aa 100644
> --- a/drivers/scsi/ufs/ufshcd-crypto.c
> +++ b/drivers/scsi/ufs/ufshcd-crypto.c
> @@ -138,18 +138,17 @@ ufshcd_find_blk_crypto_mode(union ufs_crypto_cap_entry cap)
>  }
>  
>  /**
> - * ufshcd_hba_init_crypto - Read crypto capabilities, init crypto fields in hba
> + * ufshcd_hba_init_crypto_capabilities - Read crypto capabilities, init crypto
> + *					 fields in hba
>   * @hba: Per adapter instance
>   *
>   * Return: 0 if crypto was initialized or is not supported, else a -errno value.
>   */
> -int ufshcd_hba_init_crypto(struct ufs_hba *hba)
> +int ufshcd_hba_init_crypto_capabilities(struct ufs_hba *hba)
>  {
>  	int cap_idx = 0;
>  	int err = 0;
>  	enum blk_crypto_mode_num blk_mode_num;
> -	int slot = 0;
> -	int num_keyslots;
>  
>  	/*
>  	 * Don't use crypto if either the hardware doesn't advertise the
> @@ -173,8 +172,8 @@ int ufshcd_hba_init_crypto(struct ufs_hba *hba)
>  	}
>  
>  	/* The actual number of configurations supported is (CFGC+1) */
> -	num_keyslots = hba->crypto_capabilities.config_count + 1;
> -	err = blk_ksm_init(&hba->ksm, num_keyslots);
> +	err = blk_ksm_init(&hba->ksm,
> +			   hba->crypto_capabilities.config_count + 1);
>  	if (err)
>  		goto out_free_caps;
>  
> @@ -200,9 +199,6 @@ int ufshcd_hba_init_crypto(struct ufs_hba *hba)
>  				hba->crypto_cap_array[cap_idx].sdus_mask * 512;
>  	}
>  
> -	for (slot = 0; slot < num_keyslots; slot++)
> -		ufshcd_clear_keyslot(hba, slot);
> -
>  	return 0;
>  
>  out_free_caps:
> @@ -213,6 +209,22 @@ int ufshcd_hba_init_crypto(struct ufs_hba *hba)
>  	return err;
>  }
>  
> +/**
> + * ufshcd_init_crypto - Initialize crypto hardware
> + * @hba: Per adapter instance
> + */
> +void ufshcd_init_crypto(struct ufs_hba *hba)
> +{
> +	int slot = 0;
> +
> +	if (!(hba->caps & UFSHCD_CAP_CRYPTO))
> +		return;
> +
> +	/* Clear all keyslots - the number of keyslots is (CFGC + 1) */
> +	for (slot = 0; slot < hba->crypto_capabilities.config_count + 1; slot++)
> +		ufshcd_clear_keyslot(hba, slot);
> +}
> +
>  void ufshcd_crypto_setup_rq_keyslot_manager(struct ufs_hba *hba,
>  					    struct request_queue *q)
>  {

Seems that these changes got folded into the wrong patch.
They should go in patch 2.

- Eric

  reply	other threads:[~2020-07-06 19:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06 19:10 [PATCH v3 0/3] Inline Encryption Support for UFS Satya Tangirala
2020-07-06 19:10 ` [PATCH v3 1/3] scsi: ufs: UFS driver v2.1 spec crypto additions Satya Tangirala
2020-07-06 19:10 ` [PATCH v3 2/3] scsi: ufs: UFS crypto API Satya Tangirala
2020-07-06 19:10 ` [PATCH v3 3/3] scsi: ufs: Add inline encryption support to UFS Satya Tangirala
2020-07-06 19:29   ` Eric Biggers [this message]
2020-07-06 19:42   ` 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=20200706192931.GA833@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=bmuthuku@qti.qualcomm.com \
    --cc=boojin.kim@samsung.com \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=satyat@google.com \
    --cc=stanley.chu@mediatek.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 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.