[PATCH v6 0/5] Inline crypto support on DragonBoard 845c

[PATCH v6 0/5] Inline crypto support on DragonBoard 845c

[Eric Biggers]

Hello,

This patchset implements UFS inline encryption support on the
DragonBoard 845c, using the Qualcomm Inline Crypto Engine (ICE)
that's present on the Snapdragon 845 SoC.

This is based on top of scsi/5.9/scsi-queue, which contains the
ufshcd-crypto patches by Satya Tangirala.

Most of the logic needed to use ICE is already handled by the blk-crypto
framework (introduced in v5.8-rc1) and by ufshcd-crypto.  This new
patchset just adds the vendor-specific parts.  I also only implemented
support for version 3 of the ICE hardware, which seems to be easier to
use than older versions.

Due to these factors and others, I was able to greatly simplify the
driver from the vendor's original.  It works fine in testing with
fscrypt and with a blk-crypto self-test I'm also working on.

This driver also works on several other Snapdragon SoCs.
See the commit messages for details.

This patchset is also available in git at:
    Repo: https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
    Tag: db845c-crypto-v6

(To actually test this with fscrypt, it's also needed to merge the
master branch of https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git
to get the fscrypt patches.)

Changed v5 => v6:
    - Rebased onto scsi/5.9/scsi-queue.

Changed v4 => v5:
    - Rebased onto v5.8-rc1 + the latest ufshcd-crypto patchset.
    - Refer to the ICE registers by name rather than by index.
    - Added Tested-by and Acked-by tags.

Changed v3 => v4:
    - Rebased onto the v12 inline encryption patchset.
    - A couple small cleanups.

Changed v2 => v3:
    - Rebased onto the v8 inline encryption patchset.  Now the driver
      has to opt into inline crypto support rather than opting out.
    - Switched qcom_scm_ice_set_key() to use dma_alloc_coherent()
      so that we can reliably zeroing the key without assuming that
      bounce buffers aren't used.  Also added a comment.
    - Made the key_size and data_unit_size arguments to
      qcom_scm_ice_set_key() be 'u32' instead of 'int'.

Changed v1 => v2:
    - Rebased onto the v7 inline encryption patchset.
    - Account for all the recent qcom_scm changes.
    - Don't ignore errors from ->program_key().
    - Don't dereference NULL hba->vops.
    - Dropped the patch that added UFSHCD_QUIRK_BROKEN_CRYPTO, as this
      flag is now included in the main inline encryption patchset.
    - Many other cleanups.

Eric Biggers (5):
  firmware: qcom_scm: Add support for programming inline crypto keys
  scsi: ufs-qcom: name the dev_ref_clk_ctrl registers
  arm64: dts: sdm845: add Inline Crypto Engine registers and clock
  scsi: ufs: add program_key() variant op
  scsi: ufs-qcom: add Inline Crypto Engine support

 MAINTAINERS                          |   2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi |  13 +-
 drivers/firmware/qcom_scm.c          | 101 +++++++++++
 drivers/firmware/qcom_scm.h          |   4 +
 drivers/scsi/ufs/Kconfig             |   1 +
 drivers/scsi/ufs/Makefile            |   4 +-
 drivers/scsi/ufs/ufs-qcom-ice.c      | 245 +++++++++++++++++++++++++++
 drivers/scsi/ufs/ufs-qcom.c          |  15 +-
 drivers/scsi/ufs/ufs-qcom.h          |  27 +++
 drivers/scsi/ufs/ufshcd-crypto.c     |  27 +--
 drivers/scsi/ufs/ufshcd.h            |   3 +
 include/linux/qcom_scm.h             |  19 +++
 12 files changed, 443 insertions(+), 18 deletions(-)
 create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c


base-commit: b53293fa662e28ae0cdd40828dc641c09f133405
-- 
2.27.0

[PATCH v6 1/5] firmware: qcom_scm: Add support for programming inline crypto keys

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Add support for the Inline Crypto Engine (ICE) key programming interface
that's needed for the ufs-qcom driver to use inline encryption on
Snapdragon SoCs.  This interface consists of two SCM calls: one to
program a key into a keyslot, and one to invalidate a keyslot.

Although the UFS specification defines a standard way to do this, on
these SoCs the Linux kernel isn't permitted to access the needed crypto
configuration registers directly; these SCM calls must be used instead.

Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 drivers/firmware/qcom_scm.c | 101 ++++++++++++++++++++++++++++++++++++
 drivers/firmware/qcom_scm.h |   4 ++
 include/linux/qcom_scm.h    |  19 +++++++
 3 files changed, 124 insertions(+)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 0e7233a20f34..1a8eb1b42b1e 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -923,6 +923,107 @@ int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
 }
 EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
 
+/**
+ * qcom_scm_ice_available() - Is the ICE key programming interface available?
+ *
+ * Return: true iff the SCM calls wrapped by qcom_scm_ice_invalidate_key() and
+ *	   qcom_scm_ice_set_key() are available.
+ */
+bool qcom_scm_ice_available(void)
+{
+	return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
+					    QCOM_SCM_ES_INVALIDATE_ICE_KEY) &&
+		__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
+					     QCOM_SCM_ES_CONFIG_SET_ICE_KEY);
+}
+EXPORT_SYMBOL(qcom_scm_ice_available);
+
+/**
+ * qcom_scm_ice_invalidate_key() - Invalidate an inline encryption key
+ * @index: the keyslot to invalidate
+ *
+ * The UFSHCI standard defines a standard way to do this, but it doesn't work on
+ * these SoCs; only this SCM call does.
+ *
+ * Return: 0 on success; -errno on failure.
+ */
+int qcom_scm_ice_invalidate_key(u32 index)
+{
+	struct qcom_scm_desc desc = {
+		.svc = QCOM_SCM_SVC_ES,
+		.cmd = QCOM_SCM_ES_INVALIDATE_ICE_KEY,
+		.arginfo = QCOM_SCM_ARGS(1),
+		.args[0] = index,
+		.owner = ARM_SMCCC_OWNER_SIP,
+	};
+
+	return qcom_scm_call(__scm->dev, &desc, NULL);
+}
+EXPORT_SYMBOL(qcom_scm_ice_invalidate_key);
+
+/**
+ * qcom_scm_ice_set_key() - Set an inline encryption key
+ * @index: the keyslot into which to set the key
+ * @key: the key to program
+ * @key_size: the size of the key in bytes
+ * @cipher: the encryption algorithm the key is for
+ * @data_unit_size: the encryption data unit size, i.e. the size of each
+ *		    individual plaintext and ciphertext.  Given in 512-byte
+ *		    units, e.g. 1 = 512 bytes, 8 = 4096 bytes, etc.
+ *
+ * Program a key into a keyslot of Qualcomm ICE (Inline Crypto Engine), where it
+ * can then be used to encrypt/decrypt UFS I/O requests inline.
+ *
+ * The UFSHCI standard defines a standard way to do this, but it doesn't work on
+ * these SoCs; only this SCM call does.
+ *
+ * Return: 0 on success; -errno on failure.
+ */
+int qcom_scm_ice_set_key(u32 index, const u8 *key, u32 key_size,
+			 enum qcom_scm_ice_cipher cipher, u32 data_unit_size)
+{
+	struct qcom_scm_desc desc = {
+		.svc = QCOM_SCM_SVC_ES,
+		.cmd = QCOM_SCM_ES_CONFIG_SET_ICE_KEY,
+		.arginfo = QCOM_SCM_ARGS(5, QCOM_SCM_VAL, QCOM_SCM_RW,
+					 QCOM_SCM_VAL, QCOM_SCM_VAL,
+					 QCOM_SCM_VAL),
+		.args[0] = index,
+		.args[2] = key_size,
+		.args[3] = cipher,
+		.args[4] = data_unit_size,
+		.owner = ARM_SMCCC_OWNER_SIP,
+	};
+	void *keybuf;
+	dma_addr_t key_phys;
+	int ret;
+
+	/*
+	 * 'key' may point to vmalloc()'ed memory, but we need to pass a
+	 * physical address that's been properly flushed.  The sanctioned way to
+	 * do this is by using the DMA API.  But as is best practice for crypto
+	 * keys, we also must wipe the key after use.  This makes kmemdup() +
+	 * dma_map_single() not clearly correct, since the DMA API can use
+	 * bounce buffers.  Instead, just use dma_alloc_coherent().  Programming
+	 * keys is normally rare and thus not performance-critical.
+	 */
+
+	keybuf = dma_alloc_coherent(__scm->dev, key_size, &key_phys,
+				    GFP_KERNEL);
+	if (!keybuf)
+		return -ENOMEM;
+	memcpy(keybuf, key, key_size);
+	desc.args[1] = key_phys;
+
+	ret = qcom_scm_call(__scm->dev, &desc, NULL);
+
+	memzero_explicit(keybuf, key_size);
+
+	dma_free_coherent(__scm->dev, key_size, keybuf, key_phys);
+	return ret;
+}
+EXPORT_SYMBOL(qcom_scm_ice_set_key);
+
 /**
  * qcom_scm_hdcp_available() - Check if secure environment supports HDCP.
  *
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index d9ed670da222..38ea614d29fe 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -103,6 +103,10 @@ extern int scm_legacy_call(struct device *dev, const struct qcom_scm_desc *desc,
 #define QCOM_SCM_OCMEM_LOCK_CMD		0x01
 #define QCOM_SCM_OCMEM_UNLOCK_CMD	0x02
 
+#define QCOM_SCM_SVC_ES			0x10	/* Enterprise Security */
+#define QCOM_SCM_ES_INVALIDATE_ICE_KEY	0x03
+#define QCOM_SCM_ES_CONFIG_SET_ICE_KEY	0x04
+
 #define QCOM_SCM_SVC_HDCP		0x11
 #define QCOM_SCM_HDCP_INVOKE		0x01
 
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 3d6a24697761..2e1193a3fb5f 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -44,6 +44,13 @@ enum qcom_scm_sec_dev_id {
 	QCOM_SCM_ICE_DEV_ID     = 20,
 };
 
+enum qcom_scm_ice_cipher {
+	QCOM_SCM_ICE_CIPHER_AES_128_XTS = 0,
+	QCOM_SCM_ICE_CIPHER_AES_128_CBC = 1,
+	QCOM_SCM_ICE_CIPHER_AES_256_XTS = 3,
+	QCOM_SCM_ICE_CIPHER_AES_256_CBC = 4,
+};
+
 #define QCOM_SCM_VMID_HLOS       0x3
 #define QCOM_SCM_VMID_MSS_MSA    0xF
 #define QCOM_SCM_VMID_WLAN       0x18
@@ -88,6 +95,12 @@ extern int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset,
 extern int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset,
 				 u32 size);
 
+extern bool qcom_scm_ice_available(void);
+extern int qcom_scm_ice_invalidate_key(u32 index);
+extern int qcom_scm_ice_set_key(u32 index, const u8 *key, u32 key_size,
+				enum qcom_scm_ice_cipher cipher,
+				u32 data_unit_size);
+
 extern bool qcom_scm_hdcp_available(void);
 extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
 			     u32 *resp);
@@ -138,6 +151,12 @@ static inline int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset,
 static inline int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id,
 		u32 offset, u32 size) { return -ENODEV; }
 
+static inline bool qcom_scm_ice_available(void) { return false; }
+static inline int qcom_scm_ice_invalidate_key(u32 index) { return -ENODEV; }
+static inline int qcom_scm_ice_set_key(u32 index, const u8 *key, u32 key_size,
+				       enum qcom_scm_ice_cipher cipher,
+				       u32 data_unit_size) { return -ENODEV; }
+
 static inline bool qcom_scm_hdcp_available(void) { return false; }
 static inline int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
 		u32 *resp) { return -ENODEV; }
-- 
2.27.0

[PATCH v6 2/5] scsi: ufs-qcom: name the dev_ref_clk_ctrl registers

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

In preparation for adding another optional register range to the
ufs-qcom driver, name the existing optional register range
"dev_ref_clk_ctrl_mem".  This allows the driver to refer to the optional
register ranges by name rather than index.

No device-tree files actually have to be updated due to this change,
since none of them actually declares these registers.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 drivers/scsi/ufs/ufs-qcom.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2e6ddb5cdfc2..bd0b4ed7b37a 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1275,7 +1275,8 @@ static int ufs_qcom_init(struct ufs_hba *hba)
 		host->dev_ref_clk_en_mask = BIT(26);
 	} else {
 		/* "dev_ref_clk_ctrl_mem" is optional resource */
-		res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+						   "dev_ref_clk_ctrl_mem");
 		if (res) {
 			host->dev_ref_clk_ctrl_mmio =
 					devm_ioremap_resource(dev, res);
-- 
2.27.0

RE: [PATCH v6 2/5] scsi: ufs-qcom: name the dev_ref_clk_ctrl registers

[Avri Altman]

> 
> 
> From: Eric Biggers <ebiggers@google.com>
> 
> In preparation for adding another optional register range to the
> ufs-qcom driver, name the existing optional register range
> "dev_ref_clk_ctrl_mem".  This allows the driver to refer to the optional
> register ranges by name rather than index.
> 
> No device-tree files actually have to be updated due to this change,
> since none of them actually declares these registers.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>


> ---
>  drivers/scsi/ufs/ufs-qcom.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index 2e6ddb5cdfc2..bd0b4ed7b37a 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -1275,7 +1275,8 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>                 host->dev_ref_clk_en_mask = BIT(26);
>         } else {
>                 /* "dev_ref_clk_ctrl_mem" is optional resource */
> -               res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +               res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +                                                  "dev_ref_clk_ctrl_mem");
>                 if (res) {
>                         host->dev_ref_clk_ctrl_mmio =
>                                         devm_ioremap_resource(dev, res);
> --
> 2.27.0

Re: [PATCH v6 2/5] scsi: ufs-qcom: name the dev_ref_clk_ctrl registers

[Bjorn Andersson]

On Fri 10 Jul 00:20 PDT 2020, Eric Biggers wrote:

> From: Eric Biggers <ebiggers@google.com>
> 
> In preparation for adding another optional register range to the
> ufs-qcom driver, name the existing optional register range
> "dev_ref_clk_ctrl_mem".  This allows the driver to refer to the optional
> register ranges by name rather than index.
> 
> No device-tree files actually have to be updated due to this change,
> since none of them actually declares these registers.
> 

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  drivers/scsi/ufs/ufs-qcom.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index 2e6ddb5cdfc2..bd0b4ed7b37a 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -1275,7 +1275,8 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>  		host->dev_ref_clk_en_mask = BIT(26);
>  	} else {
>  		/* "dev_ref_clk_ctrl_mem" is optional resource */
> -		res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +						   "dev_ref_clk_ctrl_mem");
>  		if (res) {
>  			host->dev_ref_clk_ctrl_mmio =
>  					devm_ioremap_resource(dev, res);
> -- 
> 2.27.0
> 

[PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Add the vendor-specific registers and clock for Qualcomm ICE (Inline
Crypto Engine) to the device tree node for the UFS host controller on
sdm845, so that the ufs-qcom driver will be able to use inline crypto.

Use a separate register range rather than extending the main UFS range
because there's a gap between the two, and the ICE registers are
vendor-specific.  (Actually, the hardware claims that the ICE range also
includes the array of standard crypto configuration registers; however,
on this SoC the Linux kernel isn't permitted to access them directly.)

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 8eb5a31346d2..0affb0041724 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1692,7 +1692,9 @@ mmss_noc: interconnect@1740000 {
 		ufs_mem_hc: ufshc@1d84000 {
 			compatible = "qcom,sdm845-ufshc", "qcom,ufshc",
 				     "jedec,ufs-2.0";
-			reg = <0 0x01d84000 0 0x2500>;
+			reg = <0 0x01d84000 0 0x2500>,
+			      <0 0x01d90000 0 0x8000>;
+			reg-names = "std", "ice";
 			interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
 			phys = <&ufs_mem_phy_lanes>;
 			phy-names = "ufsphy";
@@ -1712,7 +1714,8 @@ ufs_mem_hc: ufshc@1d84000 {
 				"ref_clk",
 				"tx_lane0_sync_clk",
 				"rx_lane0_sync_clk",
-				"rx_lane1_sync_clk";
+				"rx_lane1_sync_clk",
+				"ice_core_clk";
 			clocks =
 				<&gcc GCC_UFS_PHY_AXI_CLK>,
 				<&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
@@ -1721,7 +1724,8 @@ ufs_mem_hc: ufshc@1d84000 {
 				<&rpmhcc RPMH_CXO_CLK>,
 				<&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
 				<&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
-				<&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
+				<&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>,
+				<&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
 			freq-table-hz =
 				<50000000 200000000>,
 				<0 0>,
@@ -1730,7 +1734,8 @@ ufs_mem_hc: ufshc@1d84000 {
 				<0 0>,
 				<0 0>,
 				<0 0>,
-				<0 0>;
+				<0 0>,
+				<0 300000000>;
 
 			status = "disabled";
 		};
-- 
2.27.0

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Martin K. Petersen]

Eric,

> Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> Crypto Engine) to the device tree node for the UFS host controller on
> sdm845, so that the ufs-qcom driver will be able to use inline crypto.

I would like to see an Acked-by for this patch before I merge it.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> 
> Eric,
> 
> > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > Crypto Engine) to the device tree node for the UFS host controller on
> > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> 
> I would like to see an Acked-by for this patch before I merge it.
> 

Andy, Bjorn, or Rob: can you give Acked-by?

- Eric

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Rob Herring]

On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> >
> > Eric,
> >
> > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > Crypto Engine) to the device tree node for the UFS host controller on
> > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> >
> > I would like to see an Acked-by for this patch before I merge it.
> >
>
> Andy, Bjorn, or Rob: can you give Acked-by?

DTS changes should go in via the QCom tree.

Rob

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > >
> > > Eric,
> > >
> > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > >
> > > I would like to see an Acked-by for this patch before I merge it.
> > >
> >
> > Andy, Bjorn, or Rob: can you give Acked-by?
> 
> DTS changes should go in via the QCom tree.
> 

So, the DTS patch can't be applied without the driver patches since then the
driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.

But the driver patches can be applied without the DTS patch.

Martin: how about you take patches 1-2 and 4-5 through the scsi tree for 5.9,
and then we get the DTS patch taken through the QCOM tree for 5.10?

- Eric

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Martin K. Petersen]

Eric,

> Martin: how about you take patches 1-2 and 4-5 through the scsi tree
> for 5.9, and then we get the DTS patch taken through the QCOM tree for
> 5.10?

Sure!

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Rob Herring]

On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > >
> > > > Eric,
> > > >
> > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > >
> > > > I would like to see an Acked-by for this patch before I merge it.
> > > >
> > >
> > > Andy, Bjorn, or Rob: can you give Acked-by?
> >
> > DTS changes should go in via the QCom tree.
> >
>
> So, the DTS patch can't be applied without the driver patches since then the
> driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.

That sounds broken, but there's no context here for me to comment
further. DTS changes should work with old/stable kernels. I'd suggest
you get a review from Bjorn on the driver first.

Rob

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > >
> > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > >
> > > > > Eric,
> > > > >
> > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > >
> > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > >
> > > >
> > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > >
> > > DTS changes should go in via the QCom tree.
> > >
> >
> > So, the DTS patch can't be applied without the driver patches since then the
> > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> 
> That sounds broken, but there's no context here for me to comment
> further. DTS changes should work with old/stable kernels. I'd suggest
> you get a review from Bjorn on the driver first.
> 

The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
by name instead of assumed to be index 1.

A reviewer had complained about the device-mapper bindings of this driver before
(https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
Changing to identifying the registers by name seemed like an improvement.

If needed I can add a hole at index 1 to make the DTS changes work with
old/stable kernels too, but I didn't know that is a requirement.  (Normally for
Linux kernel development, kernel-internal refactoring is always allowed
upstream.)  If I do this, would this hack have to be carried forever, or would
we be able to fix it up eventually?  Is there any deprecation period for DTS, or
do the latest DTS have to work with a 20 year old kernel?

- Eric

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Bjorn Andersson]

On Tue 14 Jul 10:12 PDT 2020, Eric Biggers wrote:

> On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > >
> > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > > >
> > > > > > Eric,
> > > > > >
> > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > > >
> > > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > > >
> > > > >
> > > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > > >
> > > > DTS changes should go in via the QCom tree.
> > > >
> > >
> > > So, the DTS patch can't be applied without the driver patches since then the
> > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> > 
> > That sounds broken, but there's no context here for me to comment
> > further. DTS changes should work with old/stable kernels. I'd suggest
> > you get a review from Bjorn on the driver first.
> > 
> 
> The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
> by name instead of assumed to be index 1.
> 
> A reviewer had complained about the device-mapper bindings of this driver before
> (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
> Changing to identifying the registers by name seemed like an improvement.
> 
> If needed I can add a hole at index 1 to make the DTS changes work with
> old/stable kernels too, but I didn't know that is a requirement.  (Normally for
> Linux kernel development, kernel-internal refactoring is always allowed
> upstream.)  If I do this, would this hack have to be carried forever, or would
> we be able to fix it up eventually?  Is there any deprecation period for DTS, or
> do the latest DTS have to work with a 20 year old kernel?
> 

The problem here is that DT binding refactoring is not kernel-internal.
It's two different projects living in the same git.

There's a wish from various people that we make sure that new DTS
continues to work with existing kernels. This is a nice in theory
there's a lot of examples where we simply couldn't anticipate how future
bindings would look. A particular example is that this prohibits most
advancement in power management.


But afaict what you describe above would make a new kernel failing to
operate with the old DTS and that we have agreed to avoid.
So I think the appropriate way to deal with this is to request the reg
byname to detect the new binding and if that fails then assume that
index 1 is dev_ref_clk_ctrl.


There are cases where we just decide not to be backwards compatible, but
it's pretty rare. As for deprecation, I think 1-2 LTS releases is
sufficient, at that time scale it doesn't make sense to sit with an old
DTB anyways (given the current pace of advancements in the kernel).

Regards,
Bjorn

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Bjorn Andersson]

On Tue 14 Jul 10:31 PDT 2020, Bjorn Andersson wrote:

> On Tue 14 Jul 10:12 PDT 2020, Eric Biggers wrote:
> 
> > On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> > > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > >
> > > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > >
> > > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > > > >
> > > > > > > Eric,
> > > > > > >
> > > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > > > >
> > > > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > > > >
> > > > > >
> > > > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > > > >
> > > > > DTS changes should go in via the QCom tree.
> > > > >
> > > >
> > > > So, the DTS patch can't be applied without the driver patches since then the
> > > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> > > 
> > > That sounds broken, but there's no context here for me to comment
> > > further. DTS changes should work with old/stable kernels. I'd suggest
> > > you get a review from Bjorn on the driver first.
> > > 
> > 
> > The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
> > by name instead of assumed to be index 1.
> > 
> > A reviewer had complained about the device-mapper bindings of this driver before
> > (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
> > Changing to identifying the registers by name seemed like an improvement.
> > 
> > If needed I can add a hole at index 1 to make the DTS changes work with
> > old/stable kernels too, but I didn't know that is a requirement.  (Normally for
> > Linux kernel development, kernel-internal refactoring is always allowed
> > upstream.)  If I do this, would this hack have to be carried forever, or would
> > we be able to fix it up eventually?  Is there any deprecation period for DTS, or
> > do the latest DTS have to work with a 20 year old kernel?
> > 
> 
> The problem here is that DT binding refactoring is not kernel-internal.
> It's two different projects living in the same git.
> 
> There's a wish from various people that we make sure that new DTS
> continues to work with existing kernels. This is a nice in theory
> there's a lot of examples where we simply couldn't anticipate how future
> bindings would look. A particular example is that this prohibits most
> advancement in power management.
> 
> 
> But afaict what you describe above would make a new kernel failing to
> operate with the old DTS and that we have agreed to avoid.
> So I think the appropriate way to deal with this is to request the reg
> byname to detect the new binding and if that fails then assume that
> index 1 is dev_ref_clk_ctrl.
> 

I took another look at the git history and I can't find a single dts -
either upstream or in any downstream tree - that specifies that second
reg.

So per my argument below, if you could include a patch that just removes
the "dev_ref_clk_ctrl_mem" reference from the binding and driver I would
be happy to r-b that and ack this patch.

Regards,
Bjorn

> 
> There are cases where we just decide not to be backwards compatible, but
> it's pretty rare. As for deprecation, I think 1-2 LTS releases is
> sufficient, at that time scale it doesn't make sense to sit with an old
> DTB anyways (given the current pace of advancements in the kernel).
> 
> Regards,
> Bjorn

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

On Tue, Jul 14, 2020 at 10:43:45AM -0700, Bjorn Andersson wrote:
> On Tue 14 Jul 10:31 PDT 2020, Bjorn Andersson wrote:
> 
> > On Tue 14 Jul 10:12 PDT 2020, Eric Biggers wrote:
> > 
> > > On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> > > > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > >
> > > > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > >
> > > > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > > > > >
> > > > > > > > Eric,
> > > > > > > >
> > > > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > > > > >
> > > > > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > > > > >
> > > > > > >
> > > > > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > > > > >
> > > > > > DTS changes should go in via the QCom tree.
> > > > > >
> > > > >
> > > > > So, the DTS patch can't be applied without the driver patches since then the
> > > > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> > > > 
> > > > That sounds broken, but there's no context here for me to comment
> > > > further. DTS changes should work with old/stable kernels. I'd suggest
> > > > you get a review from Bjorn on the driver first.
> > > > 
> > > 
> > > The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
> > > by name instead of assumed to be index 1.
> > > 
> > > A reviewer had complained about the device-mapper bindings of this driver before
> > > (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
> > > Changing to identifying the registers by name seemed like an improvement.
> > > 
> > > If needed I can add a hole at index 1 to make the DTS changes work with
> > > old/stable kernels too, but I didn't know that is a requirement.  (Normally for
> > > Linux kernel development, kernel-internal refactoring is always allowed
> > > upstream.)  If I do this, would this hack have to be carried forever, or would
> > > we be able to fix it up eventually?  Is there any deprecation period for DTS, or
> > > do the latest DTS have to work with a 20 year old kernel?
> > > 
> > 
> > The problem here is that DT binding refactoring is not kernel-internal.
> > It's two different projects living in the same git.
> > 
> > There's a wish from various people that we make sure that new DTS
> > continues to work with existing kernels. This is a nice in theory
> > there's a lot of examples where we simply couldn't anticipate how future
> > bindings would look. A particular example is that this prohibits most
> > advancement in power management.
> > 
> > 
> > But afaict what you describe above would make a new kernel failing to
> > operate with the old DTS and that we have agreed to avoid.
> > So I think the appropriate way to deal with this is to request the reg
> > byname to detect the new binding and if that fails then assume that
> > index 1 is dev_ref_clk_ctrl.
> > 
> 
> I took another look at the git history and I can't find a single dts -
> either upstream or in any downstream tree - that specifies that second
> reg.
> 
> So per my argument below, if you could include a patch that just removes
> the "dev_ref_clk_ctrl_mem" reference from the binding and driver I would
> be happy to r-b that and ack this patch.
> 
> Regards,
> Bjorn
> 
> > 
> > There are cases where we just decide not to be backwards compatible, but
> > it's pretty rare. As for deprecation, I think 1-2 LTS releases is
> > sufficient, at that time scale it doesn't make sense to sit with an old
> > DTB anyways (given the current pace of advancements in the kernel).
> > 

Great, I'll remove the driver support for "dev_ref_clk_ctrl" then.  However,
that doesn't solve the problem of the new DTS breaking old drivers, since old
drivers assume that reg[1] is dev_ref_clk_ctrl.

This patch makes the DTS look like:

	reg = <0 0x01d84000 0 0x2500>,
	      <0 0x01d90000 0 0x8000>;
	reg-names = "std", "ice";

The "ice" registers are new and are accessed by name instead of by index.

But these also happen to be in reg[1].  Old drivers will see that reg[1] is
present and assume it is dev_ref_clk_ctrl.

To work around this, I could leave a blank reg[1] entry:

	reg = <0 0x01d84000 0 0x2500>,
	      <0 0 0 0>,
	      <0 0x01d90000 0 0x8000>;
	reg-names = "std", "dev_ref_clk_ctrl", "ice";

Do I need to do that?

- Eric

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Bjorn Andersson]

On Tue 14 Jul 10:57 PDT 2020, Eric Biggers wrote:

> On Tue, Jul 14, 2020 at 10:43:45AM -0700, Bjorn Andersson wrote:
> > On Tue 14 Jul 10:31 PDT 2020, Bjorn Andersson wrote:
> > 
> > > On Tue 14 Jul 10:12 PDT 2020, Eric Biggers wrote:
> > > 
> > > > On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> > > > > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > >
> > > > > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > > > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > > >
> > > > > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > > > > > >
> > > > > > > > > Eric,
> > > > > > > > >
> > > > > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > > > > > >
> > > > > > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > > > > > >
> > > > > > > DTS changes should go in via the QCom tree.
> > > > > > >
> > > > > >
> > > > > > So, the DTS patch can't be applied without the driver patches since then the
> > > > > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> > > > > 
> > > > > That sounds broken, but there's no context here for me to comment
> > > > > further. DTS changes should work with old/stable kernels. I'd suggest
> > > > > you get a review from Bjorn on the driver first.
> > > > > 
> > > > 
> > > > The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
> > > > by name instead of assumed to be index 1.
> > > > 
> > > > A reviewer had complained about the device-mapper bindings of this driver before
> > > > (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
> > > > Changing to identifying the registers by name seemed like an improvement.
> > > > 
> > > > If needed I can add a hole at index 1 to make the DTS changes work with
> > > > old/stable kernels too, but I didn't know that is a requirement.  (Normally for
> > > > Linux kernel development, kernel-internal refactoring is always allowed
> > > > upstream.)  If I do this, would this hack have to be carried forever, or would
> > > > we be able to fix it up eventually?  Is there any deprecation period for DTS, or
> > > > do the latest DTS have to work with a 20 year old kernel?
> > > > 
> > > 
> > > The problem here is that DT binding refactoring is not kernel-internal.
> > > It's two different projects living in the same git.
> > > 
> > > There's a wish from various people that we make sure that new DTS
> > > continues to work with existing kernels. This is a nice in theory
> > > there's a lot of examples where we simply couldn't anticipate how future
> > > bindings would look. A particular example is that this prohibits most
> > > advancement in power management.
> > > 
> > > 
> > > But afaict what you describe above would make a new kernel failing to
> > > operate with the old DTS and that we have agreed to avoid.
> > > So I think the appropriate way to deal with this is to request the reg
> > > byname to detect the new binding and if that fails then assume that
> > > index 1 is dev_ref_clk_ctrl.
> > > 
> > 
> > I took another look at the git history and I can't find a single dts -
> > either upstream or in any downstream tree - that specifies that second
> > reg.
> > 
> > So per my argument below, if you could include a patch that just removes
> > the "dev_ref_clk_ctrl_mem" reference from the binding and driver I would
> > be happy to r-b that and ack this patch.
> > 
> > Regards,
> > Bjorn
> > 
> > > 
> > > There are cases where we just decide not to be backwards compatible, but
> > > it's pretty rare. As for deprecation, I think 1-2 LTS releases is
> > > sufficient, at that time scale it doesn't make sense to sit with an old
> > > DTB anyways (given the current pace of advancements in the kernel).
> > > 
> 
> Great, I'll remove the driver support for "dev_ref_clk_ctrl" then.  However,
> that doesn't solve the problem of the new DTS breaking old drivers, since old
> drivers assume that reg[1] is dev_ref_clk_ctrl.
> 
> This patch makes the DTS look like:
> 
> 	reg = <0 0x01d84000 0 0x2500>,
> 	      <0 0x01d90000 0 0x8000>;
> 	reg-names = "std", "ice";
> 
> The "ice" registers are new and are accessed by name instead of by index.
> 
> But these also happen to be in reg[1].  Old drivers will see that reg[1] is
> present and assume it is dev_ref_clk_ctrl.
> 
> To work around this, I could leave a blank reg[1] entry:
> 
> 	reg = <0 0x01d84000 0 0x2500>,
> 	      <0 0 0 0>,
> 	      <0 0x01d90000 0 0x8000>;
> 	reg-names = "std", "dev_ref_clk_ctrl", "ice";
> 
> Do I need to do that?
> 

No, let's not complicate it without good reason. SDM845 has hw_ver.major
== 3, so we're not taking the else-path in ufs_qcom_init(). So I should
be able to just merge this patch for 5.9 through the qcom tree after
all (your code handles that it's not there and the existing code doesn't
care).


The two platforms that I can find that has UFS controller of
hw_ver.major == 1 is APQ8084 and MSM8994, so I simply didn't look at an
old enough downstream tree (msm-3.10) to find anyone specifying reg[1].
The reg specified is however coming from the TLMM (pinctrl-msm) hardware
block, so it should not be directly remapped in the UFS driver...

But regardless, that has not been seen in an upstream dts and per your
patch 2 we would add that reg by name when that happens.
There's recent activity on upstreaming more of the MSM8994 support, so
perhaps then it's best to leave this snippet in the driver for now.


Summary: Martin merges (merged?) patch 1, 2, 4 and 5 in the scsi tree,
I'll merge this patch as is in the qcom tree and we'll just leave the
dev_ref_clk handling as is for now then.

Regards,
Bjorn

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

On Tue, Jul 14, 2020 at 01:00:27PM -0700, Bjorn Andersson wrote:
> On Tue 14 Jul 10:57 PDT 2020, Eric Biggers wrote:
> 
> > On Tue, Jul 14, 2020 at 10:43:45AM -0700, Bjorn Andersson wrote:
> > > On Tue 14 Jul 10:31 PDT 2020, Bjorn Andersson wrote:
> > > 
> > > > On Tue 14 Jul 10:12 PDT 2020, Eric Biggers wrote:
> > > > 
> > > > > On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> > > > > > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > >
> > > > > > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > > > > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > > > > > > >
> > > > > > > > > > Eric,
> > > > > > > > > >
> > > > > > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > > > > > > >
> > > > > > > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > > > > > > >
> > > > > > > > DTS changes should go in via the QCom tree.
> > > > > > > >
> > > > > > >
> > > > > > > So, the DTS patch can't be applied without the driver patches since then the
> > > > > > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> > > > > > 
> > > > > > That sounds broken, but there's no context here for me to comment
> > > > > > further. DTS changes should work with old/stable kernels. I'd suggest
> > > > > > you get a review from Bjorn on the driver first.
> > > > > > 
> > > > > 
> > > > > The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
> > > > > by name instead of assumed to be index 1.
> > > > > 
> > > > > A reviewer had complained about the device-mapper bindings of this driver before
> > > > > (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
> > > > > Changing to identifying the registers by name seemed like an improvement.
> > > > > 
> > > > > If needed I can add a hole at index 1 to make the DTS changes work with
> > > > > old/stable kernels too, but I didn't know that is a requirement.  (Normally for
> > > > > Linux kernel development, kernel-internal refactoring is always allowed
> > > > > upstream.)  If I do this, would this hack have to be carried forever, or would
> > > > > we be able to fix it up eventually?  Is there any deprecation period for DTS, or
> > > > > do the latest DTS have to work with a 20 year old kernel?
> > > > > 
> > > > 
> > > > The problem here is that DT binding refactoring is not kernel-internal.
> > > > It's two different projects living in the same git.
> > > > 
> > > > There's a wish from various people that we make sure that new DTS
> > > > continues to work with existing kernels. This is a nice in theory
> > > > there's a lot of examples where we simply couldn't anticipate how future
> > > > bindings would look. A particular example is that this prohibits most
> > > > advancement in power management.
> > > > 
> > > > 
> > > > But afaict what you describe above would make a new kernel failing to
> > > > operate with the old DTS and that we have agreed to avoid.
> > > > So I think the appropriate way to deal with this is to request the reg
> > > > byname to detect the new binding and if that fails then assume that
> > > > index 1 is dev_ref_clk_ctrl.
> > > > 
> > > 
> > > I took another look at the git history and I can't find a single dts -
> > > either upstream or in any downstream tree - that specifies that second
> > > reg.
> > > 
> > > So per my argument below, if you could include a patch that just removes
> > > the "dev_ref_clk_ctrl_mem" reference from the binding and driver I would
> > > be happy to r-b that and ack this patch.
> > > 
> > > Regards,
> > > Bjorn
> > > 
> > > > 
> > > > There are cases where we just decide not to be backwards compatible, but
> > > > it's pretty rare. As for deprecation, I think 1-2 LTS releases is
> > > > sufficient, at that time scale it doesn't make sense to sit with an old
> > > > DTB anyways (given the current pace of advancements in the kernel).
> > > > 
> > 
> > Great, I'll remove the driver support for "dev_ref_clk_ctrl" then.  However,
> > that doesn't solve the problem of the new DTS breaking old drivers, since old
> > drivers assume that reg[1] is dev_ref_clk_ctrl.
> > 
> > This patch makes the DTS look like:
> > 
> > 	reg = <0 0x01d84000 0 0x2500>,
> > 	      <0 0x01d90000 0 0x8000>;
> > 	reg-names = "std", "ice";
> > 
> > The "ice" registers are new and are accessed by name instead of by index.
> > 
> > But these also happen to be in reg[1].  Old drivers will see that reg[1] is
> > present and assume it is dev_ref_clk_ctrl.
> > 
> > To work around this, I could leave a blank reg[1] entry:
> > 
> > 	reg = <0 0x01d84000 0 0x2500>,
> > 	      <0 0 0 0>,
> > 	      <0 0x01d90000 0 0x8000>;
> > 	reg-names = "std", "dev_ref_clk_ctrl", "ice";
> > 
> > Do I need to do that?
> > 
> 
> No, let's not complicate it without good reason. SDM845 has hw_ver.major
> == 3, so we're not taking the else-path in ufs_qcom_init(). So I should
> be able to just merge this patch for 5.9 through the qcom tree after
> all (your code handles that it's not there and the existing code doesn't
> care).
> 
> 
> The two platforms that I can find that has UFS controller of
> hw_ver.major == 1 is APQ8084 and MSM8994, so I simply didn't look at an
> old enough downstream tree (msm-3.10) to find anyone specifying reg[1].
> The reg specified is however coming from the TLMM (pinctrl-msm) hardware
> block, so it should not be directly remapped in the UFS driver...
> 
> But regardless, that has not been seen in an upstream dts and per your
> patch 2 we would add that reg by name when that happens.
> There's recent activity on upstreaming more of the MSM8994 support, so
> perhaps then it's best to leave this snippet in the driver for now.
> 
> 
> Summary: Martin merges (merged?) patch 1, 2, 4 and 5 in the scsi tree,
> I'll merge this patch as is in the qcom tree and we'll just leave the
> dev_ref_clk handling as is for now then.
> 

Okay, great.  So an old DTS with the new driver isn't a problem because no DTS
has ever declared dev_ref_clk_ctrl.  And a new DTS with an old driver is a less
important case, and also not really a problem here since breakage would only
occur if we added the ICE registers to an older SoC that has hw_ver.major == 1.

Maybe you'd like to provide your Acked-by on patches 2 and 5?

My instinct is always to remove code that has never been used.  But sure, if you
think the dev_ref_clk_ctrl code might be used soon, we can keep it for now.

- Eric

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

On Tue, Jul 14, 2020 at 08:00:04PM -0700, Eric Biggers wrote:
> On Tue, Jul 14, 2020 at 01:00:27PM -0700, Bjorn Andersson wrote:
> > On Tue 14 Jul 10:57 PDT 2020, Eric Biggers wrote:
> > 
> > > On Tue, Jul 14, 2020 at 10:43:45AM -0700, Bjorn Andersson wrote:
> > > > On Tue 14 Jul 10:31 PDT 2020, Bjorn Andersson wrote:
> > > > 
> > > > > On Tue 14 Jul 10:12 PDT 2020, Eric Biggers wrote:
> > > > > 
> > > > > > On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> > > > > > > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > > >
> > > > > > > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > > > > > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > > > > > > > >
> > > > > > > > > > > Eric,
> > > > > > > > > > >
> > > > > > > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > > > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > > > > > > > >
> > > > > > > > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > > > > > > > >
> > > > > > > > > DTS changes should go in via the QCom tree.
> > > > > > > > >
> > > > > > > >
> > > > > > > > So, the DTS patch can't be applied without the driver patches since then the
> > > > > > > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> > > > > > > 
> > > > > > > That sounds broken, but there's no context here for me to comment
> > > > > > > further. DTS changes should work with old/stable kernels. I'd suggest
> > > > > > > you get a review from Bjorn on the driver first.
> > > > > > > 
> > > > > > 
> > > > > > The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
> > > > > > by name instead of assumed to be index 1.
> > > > > > 
> > > > > > A reviewer had complained about the device-mapper bindings of this driver before
> > > > > > (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
> > > > > > Changing to identifying the registers by name seemed like an improvement.
> > > > > > 
> > > > > > If needed I can add a hole at index 1 to make the DTS changes work with
> > > > > > old/stable kernels too, but I didn't know that is a requirement.  (Normally for
> > > > > > Linux kernel development, kernel-internal refactoring is always allowed
> > > > > > upstream.)  If I do this, would this hack have to be carried forever, or would
> > > > > > we be able to fix it up eventually?  Is there any deprecation period for DTS, or
> > > > > > do the latest DTS have to work with a 20 year old kernel?
> > > > > > 
> > > > > 
> > > > > The problem here is that DT binding refactoring is not kernel-internal.
> > > > > It's two different projects living in the same git.
> > > > > 
> > > > > There's a wish from various people that we make sure that new DTS
> > > > > continues to work with existing kernels. This is a nice in theory
> > > > > there's a lot of examples where we simply couldn't anticipate how future
> > > > > bindings would look. A particular example is that this prohibits most
> > > > > advancement in power management.
> > > > > 
> > > > > 
> > > > > But afaict what you describe above would make a new kernel failing to
> > > > > operate with the old DTS and that we have agreed to avoid.
> > > > > So I think the appropriate way to deal with this is to request the reg
> > > > > byname to detect the new binding and if that fails then assume that
> > > > > index 1 is dev_ref_clk_ctrl.
> > > > > 
> > > > 
> > > > I took another look at the git history and I can't find a single dts -
> > > > either upstream or in any downstream tree - that specifies that second
> > > > reg.
> > > > 
> > > > So per my argument below, if you could include a patch that just removes
> > > > the "dev_ref_clk_ctrl_mem" reference from the binding and driver I would
> > > > be happy to r-b that and ack this patch.
> > > > 
> > > > Regards,
> > > > Bjorn
> > > > 
> > > > > 
> > > > > There are cases where we just decide not to be backwards compatible, but
> > > > > it's pretty rare. As for deprecation, I think 1-2 LTS releases is
> > > > > sufficient, at that time scale it doesn't make sense to sit with an old
> > > > > DTB anyways (given the current pace of advancements in the kernel).
> > > > > 
> > > 
> > > Great, I'll remove the driver support for "dev_ref_clk_ctrl" then.  However,
> > > that doesn't solve the problem of the new DTS breaking old drivers, since old
> > > drivers assume that reg[1] is dev_ref_clk_ctrl.
> > > 
> > > This patch makes the DTS look like:
> > > 
> > > 	reg = <0 0x01d84000 0 0x2500>,
> > > 	      <0 0x01d90000 0 0x8000>;
> > > 	reg-names = "std", "ice";
> > > 
> > > The "ice" registers are new and are accessed by name instead of by index.
> > > 
> > > But these also happen to be in reg[1].  Old drivers will see that reg[1] is
> > > present and assume it is dev_ref_clk_ctrl.
> > > 
> > > To work around this, I could leave a blank reg[1] entry:
> > > 
> > > 	reg = <0 0x01d84000 0 0x2500>,
> > > 	      <0 0 0 0>,
> > > 	      <0 0x01d90000 0 0x8000>;
> > > 	reg-names = "std", "dev_ref_clk_ctrl", "ice";
> > > 
> > > Do I need to do that?
> > > 
> > 
> > No, let's not complicate it without good reason. SDM845 has hw_ver.major
> > == 3, so we're not taking the else-path in ufs_qcom_init(). So I should
> > be able to just merge this patch for 5.9 through the qcom tree after
> > all (your code handles that it's not there and the existing code doesn't
> > care).
> > 
> > 
> > The two platforms that I can find that has UFS controller of
> > hw_ver.major == 1 is APQ8084 and MSM8994, so I simply didn't look at an
> > old enough downstream tree (msm-3.10) to find anyone specifying reg[1].
> > The reg specified is however coming from the TLMM (pinctrl-msm) hardware
> > block, so it should not be directly remapped in the UFS driver...
> > 
> > But regardless, that has not been seen in an upstream dts and per your
> > patch 2 we would add that reg by name when that happens.
> > There's recent activity on upstreaming more of the MSM8994 support, so
> > perhaps then it's best to leave this snippet in the driver for now.
> > 
> > 
> > Summary: Martin merges (merged?) patch 1, 2, 4 and 5 in the scsi tree,
> > I'll merge this patch as is in the qcom tree and we'll just leave the
> > dev_ref_clk handling as is for now then.
> > 
> 
> Okay, great.  So an old DTS with the new driver isn't a problem because no DTS
> has ever declared dev_ref_clk_ctrl.  And a new DTS with an old driver is a less
> important case, and also not really a problem here since breakage would only
> occur if we added the ICE registers to an older SoC that has hw_ver.major == 1.
> 
> Maybe you'd like to provide your Acked-by on patches 2 and 5?
> 
> My instinct is always to remove code that has never been used.  But sure, if you
> think the dev_ref_clk_ctrl code might be used soon, we can keep it for now.
> 

Ping?

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

On Mon, Jul 20, 2020 at 10:07:13AM -0700, Eric Biggers wrote:
> > > No, let's not complicate it without good reason. SDM845 has hw_ver.major
> > > == 3, so we're not taking the else-path in ufs_qcom_init(). So I should
> > > be able to just merge this patch for 5.9 through the qcom tree after
> > > all (your code handles that it's not there and the existing code doesn't
> > > care).
> > > 
> > > 
> > > The two platforms that I can find that has UFS controller of
> > > hw_ver.major == 1 is APQ8084 and MSM8994, so I simply didn't look at an
> > > old enough downstream tree (msm-3.10) to find anyone specifying reg[1].
> > > The reg specified is however coming from the TLMM (pinctrl-msm) hardware
> > > block, so it should not be directly remapped in the UFS driver...
> > > 
> > > But regardless, that has not been seen in an upstream dts and per your
> > > patch 2 we would add that reg by name when that happens.
> > > There's recent activity on upstreaming more of the MSM8994 support, so
> > > perhaps then it's best to leave this snippet in the driver for now.
> > > 
> > > 
> > > Summary: Martin merges (merged?) patch 1, 2, 4 and 5 in the scsi tree,
> > > I'll merge this patch as is in the qcom tree and we'll just leave the
> > > dev_ref_clk handling as is for now then.
> > > 
> > 
> > Okay, great.  So an old DTS with the new driver isn't a problem because no DTS
> > has ever declared dev_ref_clk_ctrl.  And a new DTS with an old driver is a less
> > important case, and also not really a problem here since breakage would only
> > occur if we added the ICE registers to an older SoC that has hw_ver.major == 1.
> > 
> > Maybe you'd like to provide your Acked-by on patches 2 and 5?
> > 
> > My instinct is always to remove code that has never been used.  But sure, if you
> > think the dev_ref_clk_ctrl code might be used soon, we can keep it for now.
> > 

Martin,

As per the above discussion, Bjorn has included this device tree patch
in his pull request for 5.9:
https://lore.kernel.org/linux-arm-msm/20200721044934.3430084-1-bjorn.andersson@linaro.org/

Could you apply patches 1-2 and 4-5 to the scsi tree now?

Thanks!

- Eric

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Bjorn Andersson]

On Mon 20 Jul 10:07 PDT 2020, Eric Biggers wrote:

> On Tue, Jul 14, 2020 at 08:00:04PM -0700, Eric Biggers wrote:
> > On Tue, Jul 14, 2020 at 01:00:27PM -0700, Bjorn Andersson wrote:
> > > On Tue 14 Jul 10:57 PDT 2020, Eric Biggers wrote:
> > > 
> > > > On Tue, Jul 14, 2020 at 10:43:45AM -0700, Bjorn Andersson wrote:
> > > > > On Tue 14 Jul 10:31 PDT 2020, Bjorn Andersson wrote:
> > > > > 
> > > > > > On Tue 14 Jul 10:12 PDT 2020, Eric Biggers wrote:
> > > > > > 
> > > > > > > On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> > > > > > > > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > > > > > > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Eric,
> > > > > > > > > > > >
> > > > > > > > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > > > > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > > > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > > > > > > > > >
> > > > > > > > > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > > > > > > > > >
> > > > > > > > > > DTS changes should go in via the QCom tree.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > So, the DTS patch can't be applied without the driver patches since then the
> > > > > > > > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> > > > > > > > 
> > > > > > > > That sounds broken, but there's no context here for me to comment
> > > > > > > > further. DTS changes should work with old/stable kernels. I'd suggest
> > > > > > > > you get a review from Bjorn on the driver first.
> > > > > > > > 
> > > > > > > 
> > > > > > > The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
> > > > > > > by name instead of assumed to be index 1.
> > > > > > > 
> > > > > > > A reviewer had complained about the device-mapper bindings of this driver before
> > > > > > > (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
> > > > > > > Changing to identifying the registers by name seemed like an improvement.
> > > > > > > 
> > > > > > > If needed I can add a hole at index 1 to make the DTS changes work with
> > > > > > > old/stable kernels too, but I didn't know that is a requirement.  (Normally for
> > > > > > > Linux kernel development, kernel-internal refactoring is always allowed
> > > > > > > upstream.)  If I do this, would this hack have to be carried forever, or would
> > > > > > > we be able to fix it up eventually?  Is there any deprecation period for DTS, or
> > > > > > > do the latest DTS have to work with a 20 year old kernel?
> > > > > > > 
> > > > > > 
> > > > > > The problem here is that DT binding refactoring is not kernel-internal.
> > > > > > It's two different projects living in the same git.
> > > > > > 
> > > > > > There's a wish from various people that we make sure that new DTS
> > > > > > continues to work with existing kernels. This is a nice in theory
> > > > > > there's a lot of examples where we simply couldn't anticipate how future
> > > > > > bindings would look. A particular example is that this prohibits most
> > > > > > advancement in power management.
> > > > > > 
> > > > > > 
> > > > > > But afaict what you describe above would make a new kernel failing to
> > > > > > operate with the old DTS and that we have agreed to avoid.
> > > > > > So I think the appropriate way to deal with this is to request the reg
> > > > > > byname to detect the new binding and if that fails then assume that
> > > > > > index 1 is dev_ref_clk_ctrl.
> > > > > > 
> > > > > 
> > > > > I took another look at the git history and I can't find a single dts -
> > > > > either upstream or in any downstream tree - that specifies that second
> > > > > reg.
> > > > > 
> > > > > So per my argument below, if you could include a patch that just removes
> > > > > the "dev_ref_clk_ctrl_mem" reference from the binding and driver I would
> > > > > be happy to r-b that and ack this patch.
> > > > > 
> > > > > Regards,
> > > > > Bjorn
> > > > > 
> > > > > > 
> > > > > > There are cases where we just decide not to be backwards compatible, but
> > > > > > it's pretty rare. As for deprecation, I think 1-2 LTS releases is
> > > > > > sufficient, at that time scale it doesn't make sense to sit with an old
> > > > > > DTB anyways (given the current pace of advancements in the kernel).
> > > > > > 
> > > > 
> > > > Great, I'll remove the driver support for "dev_ref_clk_ctrl" then.  However,
> > > > that doesn't solve the problem of the new DTS breaking old drivers, since old
> > > > drivers assume that reg[1] is dev_ref_clk_ctrl.
> > > > 
> > > > This patch makes the DTS look like:
> > > > 
> > > > 	reg = <0 0x01d84000 0 0x2500>,
> > > > 	      <0 0x01d90000 0 0x8000>;
> > > > 	reg-names = "std", "ice";
> > > > 
> > > > The "ice" registers are new and are accessed by name instead of by index.
> > > > 
> > > > But these also happen to be in reg[1].  Old drivers will see that reg[1] is
> > > > present and assume it is dev_ref_clk_ctrl.
> > > > 
> > > > To work around this, I could leave a blank reg[1] entry:
> > > > 
> > > > 	reg = <0 0x01d84000 0 0x2500>,
> > > > 	      <0 0 0 0>,
> > > > 	      <0 0x01d90000 0 0x8000>;
> > > > 	reg-names = "std", "dev_ref_clk_ctrl", "ice";
> > > > 
> > > > Do I need to do that?
> > > > 
> > > 
> > > No, let's not complicate it without good reason. SDM845 has hw_ver.major
> > > == 3, so we're not taking the else-path in ufs_qcom_init(). So I should
> > > be able to just merge this patch for 5.9 through the qcom tree after
> > > all (your code handles that it's not there and the existing code doesn't
> > > care).
> > > 
> > > 
> > > The two platforms that I can find that has UFS controller of
> > > hw_ver.major == 1 is APQ8084 and MSM8994, so I simply didn't look at an
> > > old enough downstream tree (msm-3.10) to find anyone specifying reg[1].
> > > The reg specified is however coming from the TLMM (pinctrl-msm) hardware
> > > block, so it should not be directly remapped in the UFS driver...
> > > 
> > > But regardless, that has not been seen in an upstream dts and per your
> > > patch 2 we would add that reg by name when that happens.
> > > There's recent activity on upstreaming more of the MSM8994 support, so
> > > perhaps then it's best to leave this snippet in the driver for now.
> > > 
> > > 
> > > Summary: Martin merges (merged?) patch 1, 2, 4 and 5 in the scsi tree,
> > > I'll merge this patch as is in the qcom tree and we'll just leave the
> > > dev_ref_clk handling as is for now then.
> > > 
> > 
> > Okay, great.  So an old DTS with the new driver isn't a problem because no DTS
> > has ever declared dev_ref_clk_ctrl.  And a new DTS with an old driver is a less
> > important case, and also not really a problem here since breakage would only
> > occur if we added the ICE registers to an older SoC that has hw_ver.major == 1.
> > 
> > Maybe you'd like to provide your Acked-by on patches 2 and 5?
> > 
> > My instinct is always to remove code that has never been used.  But sure, if you
> > think the dev_ref_clk_ctrl code might be used soon, we can keep it for now.
> > 
> 
> Ping?

Sorry, I thought Martin already did pick up the SCSI patches. I've acked
the two patches now.

Let's see what happens on MSM8994 to see if we should alter or remove
the external ref_clk handling.

Regards,
Bjorn

Re: [PATCH v6 3/5] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Rob Herring]

On Tue, Jul 14, 2020 at 11:12 AM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote:
> > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote:
> > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > >
> > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote:
> > > > > >
> > > > > > Eric,
> > > > > >
> > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline
> > > > > > > Crypto Engine) to the device tree node for the UFS host controller on
> > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto.
> > > > > >
> > > > > > I would like to see an Acked-by for this patch before I merge it.
> > > > > >
> > > > >
> > > > > Andy, Bjorn, or Rob: can you give Acked-by?
> > > >
> > > > DTS changes should go in via the QCom tree.
> > > >
> > >
> > > So, the DTS patch can't be applied without the driver patches since then the
> > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers.
> >
> > That sounds broken, but there's no context here for me to comment
> > further. DTS changes should work with old/stable kernels. I'd suggest
> > you get a review from Bjorn on the driver first.
> >
>
> The "breaking" change is that the dev_ref_clk_ctrl registers are now identified
> by name instead of assumed to be index 1.
>
> A reviewer had complained about the device-mapper bindings of this driver before
> (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@swboyd.mtv.corp.google.com).
> Changing to identifying the registers by name seemed like an improvement.
>
> If needed I can add a hole at index 1 to make the DTS changes work with
> old/stable kernels too, but I didn't know that is a requirement.  (Normally for
> Linux kernel development, kernel-internal refactoring is always allowed
> upstream.)

dtb <-> kernel is an ABI and not an internal interface. The dts files
are hosted in the kernel for convenience as that's where the vast
majority of h/w support is. The DT parts are also generated as a
standalone repo[1] using git-filter-branch for other projects to use.

>  If I do this, would this hack have to be carried forever, or would
> we be able to fix it up eventually?  Is there any deprecation period for DTS, or
> do the latest DTS have to work with a 20 year old kernel?

With the above being said, it's up to the individual platform
maintainers to decide whether breaking the ABI is okay or how long to
worry about compatibility. My only requirement is documenting that a
change does break compatibility. Given this is probably an optional
driver, they may not care.

BTW, we have broken (and fixed) 1998 era PowerMac G3s not too long
ago. That's the opposite direction with old DT (firmware really) and
new kernel.

Rob

[1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

[PATCH v6 4/5] scsi: ufs: add program_key() variant op

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

On Snapdragon SoCs, the Linux kernel isn't permitted to directly access
the standard UFS crypto configuration registers.  Instead, programming
and evicting keys must be done through vendor-specific SMC calls.

To support this hardware, add a ->program_key() method to
'struct ufs_hba_variant_ops'.  This allows overriding the UFS standard
key programming / eviction procedure.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 drivers/scsi/ufs/ufshcd-crypto.c | 27 +++++++++++++++++----------
 drivers/scsi/ufs/ufshcd.h        |  3 +++
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
index 98ff87c38aa7..d2edbd960ebf 100644
--- a/drivers/scsi/ufs/ufshcd-crypto.c
+++ b/drivers/scsi/ufs/ufshcd-crypto.c
@@ -17,14 +17,20 @@ static const struct ufs_crypto_alg_entry {
 	},
 };
 
-static void ufshcd_program_key(struct ufs_hba *hba,
-			       const union ufs_crypto_cfg_entry *cfg,
-			       int slot)
+static int ufshcd_program_key(struct ufs_hba *hba,
+			      const union ufs_crypto_cfg_entry *cfg, int slot)
 {
 	int i;
 	u32 slot_offset = hba->crypto_cfg_register + slot * sizeof(*cfg);
+	int err = 0;
 
 	ufshcd_hold(hba, false);
+
+	if (hba->vops && hba->vops->program_key) {
+		err = hba->vops->program_key(hba, cfg, slot);
+		goto out;
+	}
+
 	/* Ensure that CFGE is cleared before programming the key */
 	ufshcd_writel(hba, 0, slot_offset + 16 * sizeof(cfg->reg_val[0]));
 	for (i = 0; i < 16; i++) {
@@ -37,7 +43,9 @@ static void ufshcd_program_key(struct ufs_hba *hba,
 	/* Dword 16 must be written last */
 	ufshcd_writel(hba, le32_to_cpu(cfg->reg_val[16]),
 		      slot_offset + 16 * sizeof(cfg->reg_val[0]));
+out:
 	ufshcd_release(hba);
+	return err;
 }
 
 static int ufshcd_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
@@ -52,6 +60,7 @@ static int ufshcd_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
 	int i;
 	int cap_idx = -1;
 	union ufs_crypto_cfg_entry cfg = { 0 };
+	int err;
 
 	BUILD_BUG_ON(UFS_CRYPTO_KEY_SIZE_INVALID != 0);
 	for (i = 0; i < hba->crypto_capabilities.num_crypto_cap; i++) {
@@ -79,13 +88,13 @@ static int ufshcd_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
 		memcpy(cfg.crypto_key, key->raw, key->size);
 	}
 
-	ufshcd_program_key(hba, &cfg, slot);
+	err = ufshcd_program_key(hba, &cfg, slot);
 
 	memzero_explicit(&cfg, sizeof(cfg));
-	return 0;
+	return err;
 }
 
-static void ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
+static int ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
 {
 	/*
 	 * Clear the crypto cfg on the device. Clearing CFGE
@@ -93,7 +102,7 @@ static void ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
 	 */
 	union ufs_crypto_cfg_entry cfg = { 0 };
 
-	ufshcd_program_key(hba, &cfg, slot);
+	return ufshcd_program_key(hba, &cfg, slot);
 }
 
 static int ufshcd_crypto_keyslot_evict(struct blk_keyslot_manager *ksm,
@@ -102,9 +111,7 @@ static int ufshcd_crypto_keyslot_evict(struct blk_keyslot_manager *ksm,
 {
 	struct ufs_hba *hba = container_of(ksm, struct ufs_hba, ksm);
 
-	ufshcd_clear_keyslot(hba, slot);
-
-	return 0;
+	return ufshcd_clear_keyslot(hba, slot);
 }
 
 bool ufshcd_crypto_enable(struct ufs_hba *hba)
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 656c0691c858..b2ef18f1b746 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -281,6 +281,7 @@ struct ufs_pwr_mode_info {
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
  * @device_reset: called to issue a reset pulse on the UFS device
+ * @program_key: program or evict an inline encryption key
  */
 struct ufs_hba_variant_ops {
 	const char *name;
@@ -314,6 +315,8 @@ struct ufs_hba_variant_ops {
 	void	(*config_scaling_param)(struct ufs_hba *hba,
 					struct devfreq_dev_profile *profile,
 					void *data);
+	int	(*program_key)(struct ufs_hba *hba,
+			       const union ufs_crypto_cfg_entry *cfg, int slot);
 };
 
 /* clock gating state  */
-- 
2.27.0

RE: [PATCH v6 4/5] scsi: ufs: add program_key() variant op

[Avri Altman]

 
> 
> From: Eric Biggers <ebiggers@google.com>
> 
> On Snapdragon SoCs, the Linux kernel isn't permitted to directly access
> the standard UFS crypto configuration registers.  Instead, programming
> and evicting keys must be done through vendor-specific SMC calls.
> 
> To support this hardware, add a ->program_key() method to
> 'struct ufs_hba_variant_ops'.  This allows overriding the UFS standard
> key programming / eviction procedure.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>


> ---
>  drivers/scsi/ufs/ufshcd-crypto.c | 27 +++++++++++++++++----------
>  drivers/scsi/ufs/ufshcd.h        |  3 +++
>  2 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
> index 98ff87c38aa7..d2edbd960ebf 100644
> --- a/drivers/scsi/ufs/ufshcd-crypto.c
> +++ b/drivers/scsi/ufs/ufshcd-crypto.c
> @@ -17,14 +17,20 @@ static const struct ufs_crypto_alg_entry {
>         },
>  };
> 
> -static void ufshcd_program_key(struct ufs_hba *hba,
> -                              const union ufs_crypto_cfg_entry *cfg,
> -                              int slot)
> +static int ufshcd_program_key(struct ufs_hba *hba,
> +                             const union ufs_crypto_cfg_entry *cfg, int slot)
>  {
>         int i;
>         u32 slot_offset = hba->crypto_cfg_register + slot * sizeof(*cfg);
> +       int err = 0;
> 
>         ufshcd_hold(hba, false);
> +
> +       if (hba->vops && hba->vops->program_key) {
> +               err = hba->vops->program_key(hba, cfg, slot);
> +               goto out;
> +       }
> +
>         /* Ensure that CFGE is cleared before programming the key */
>         ufshcd_writel(hba, 0, slot_offset + 16 * sizeof(cfg->reg_val[0]));
>         for (i = 0; i < 16; i++) {
> @@ -37,7 +43,9 @@ static void ufshcd_program_key(struct ufs_hba *hba,
>         /* Dword 16 must be written last */
>         ufshcd_writel(hba, le32_to_cpu(cfg->reg_val[16]),
>                       slot_offset + 16 * sizeof(cfg->reg_val[0]));
> +out:
>         ufshcd_release(hba);
> +       return err;
>  }
> 
>  static int ufshcd_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
> @@ -52,6 +60,7 @@ static int ufshcd_crypto_keyslot_program(struct
> blk_keyslot_manager *ksm,
>         int i;
>         int cap_idx = -1;
>         union ufs_crypto_cfg_entry cfg = { 0 };
> +       int err;
> 
>         BUILD_BUG_ON(UFS_CRYPTO_KEY_SIZE_INVALID != 0);
>         for (i = 0; i < hba->crypto_capabilities.num_crypto_cap; i++) {
> @@ -79,13 +88,13 @@ static int ufshcd_crypto_keyslot_program(struct
> blk_keyslot_manager *ksm,
>                 memcpy(cfg.crypto_key, key->raw, key->size);
>         }
> 
> -       ufshcd_program_key(hba, &cfg, slot);
> +       err = ufshcd_program_key(hba, &cfg, slot);
> 
>         memzero_explicit(&cfg, sizeof(cfg));
> -       return 0;
> +       return err;
>  }
> 
> -static void ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
> +static int ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
>  {
>         /*
>          * Clear the crypto cfg on the device. Clearing CFGE
> @@ -93,7 +102,7 @@ static void ufshcd_clear_keyslot(struct ufs_hba *hba,
> int slot)
>          */
>         union ufs_crypto_cfg_entry cfg = { 0 };
> 
> -       ufshcd_program_key(hba, &cfg, slot);
> +       return ufshcd_program_key(hba, &cfg, slot);
>  }
> 
>  static int ufshcd_crypto_keyslot_evict(struct blk_keyslot_manager *ksm,
> @@ -102,9 +111,7 @@ static int ufshcd_crypto_keyslot_evict(struct
> blk_keyslot_manager *ksm,
>  {
>         struct ufs_hba *hba = container_of(ksm, struct ufs_hba, ksm);
> 
> -       ufshcd_clear_keyslot(hba, slot);
> -
> -       return 0;
> +       return ufshcd_clear_keyslot(hba, slot);
>  }
> 
>  bool ufshcd_crypto_enable(struct ufs_hba *hba)
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 656c0691c858..b2ef18f1b746 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -281,6 +281,7 @@ struct ufs_pwr_mode_info {
>   * @dbg_register_dump: used to dump controller debug information
>   * @phy_initialization: used to initialize phys
>   * @device_reset: called to issue a reset pulse on the UFS device
> + * @program_key: program or evict an inline encryption key
>   */
>  struct ufs_hba_variant_ops {
>         const char *name;
> @@ -314,6 +315,8 @@ struct ufs_hba_variant_ops {
>         void    (*config_scaling_param)(struct ufs_hba *hba,
>                                         struct devfreq_dev_profile *profile,
>                                         void *data);
> +       int     (*program_key)(struct ufs_hba *hba,
> +                              const union ufs_crypto_cfg_entry *cfg, int slot);
>  };
> 
>  /* clock gating state  */
> --
> 2.27.0

[PATCH v6 5/5] scsi: ufs-qcom: add Inline Crypto Engine support

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Add support for Qualcomm Inline Crypto Engine (ICE) to ufs-qcom.

The standards-compliant parts, such as querying the crypto capabilities
and enabling crypto for individual UFS requests, are already handled by
ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
However, ICE requires vendor-specific init, enable, and resume logic,
and it requires that keys be programmed and evicted by vendor-specific
SMC calls.  Make the ufs-qcom driver handle these details.

I tested this on Dragonboard 845c, which is a publicly available
development board that uses the Snapdragon 845 SoC and runs the upstream
Linux kernel.  This is the same SoC used in the Pixel 3 and Pixel 3 XL
phones.  This testing included (among other things) verifying that the
expected ciphertext was produced, both manually using ext4 encryption
and automatically using a block layer self-test I've written.

I've also tested that this driver works nearly as-is on the Snapdragon
765 and Snapdragon 865 SoCs.  And others have tested it on Snapdragon
850, Snapdragon 855, and Snapdragon 865 (see the Tested-by tags).

This is based very loosely on the vendor-provided driver in the kernel
source code for the Pixel 3, but I've greatly simplified it.  Also, for
now I've only included support for major version 3 of ICE, since that's
all I have the hardware to test with the mainline kernel.  Plus it
appears that version 3 is easier to use than older versions of ICE.

For now, only allow using AES-256-XTS.  The hardware also declares
support for AES-128-XTS, AES-{128,256}-ECB, and AES-{128,256}-CBC
(BitLocker variant).  But none of these others are really useful, and
they'd need to be individually tested to be sure they worked properly.

This commit also changes the name of the loadable module from "ufs-qcom"
to "ufs_qcom", as this is necessary to compile it from multiple source
files (unless we were to rename ufs-qcom.c).

Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Tested-by: Thara Gopinath <thara.gopinath@linaro.org> # db845c, sm8150-mtp, sm8250-mtp
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 MAINTAINERS                     |   2 +-
 drivers/scsi/ufs/Kconfig        |   1 +
 drivers/scsi/ufs/Makefile       |   4 +-
 drivers/scsi/ufs/ufs-qcom-ice.c | 245 ++++++++++++++++++++++++++++++++
 drivers/scsi/ufs/ufs-qcom.c     |  12 +-
 drivers/scsi/ufs/ufs-qcom.h     |  27 ++++
 6 files changed, 288 insertions(+), 3 deletions(-)
 create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 68f21d46614c..aa9c924facc6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2271,7 +2271,7 @@ F:	drivers/pci/controller/dwc/pcie-qcom.c
 F:	drivers/phy/qualcomm/
 F:	drivers/power/*/msm*
 F:	drivers/reset/reset-qcom-*
-F:	drivers/scsi/ufs/ufs-qcom.*
+F:	drivers/scsi/ufs/ufs-qcom*
 F:	drivers/spi/spi-geni-qcom.c
 F:	drivers/spi/spi-qcom-qspi.c
 F:	drivers/spi/spi-qup.c
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 46a4542f37eb..f6394999b98c 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -99,6 +99,7 @@ config SCSI_UFS_DWC_TC_PLATFORM
 config SCSI_UFS_QCOM
 	tristate "QCOM specific hooks to UFS controller platform driver"
 	depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
+	select QCOM_SCM
 	select RESET_CONTROLLER
 	help
 	  This selects the QCOM specific additions to UFSHCD platform driver.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 9810963bc049..4679af1b564e 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -3,7 +3,9 @@
 obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o tc-dwc-g210.o
 obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o tc-dwc-g210.o
 obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
-obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
+obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
+ufs_qcom-y += ufs-qcom.o
+ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
 obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
 ufshcd-core-y				+= ufshcd.o ufs-sysfs.o
diff --git a/drivers/scsi/ufs/ufs-qcom-ice.c b/drivers/scsi/ufs/ufs-qcom-ice.c
new file mode 100644
index 000000000000..bbb0ad7590ec
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-qcom-ice.c
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm ICE (Inline Crypto Engine) support.
+ *
+ * Copyright (c) 2014-2019, The Linux Foundation. All rights reserved.
+ * Copyright 2019 Google LLC
+ */
+
+#include <linux/platform_device.h>
+#include <linux/qcom_scm.h>
+
+#include "ufshcd-crypto.h"
+#include "ufs-qcom.h"
+
+#define AES_256_XTS_KEY_SIZE			64
+
+/* QCOM ICE registers */
+
+#define QCOM_ICE_REG_CONTROL			0x0000
+#define QCOM_ICE_REG_RESET			0x0004
+#define QCOM_ICE_REG_VERSION			0x0008
+#define QCOM_ICE_REG_FUSE_SETTING		0x0010
+#define QCOM_ICE_REG_PARAMETERS_1		0x0014
+#define QCOM_ICE_REG_PARAMETERS_2		0x0018
+#define QCOM_ICE_REG_PARAMETERS_3		0x001C
+#define QCOM_ICE_REG_PARAMETERS_4		0x0020
+#define QCOM_ICE_REG_PARAMETERS_5		0x0024
+
+/* QCOM ICE v3.X only */
+#define QCOM_ICE_GENERAL_ERR_STTS		0x0040
+#define QCOM_ICE_INVALID_CCFG_ERR_STTS		0x0030
+#define QCOM_ICE_GENERAL_ERR_MASK		0x0044
+
+/* QCOM ICE v2.X only */
+#define QCOM_ICE_REG_NON_SEC_IRQ_STTS		0x0040
+#define QCOM_ICE_REG_NON_SEC_IRQ_MASK		0x0044
+
+#define QCOM_ICE_REG_NON_SEC_IRQ_CLR		0x0048
+#define QCOM_ICE_REG_STREAM1_ERROR_SYNDROME1	0x0050
+#define QCOM_ICE_REG_STREAM1_ERROR_SYNDROME2	0x0054
+#define QCOM_ICE_REG_STREAM2_ERROR_SYNDROME1	0x0058
+#define QCOM_ICE_REG_STREAM2_ERROR_SYNDROME2	0x005C
+#define QCOM_ICE_REG_STREAM1_BIST_ERROR_VEC	0x0060
+#define QCOM_ICE_REG_STREAM2_BIST_ERROR_VEC	0x0064
+#define QCOM_ICE_REG_STREAM1_BIST_FINISH_VEC	0x0068
+#define QCOM_ICE_REG_STREAM2_BIST_FINISH_VEC	0x006C
+#define QCOM_ICE_REG_BIST_STATUS		0x0070
+#define QCOM_ICE_REG_BYPASS_STATUS		0x0074
+#define QCOM_ICE_REG_ADVANCED_CONTROL		0x1000
+#define QCOM_ICE_REG_ENDIAN_SWAP		0x1004
+#define QCOM_ICE_REG_TEST_BUS_CONTROL		0x1010
+#define QCOM_ICE_REG_TEST_BUS_REG		0x1014
+
+/* BIST ("built-in self-test"?) status flags */
+#define QCOM_ICE_BIST_STATUS_MASK		0xF0000000
+
+#define QCOM_ICE_FUSE_SETTING_MASK		0x1
+#define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK	0x2
+#define QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK	0x4
+
+#define qcom_ice_writel(host, val, reg)	\
+	writel((val), (host)->ice_mmio + (reg))
+#define qcom_ice_readl(host, reg)	\
+	readl((host)->ice_mmio + (reg))
+
+static bool qcom_ice_supported(struct ufs_qcom_host *host)
+{
+	struct device *dev = host->hba->dev;
+	u32 regval = qcom_ice_readl(host, QCOM_ICE_REG_VERSION);
+	int major = regval >> 24;
+	int minor = (regval >> 16) & 0xFF;
+	int step = regval & 0xFFFF;
+
+	/* For now this driver only supports ICE version 3. */
+	if (major != 3) {
+		dev_warn(dev, "Unsupported ICE version: v%d.%d.%d\n",
+			 major, minor, step);
+		return false;
+	}
+
+	dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
+		 major, minor, step);
+
+	/* If fuses are blown, ICE might not work in the standard way. */
+	regval = qcom_ice_readl(host, QCOM_ICE_REG_FUSE_SETTING);
+	if (regval & (QCOM_ICE_FUSE_SETTING_MASK |
+		      QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK |
+		      QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK)) {
+		dev_warn(dev, "Fuses are blown; ICE is unusable!\n");
+		return false;
+	}
+	return true;
+}
+
+int ufs_qcom_ice_init(struct ufs_qcom_host *host)
+{
+	struct ufs_hba *hba = host->hba;
+	struct device *dev = hba->dev;
+	struct platform_device *pdev = to_platform_device(dev);
+	struct resource *res;
+	int err;
+
+	if (!(ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES) &
+	      MASK_CRYPTO_SUPPORT))
+		return 0;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ice");
+	if (!res) {
+		dev_warn(dev, "ICE registers not found\n");
+		goto disable;
+	}
+
+	if (!qcom_scm_ice_available()) {
+		dev_warn(dev, "ICE SCM interface not found\n");
+		goto disable;
+	}
+
+	host->ice_mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(host->ice_mmio)) {
+		err = PTR_ERR(host->ice_mmio);
+		dev_err(dev, "Failed to map ICE registers; err=%d\n", err);
+		return err;
+	}
+
+	if (!qcom_ice_supported(host))
+		goto disable;
+
+	return 0;
+
+disable:
+	dev_warn(dev, "Disabling inline encryption support\n");
+	hba->caps &= ~UFSHCD_CAP_CRYPTO;
+	return 0;
+}
+
+static void qcom_ice_low_power_mode_enable(struct ufs_qcom_host *host)
+{
+	u32 regval;
+
+	regval = qcom_ice_readl(host, QCOM_ICE_REG_ADVANCED_CONTROL);
+	/*
+	 * Enable low power mode sequence
+	 * [0]-0, [1]-0, [2]-0, [3]-E, [4]-0, [5]-0, [6]-0, [7]-0
+	 */
+	regval |= 0x7000;
+	qcom_ice_writel(host, regval, QCOM_ICE_REG_ADVANCED_CONTROL);
+}
+
+static void qcom_ice_optimization_enable(struct ufs_qcom_host *host)
+{
+	u32 regval;
+
+	/* ICE Optimizations Enable Sequence */
+	regval = qcom_ice_readl(host, QCOM_ICE_REG_ADVANCED_CONTROL);
+	regval |= 0xD807100;
+	/* ICE HPG requires delay before writing */
+	udelay(5);
+	qcom_ice_writel(host, regval, QCOM_ICE_REG_ADVANCED_CONTROL);
+	udelay(5);
+}
+
+int ufs_qcom_ice_enable(struct ufs_qcom_host *host)
+{
+	if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
+		return 0;
+	qcom_ice_low_power_mode_enable(host);
+	qcom_ice_optimization_enable(host);
+	return ufs_qcom_ice_resume(host);
+}
+
+/* Poll until all BIST bits are reset */
+static int qcom_ice_wait_bist_status(struct ufs_qcom_host *host)
+{
+	int count;
+	u32 reg;
+
+	for (count = 0; count < 100; count++) {
+		reg = qcom_ice_readl(host, QCOM_ICE_REG_BIST_STATUS);
+		if (!(reg & QCOM_ICE_BIST_STATUS_MASK))
+			break;
+		udelay(50);
+	}
+	if (reg)
+		return -ETIMEDOUT;
+	return 0;
+}
+
+int ufs_qcom_ice_resume(struct ufs_qcom_host *host)
+{
+	int err;
+
+	if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
+		return 0;
+
+	err = qcom_ice_wait_bist_status(host);
+	if (err) {
+		dev_err(host->hba->dev, "BIST status error (%d)\n", err);
+		return err;
+	}
+	return 0;
+}
+
+/*
+ * Program a key into a QC ICE keyslot, or evict a keyslot.  QC ICE requires
+ * vendor-specific SCM calls for this; it doesn't support the standard way.
+ */
+int ufs_qcom_ice_program_key(struct ufs_hba *hba,
+			     const union ufs_crypto_cfg_entry *cfg, int slot)
+{
+	union ufs_crypto_cap_entry cap;
+	union {
+		u8 bytes[AES_256_XTS_KEY_SIZE];
+		u32 words[AES_256_XTS_KEY_SIZE / sizeof(u32)];
+	} key;
+	int i;
+	int err;
+
+	if (!(cfg->config_enable & UFS_CRYPTO_CONFIGURATION_ENABLE))
+		return qcom_scm_ice_invalidate_key(slot);
+
+	/* Only AES-256-XTS has been tested so far. */
+	cap = hba->crypto_cap_array[cfg->crypto_cap_idx];
+	if (cap.algorithm_id != UFS_CRYPTO_ALG_AES_XTS ||
+	    cap.key_size != UFS_CRYPTO_KEY_SIZE_256) {
+		dev_err_ratelimited(hba->dev,
+				    "Unhandled crypto capability; algorithm_id=%d, key_size=%d\n",
+				    cap.algorithm_id, cap.key_size);
+		return -EINVAL;
+	}
+
+	memcpy(key.bytes, cfg->crypto_key, AES_256_XTS_KEY_SIZE);
+
+	/*
+	 * The SCM call byte-swaps the 32-bit words of the key.  So we have to
+	 * do the same, in order for the final key be correct.
+	 */
+	for (i = 0; i < ARRAY_SIZE(key.words); i++)
+		__cpu_to_be32s(&key.words[i]);
+
+	err = qcom_scm_ice_set_key(slot, key.bytes, AES_256_XTS_KEY_SIZE,
+				   QCOM_SCM_ICE_CIPHER_AES_256_XTS,
+				   cfg->data_unit_size);
+	memzero_explicit(&key, sizeof(key));
+	return err;
+}
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index bd0b4ed7b37a..139c3ae05e95 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -365,7 +365,7 @@ static int ufs_qcom_hce_enable_notify(struct ufs_hba *hba,
 		/* check if UFS PHY moved from DISABLED to HIBERN8 */
 		err = ufs_qcom_check_hibern8(hba);
 		ufs_qcom_enable_hw_clk_gating(hba);
-
+		ufs_qcom_ice_enable(host);
 		break;
 	default:
 		dev_err(hba->dev, "%s: invalid status %d\n", __func__, status);
@@ -613,6 +613,10 @@ static int ufs_qcom_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			return err;
 	}
 
+	err = ufs_qcom_ice_resume(host);
+	if (err)
+		return err;
+
 	hba->is_sys_suspended = false;
 	return 0;
 }
@@ -1071,6 +1075,7 @@ static void ufs_qcom_set_caps(struct ufs_hba *hba)
 	hba->caps |= UFSHCD_CAP_CLK_SCALING;
 	hba->caps |= UFSHCD_CAP_AUTO_BKOPS_SUSPEND;
 	hba->caps |= UFSHCD_CAP_WB_EN;
+	hba->caps |= UFSHCD_CAP_CRYPTO;
 
 	if (host->hw_ver.major >= 0x2) {
 		host->caps = UFS_QCOM_CAP_QUNIPRO |
@@ -1298,6 +1303,10 @@ static int ufs_qcom_init(struct ufs_hba *hba)
 	ufs_qcom_set_caps(hba);
 	ufs_qcom_advertise_quirks(hba);
 
+	err = ufs_qcom_ice_init(host);
+	if (err)
+		goto out_variant_clear;
+
 	ufs_qcom_set_bus_vote(hba, true);
 	ufs_qcom_setup_clocks(hba, true, POST_CHANGE);
 
@@ -1736,6 +1745,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops = {
 	.dbg_register_dump	= ufs_qcom_dump_dbg_regs,
 	.device_reset		= ufs_qcom_device_reset,
 	.config_scaling_param = ufs_qcom_config_scaling_param,
+	.program_key		= ufs_qcom_ice_program_key,
 };
 
 /**
diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
index 2d95e7cc7187..97247d17e258 100644
--- a/drivers/scsi/ufs/ufs-qcom.h
+++ b/drivers/scsi/ufs/ufs-qcom.h
@@ -227,6 +227,9 @@ struct ufs_qcom_host {
 	void __iomem *dev_ref_clk_ctrl_mmio;
 	bool is_dev_ref_clk_enabled;
 	struct ufs_hw_version hw_ver;
+#ifdef CONFIG_SCSI_UFS_CRYPTO
+	void __iomem *ice_mmio;
+#endif
 
 	u32 dev_ref_clk_en_mask;
 
@@ -264,4 +267,28 @@ static inline bool ufs_qcom_cap_qunipro(struct ufs_qcom_host *host)
 		return false;
 }
 
+/* ufs-qcom-ice.c */
+
+#ifdef CONFIG_SCSI_UFS_CRYPTO
+int ufs_qcom_ice_init(struct ufs_qcom_host *host);
+int ufs_qcom_ice_enable(struct ufs_qcom_host *host);
+int ufs_qcom_ice_resume(struct ufs_qcom_host *host);
+int ufs_qcom_ice_program_key(struct ufs_hba *hba,
+			     const union ufs_crypto_cfg_entry *cfg, int slot);
+#else
+static inline int ufs_qcom_ice_init(struct ufs_qcom_host *host)
+{
+	return 0;
+}
+static inline int ufs_qcom_ice_enable(struct ufs_qcom_host *host)
+{
+	return 0;
+}
+static inline int ufs_qcom_ice_resume(struct ufs_qcom_host *host)
+{
+	return 0;
+}
+#define ufs_qcom_ice_program_key NULL
+#endif /* !CONFIG_SCSI_UFS_CRYPTO */
+
 #endif /* UFS_QCOM_H_ */
-- 
2.27.0

RE: [PATCH v6 5/5] scsi: ufs-qcom: add Inline Crypto Engine support

[Avri Altman]

> 
> 
> From: Eric Biggers <ebiggers@google.com>
> 
> Add support for Qualcomm Inline Crypto Engine (ICE) to ufs-qcom.
> 
> The standards-compliant parts, such as querying the crypto capabilities
> and enabling crypto for individual UFS requests, are already handled by
> ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
> However, ICE requires vendor-specific init, enable, and resume logic,
> and it requires that keys be programmed and evicted by vendor-specific
> SMC calls.  Make the ufs-qcom driver handle these details.
> 
> I tested this on Dragonboard 845c, which is a publicly available
> development board that uses the Snapdragon 845 SoC and runs the upstream
> Linux kernel.  This is the same SoC used in the Pixel 3 and Pixel 3 XL
> phones.  This testing included (among other things) verifying that the
> expected ciphertext was produced, both manually using ext4 encryption
> and automatically using a block layer self-test I've written.
> 
> I've also tested that this driver works nearly as-is on the Snapdragon
> 765 and Snapdragon 865 SoCs.  And others have tested it on Snapdragon
> 850, Snapdragon 855, and Snapdragon 865 (see the Tested-by tags).
> 
> This is based very loosely on the vendor-provided driver in the kernel
> source code for the Pixel 3, but I've greatly simplified it.  Also, for
> now I've only included support for major version 3 of ICE, since that's
> all I have the hardware to test with the mainline kernel.  Plus it
> appears that version 3 is easier to use than older versions of ICE.
> 
> For now, only allow using AES-256-XTS.  The hardware also declares
> support for AES-128-XTS, AES-{128,256}-ECB, and AES-{128,256}-CBC
> (BitLocker variant).  But none of these others are really useful, and
> they'd need to be individually tested to be sure they worked properly.
> 
> This commit also changes the name of the loadable module from "ufs-qcom"
> to "ufs_qcom", as this is necessary to compile it from multiple source
> files (unless we were to rename ufs-qcom.c).
> 
> Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
> Tested-by: Thara Gopinath <thara.gopinath@linaro.org> # db845c, sm8150-
> mtp, sm8250-mtp
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good to me.
Reviewed-by: Avri Altman <avri.altman@wdc.com>


> ---
>  MAINTAINERS                     |   2 +-
>  drivers/scsi/ufs/Kconfig        |   1 +
>  drivers/scsi/ufs/Makefile       |   4 +-
>  drivers/scsi/ufs/ufs-qcom-ice.c | 245 ++++++++++++++++++++++++++++++++
>  drivers/scsi/ufs/ufs-qcom.c     |  12 +-
>  drivers/scsi/ufs/ufs-qcom.h     |  27 ++++
>  6 files changed, 288 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 68f21d46614c..aa9c924facc6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2271,7 +2271,7 @@ F:        drivers/pci/controller/dwc/pcie-qcom.c
>  F:     drivers/phy/qualcomm/
>  F:     drivers/power/*/msm*
>  F:     drivers/reset/reset-qcom-*
> -F:     drivers/scsi/ufs/ufs-qcom.*
> +F:     drivers/scsi/ufs/ufs-qcom*
>  F:     drivers/spi/spi-geni-qcom.c
>  F:     drivers/spi/spi-qcom-qspi.c
>  F:     drivers/spi/spi-qup.c
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index 46a4542f37eb..f6394999b98c 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -99,6 +99,7 @@ config SCSI_UFS_DWC_TC_PLATFORM
>  config SCSI_UFS_QCOM
>         tristate "QCOM specific hooks to UFS controller platform driver"
>         depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
> +       select QCOM_SCM
>         select RESET_CONTROLLER
>         help
>           This selects the QCOM specific additions to UFSHCD platform driver.
> diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
> index 9810963bc049..4679af1b564e 100644
> --- a/drivers/scsi/ufs/Makefile
> +++ b/drivers/scsi/ufs/Makefile
> @@ -3,7 +3,9 @@
>  obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o tc-
> dwc-g210.o
>  obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o
> ufshcd-dwc.o tc-dwc-g210.o
>  obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
> -obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
> +obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
> +ufs_qcom-y += ufs-qcom.o
> +ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
>  obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
>  obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
>  ufshcd-core-y                          += ufshcd.o ufs-sysfs.o
> diff --git a/drivers/scsi/ufs/ufs-qcom-ice.c b/drivers/scsi/ufs/ufs-qcom-ice.c
> new file mode 100644
> index 000000000000..bbb0ad7590ec
> --- /dev/null
> +++ b/drivers/scsi/ufs/ufs-qcom-ice.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Qualcomm ICE (Inline Crypto Engine) support.
> + *
> + * Copyright (c) 2014-2019, The Linux Foundation. All rights reserved.
> + * Copyright 2019 Google LLC
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/qcom_scm.h>
> +
> +#include "ufshcd-crypto.h"
> +#include "ufs-qcom.h"
> +
> +#define AES_256_XTS_KEY_SIZE                   64
> +
> +/* QCOM ICE registers */
> +
> +#define QCOM_ICE_REG_CONTROL                   0x0000
> +#define QCOM_ICE_REG_RESET                     0x0004
> +#define QCOM_ICE_REG_VERSION                   0x0008
> +#define QCOM_ICE_REG_FUSE_SETTING              0x0010
> +#define QCOM_ICE_REG_PARAMETERS_1              0x0014
> +#define QCOM_ICE_REG_PARAMETERS_2              0x0018
> +#define QCOM_ICE_REG_PARAMETERS_3              0x001C
> +#define QCOM_ICE_REG_PARAMETERS_4              0x0020
> +#define QCOM_ICE_REG_PARAMETERS_5              0x0024
> +
> +/* QCOM ICE v3.X only */
> +#define QCOM_ICE_GENERAL_ERR_STTS              0x0040
> +#define QCOM_ICE_INVALID_CCFG_ERR_STTS         0x0030
> +#define QCOM_ICE_GENERAL_ERR_MASK              0x0044
> +
> +/* QCOM ICE v2.X only */
> +#define QCOM_ICE_REG_NON_SEC_IRQ_STTS          0x0040
> +#define QCOM_ICE_REG_NON_SEC_IRQ_MASK          0x0044
> +
> +#define QCOM_ICE_REG_NON_SEC_IRQ_CLR           0x0048
> +#define QCOM_ICE_REG_STREAM1_ERROR_SYNDROME1   0x0050
> +#define QCOM_ICE_REG_STREAM1_ERROR_SYNDROME2   0x0054
> +#define QCOM_ICE_REG_STREAM2_ERROR_SYNDROME1   0x0058
> +#define QCOM_ICE_REG_STREAM2_ERROR_SYNDROME2   0x005C
> +#define QCOM_ICE_REG_STREAM1_BIST_ERROR_VEC    0x0060
> +#define QCOM_ICE_REG_STREAM2_BIST_ERROR_VEC    0x0064
> +#define QCOM_ICE_REG_STREAM1_BIST_FINISH_VEC   0x0068
> +#define QCOM_ICE_REG_STREAM2_BIST_FINISH_VEC   0x006C
> +#define QCOM_ICE_REG_BIST_STATUS               0x0070
> +#define QCOM_ICE_REG_BYPASS_STATUS             0x0074
> +#define QCOM_ICE_REG_ADVANCED_CONTROL          0x1000
> +#define QCOM_ICE_REG_ENDIAN_SWAP               0x1004
> +#define QCOM_ICE_REG_TEST_BUS_CONTROL          0x1010
> +#define QCOM_ICE_REG_TEST_BUS_REG              0x1014
> +
> +/* BIST ("built-in self-test"?) status flags */
> +#define QCOM_ICE_BIST_STATUS_MASK              0xF0000000
> +
> +#define QCOM_ICE_FUSE_SETTING_MASK             0x1
> +#define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK    0x2
> +#define QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK    0x4
> +
> +#define qcom_ice_writel(host, val, reg)        \
> +       writel((val), (host)->ice_mmio + (reg))
> +#define qcom_ice_readl(host, reg)      \
> +       readl((host)->ice_mmio + (reg))
> +
> +static bool qcom_ice_supported(struct ufs_qcom_host *host)
> +{
> +       struct device *dev = host->hba->dev;
> +       u32 regval = qcom_ice_readl(host, QCOM_ICE_REG_VERSION);
> +       int major = regval >> 24;
> +       int minor = (regval >> 16) & 0xFF;
> +       int step = regval & 0xFFFF;
> +
> +       /* For now this driver only supports ICE version 3. */
> +       if (major != 3) {
> +               dev_warn(dev, "Unsupported ICE version: v%d.%d.%d\n",
> +                        major, minor, step);
> +               return false;
> +       }
> +
> +       dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
> +                major, minor, step);
> +
> +       /* If fuses are blown, ICE might not work in the standard way. */
> +       regval = qcom_ice_readl(host, QCOM_ICE_REG_FUSE_SETTING);
> +       if (regval & (QCOM_ICE_FUSE_SETTING_MASK |
> +                     QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK |
> +                     QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK)) {
> +               dev_warn(dev, "Fuses are blown; ICE is unusable!\n");
> +               return false;
> +       }
> +       return true;
> +}
> +
> +int ufs_qcom_ice_init(struct ufs_qcom_host *host)
> +{
> +       struct ufs_hba *hba = host->hba;
> +       struct device *dev = hba->dev;
> +       struct platform_device *pdev = to_platform_device(dev);
> +       struct resource *res;
> +       int err;
> +
> +       if (!(ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES) &
> +             MASK_CRYPTO_SUPPORT))
> +               return 0;
> +
> +       res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ice");
> +       if (!res) {
> +               dev_warn(dev, "ICE registers not found\n");
> +               goto disable;
> +       }
> +
> +       if (!qcom_scm_ice_available()) {
> +               dev_warn(dev, "ICE SCM interface not found\n");
> +               goto disable;
> +       }
> +
> +       host->ice_mmio = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(host->ice_mmio)) {
> +               err = PTR_ERR(host->ice_mmio);
> +               dev_err(dev, "Failed to map ICE registers; err=%d\n", err);
> +               return err;
> +       }
> +
> +       if (!qcom_ice_supported(host))
> +               goto disable;
> +
> +       return 0;
> +
> +disable:
> +       dev_warn(dev, "Disabling inline encryption support\n");
> +       hba->caps &= ~UFSHCD_CAP_CRYPTO;
> +       return 0;
> +}
> +
> +static void qcom_ice_low_power_mode_enable(struct ufs_qcom_host *host)
> +{
> +       u32 regval;
> +
> +       regval = qcom_ice_readl(host, QCOM_ICE_REG_ADVANCED_CONTROL);
> +       /*
> +        * Enable low power mode sequence
> +        * [0]-0, [1]-0, [2]-0, [3]-E, [4]-0, [5]-0, [6]-0, [7]-0
> +        */
> +       regval |= 0x7000;
> +       qcom_ice_writel(host, regval, QCOM_ICE_REG_ADVANCED_CONTROL);
> +}
> +
> +static void qcom_ice_optimization_enable(struct ufs_qcom_host *host)
> +{
> +       u32 regval;
> +
> +       /* ICE Optimizations Enable Sequence */
> +       regval = qcom_ice_readl(host, QCOM_ICE_REG_ADVANCED_CONTROL);
> +       regval |= 0xD807100;
> +       /* ICE HPG requires delay before writing */
> +       udelay(5);
> +       qcom_ice_writel(host, regval, QCOM_ICE_REG_ADVANCED_CONTROL);
> +       udelay(5);
> +}
> +
> +int ufs_qcom_ice_enable(struct ufs_qcom_host *host)
> +{
> +       if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
> +               return 0;
> +       qcom_ice_low_power_mode_enable(host);
> +       qcom_ice_optimization_enable(host);
> +       return ufs_qcom_ice_resume(host);
> +}
> +
> +/* Poll until all BIST bits are reset */
> +static int qcom_ice_wait_bist_status(struct ufs_qcom_host *host)
> +{
> +       int count;
> +       u32 reg;
> +
> +       for (count = 0; count < 100; count++) {
> +               reg = qcom_ice_readl(host, QCOM_ICE_REG_BIST_STATUS);
> +               if (!(reg & QCOM_ICE_BIST_STATUS_MASK))
> +                       break;
> +               udelay(50);
> +       }
> +       if (reg)
> +               return -ETIMEDOUT;
> +       return 0;
> +}
> +
> +int ufs_qcom_ice_resume(struct ufs_qcom_host *host)
> +{
> +       int err;
> +
> +       if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
> +               return 0;
> +
> +       err = qcom_ice_wait_bist_status(host);
> +       if (err) {
> +               dev_err(host->hba->dev, "BIST status error (%d)\n", err);
> +               return err;
> +       }
> +       return 0;
> +}
> +
> +/*
> + * Program a key into a QC ICE keyslot, or evict a keyslot.  QC ICE requires
> + * vendor-specific SCM calls for this; it doesn't support the standard way.
> + */
> +int ufs_qcom_ice_program_key(struct ufs_hba *hba,
> +                            const union ufs_crypto_cfg_entry *cfg, int slot)
> +{
> +       union ufs_crypto_cap_entry cap;
> +       union {
> +               u8 bytes[AES_256_XTS_KEY_SIZE];
> +               u32 words[AES_256_XTS_KEY_SIZE / sizeof(u32)];
> +       } key;
> +       int i;
> +       int err;
> +
> +       if (!(cfg->config_enable & UFS_CRYPTO_CONFIGURATION_ENABLE))
> +               return qcom_scm_ice_invalidate_key(slot);
> +
> +       /* Only AES-256-XTS has been tested so far. */
> +       cap = hba->crypto_cap_array[cfg->crypto_cap_idx];
> +       if (cap.algorithm_id != UFS_CRYPTO_ALG_AES_XTS ||
> +           cap.key_size != UFS_CRYPTO_KEY_SIZE_256) {
> +               dev_err_ratelimited(hba->dev,
> +                                   "Unhandled crypto capability; algorithm_id=%d,
> key_size=%d\n",
> +                                   cap.algorithm_id, cap.key_size);
> +               return -EINVAL;
> +       }
> +
> +       memcpy(key.bytes, cfg->crypto_key, AES_256_XTS_KEY_SIZE);
> +
> +       /*
> +        * The SCM call byte-swaps the 32-bit words of the key.  So we have to
> +        * do the same, in order for the final key be correct.
> +        */
> +       for (i = 0; i < ARRAY_SIZE(key.words); i++)
> +               __cpu_to_be32s(&key.words[i]);
> +
> +       err = qcom_scm_ice_set_key(slot, key.bytes, AES_256_XTS_KEY_SIZE,
> +                                  QCOM_SCM_ICE_CIPHER_AES_256_XTS,
> +                                  cfg->data_unit_size);
> +       memzero_explicit(&key, sizeof(key));
> +       return err;
> +}
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index bd0b4ed7b37a..139c3ae05e95 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -365,7 +365,7 @@ static int ufs_qcom_hce_enable_notify(struct ufs_hba
> *hba,
>                 /* check if UFS PHY moved from DISABLED to HIBERN8 */
>                 err = ufs_qcom_check_hibern8(hba);
>                 ufs_qcom_enable_hw_clk_gating(hba);
> -
> +               ufs_qcom_ice_enable(host);
>                 break;
>         default:
>                 dev_err(hba->dev, "%s: invalid status %d\n", __func__, status);
> @@ -613,6 +613,10 @@ static int ufs_qcom_resume(struct ufs_hba *hba,
> enum ufs_pm_op pm_op)
>                         return err;
>         }
> 
> +       err = ufs_qcom_ice_resume(host);
> +       if (err)
> +               return err;
> +
>         hba->is_sys_suspended = false;
>         return 0;
>  }
> @@ -1071,6 +1075,7 @@ static void ufs_qcom_set_caps(struct ufs_hba *hba)
>         hba->caps |= UFSHCD_CAP_CLK_SCALING;
>         hba->caps |= UFSHCD_CAP_AUTO_BKOPS_SUSPEND;
>         hba->caps |= UFSHCD_CAP_WB_EN;
> +       hba->caps |= UFSHCD_CAP_CRYPTO;
> 
>         if (host->hw_ver.major >= 0x2) {
>                 host->caps = UFS_QCOM_CAP_QUNIPRO |
> @@ -1298,6 +1303,10 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>         ufs_qcom_set_caps(hba);
>         ufs_qcom_advertise_quirks(hba);
> 
> +       err = ufs_qcom_ice_init(host);
> +       if (err)
> +               goto out_variant_clear;
> +
>         ufs_qcom_set_bus_vote(hba, true);
>         ufs_qcom_setup_clocks(hba, true, POST_CHANGE);
> 
> @@ -1736,6 +1745,7 @@ static const struct ufs_hba_variant_ops
> ufs_hba_qcom_vops = {
>         .dbg_register_dump      = ufs_qcom_dump_dbg_regs,
>         .device_reset           = ufs_qcom_device_reset,
>         .config_scaling_param = ufs_qcom_config_scaling_param,
> +       .program_key            = ufs_qcom_ice_program_key,
>  };
> 
>  /**
> diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
> index 2d95e7cc7187..97247d17e258 100644
> --- a/drivers/scsi/ufs/ufs-qcom.h
> +++ b/drivers/scsi/ufs/ufs-qcom.h
> @@ -227,6 +227,9 @@ struct ufs_qcom_host {
>         void __iomem *dev_ref_clk_ctrl_mmio;
>         bool is_dev_ref_clk_enabled;
>         struct ufs_hw_version hw_ver;
> +#ifdef CONFIG_SCSI_UFS_CRYPTO
> +       void __iomem *ice_mmio;
> +#endif
> 
>         u32 dev_ref_clk_en_mask;
> 
> @@ -264,4 +267,28 @@ static inline bool ufs_qcom_cap_qunipro(struct
> ufs_qcom_host *host)
>                 return false;
>  }
> 
> +/* ufs-qcom-ice.c */
> +
> +#ifdef CONFIG_SCSI_UFS_CRYPTO
> +int ufs_qcom_ice_init(struct ufs_qcom_host *host);
> +int ufs_qcom_ice_enable(struct ufs_qcom_host *host);
> +int ufs_qcom_ice_resume(struct ufs_qcom_host *host);
> +int ufs_qcom_ice_program_key(struct ufs_hba *hba,
> +                            const union ufs_crypto_cfg_entry *cfg, int slot);
> +#else
> +static inline int ufs_qcom_ice_init(struct ufs_qcom_host *host)
> +{
> +       return 0;
> +}
> +static inline int ufs_qcom_ice_enable(struct ufs_qcom_host *host)
> +{
> +       return 0;
> +}
> +static inline int ufs_qcom_ice_resume(struct ufs_qcom_host *host)
> +{
> +       return 0;
> +}
> +#define ufs_qcom_ice_program_key NULL
> +#endif /* !CONFIG_SCSI_UFS_CRYPTO */
> +
>  #endif /* UFS_QCOM_H_ */
> --
> 2.27.0

Re: [PATCH v6 5/5] scsi: ufs-qcom: add Inline Crypto Engine support

[Bjorn Andersson]

On Fri 10 Jul 00:20 PDT 2020, Eric Biggers wrote:

> From: Eric Biggers <ebiggers@google.com>
> 
> Add support for Qualcomm Inline Crypto Engine (ICE) to ufs-qcom.
> 
> The standards-compliant parts, such as querying the crypto capabilities
> and enabling crypto for individual UFS requests, are already handled by
> ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
> However, ICE requires vendor-specific init, enable, and resume logic,
> and it requires that keys be programmed and evicted by vendor-specific
> SMC calls.  Make the ufs-qcom driver handle these details.
> 
> I tested this on Dragonboard 845c, which is a publicly available
> development board that uses the Snapdragon 845 SoC and runs the upstream
> Linux kernel.  This is the same SoC used in the Pixel 3 and Pixel 3 XL
> phones.  This testing included (among other things) verifying that the
> expected ciphertext was produced, both manually using ext4 encryption
> and automatically using a block layer self-test I've written.
> 
> I've also tested that this driver works nearly as-is on the Snapdragon
> 765 and Snapdragon 865 SoCs.  And others have tested it on Snapdragon
> 850, Snapdragon 855, and Snapdragon 865 (see the Tested-by tags).
> 
> This is based very loosely on the vendor-provided driver in the kernel
> source code for the Pixel 3, but I've greatly simplified it.  Also, for
> now I've only included support for major version 3 of ICE, since that's
> all I have the hardware to test with the mainline kernel.  Plus it
> appears that version 3 is easier to use than older versions of ICE.
> 
> For now, only allow using AES-256-XTS.  The hardware also declares
> support for AES-128-XTS, AES-{128,256}-ECB, and AES-{128,256}-CBC
> (BitLocker variant).  But none of these others are really useful, and
> they'd need to be individually tested to be sure they worked properly.
> 
> This commit also changes the name of the loadable module from "ufs-qcom"
> to "ufs_qcom", as this is necessary to compile it from multiple source
> files (unless we were to rename ufs-qcom.c).
> 

Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
> Tested-by: Thara Gopinath <thara.gopinath@linaro.org> # db845c, sm8150-mtp, sm8250-mtp
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  MAINTAINERS                     |   2 +-
>  drivers/scsi/ufs/Kconfig        |   1 +
>  drivers/scsi/ufs/Makefile       |   4 +-
>  drivers/scsi/ufs/ufs-qcom-ice.c | 245 ++++++++++++++++++++++++++++++++
>  drivers/scsi/ufs/ufs-qcom.c     |  12 +-
>  drivers/scsi/ufs/ufs-qcom.h     |  27 ++++
>  6 files changed, 288 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 68f21d46614c..aa9c924facc6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2271,7 +2271,7 @@ F:	drivers/pci/controller/dwc/pcie-qcom.c
>  F:	drivers/phy/qualcomm/
>  F:	drivers/power/*/msm*
>  F:	drivers/reset/reset-qcom-*
> -F:	drivers/scsi/ufs/ufs-qcom.*
> +F:	drivers/scsi/ufs/ufs-qcom*
>  F:	drivers/spi/spi-geni-qcom.c
>  F:	drivers/spi/spi-qcom-qspi.c
>  F:	drivers/spi/spi-qup.c
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index 46a4542f37eb..f6394999b98c 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -99,6 +99,7 @@ config SCSI_UFS_DWC_TC_PLATFORM
>  config SCSI_UFS_QCOM
>  	tristate "QCOM specific hooks to UFS controller platform driver"
>  	depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
> +	select QCOM_SCM
>  	select RESET_CONTROLLER
>  	help
>  	  This selects the QCOM specific additions to UFSHCD platform driver.
> diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
> index 9810963bc049..4679af1b564e 100644
> --- a/drivers/scsi/ufs/Makefile
> +++ b/drivers/scsi/ufs/Makefile
> @@ -3,7 +3,9 @@
>  obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o tc-dwc-g210.o
>  obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o tc-dwc-g210.o
>  obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
> -obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
> +obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
> +ufs_qcom-y += ufs-qcom.o
> +ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
>  obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
>  obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
>  ufshcd-core-y				+= ufshcd.o ufs-sysfs.o
> diff --git a/drivers/scsi/ufs/ufs-qcom-ice.c b/drivers/scsi/ufs/ufs-qcom-ice.c
> new file mode 100644
> index 000000000000..bbb0ad7590ec
> --- /dev/null
> +++ b/drivers/scsi/ufs/ufs-qcom-ice.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Qualcomm ICE (Inline Crypto Engine) support.
> + *
> + * Copyright (c) 2014-2019, The Linux Foundation. All rights reserved.
> + * Copyright 2019 Google LLC
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/qcom_scm.h>
> +
> +#include "ufshcd-crypto.h"
> +#include "ufs-qcom.h"
> +
> +#define AES_256_XTS_KEY_SIZE			64
> +
> +/* QCOM ICE registers */
> +
> +#define QCOM_ICE_REG_CONTROL			0x0000
> +#define QCOM_ICE_REG_RESET			0x0004
> +#define QCOM_ICE_REG_VERSION			0x0008
> +#define QCOM_ICE_REG_FUSE_SETTING		0x0010
> +#define QCOM_ICE_REG_PARAMETERS_1		0x0014
> +#define QCOM_ICE_REG_PARAMETERS_2		0x0018
> +#define QCOM_ICE_REG_PARAMETERS_3		0x001C
> +#define QCOM_ICE_REG_PARAMETERS_4		0x0020
> +#define QCOM_ICE_REG_PARAMETERS_5		0x0024
> +
> +/* QCOM ICE v3.X only */
> +#define QCOM_ICE_GENERAL_ERR_STTS		0x0040
> +#define QCOM_ICE_INVALID_CCFG_ERR_STTS		0x0030
> +#define QCOM_ICE_GENERAL_ERR_MASK		0x0044
> +
> +/* QCOM ICE v2.X only */
> +#define QCOM_ICE_REG_NON_SEC_IRQ_STTS		0x0040
> +#define QCOM_ICE_REG_NON_SEC_IRQ_MASK		0x0044
> +
> +#define QCOM_ICE_REG_NON_SEC_IRQ_CLR		0x0048
> +#define QCOM_ICE_REG_STREAM1_ERROR_SYNDROME1	0x0050
> +#define QCOM_ICE_REG_STREAM1_ERROR_SYNDROME2	0x0054
> +#define QCOM_ICE_REG_STREAM2_ERROR_SYNDROME1	0x0058
> +#define QCOM_ICE_REG_STREAM2_ERROR_SYNDROME2	0x005C
> +#define QCOM_ICE_REG_STREAM1_BIST_ERROR_VEC	0x0060
> +#define QCOM_ICE_REG_STREAM2_BIST_ERROR_VEC	0x0064
> +#define QCOM_ICE_REG_STREAM1_BIST_FINISH_VEC	0x0068
> +#define QCOM_ICE_REG_STREAM2_BIST_FINISH_VEC	0x006C
> +#define QCOM_ICE_REG_BIST_STATUS		0x0070
> +#define QCOM_ICE_REG_BYPASS_STATUS		0x0074
> +#define QCOM_ICE_REG_ADVANCED_CONTROL		0x1000
> +#define QCOM_ICE_REG_ENDIAN_SWAP		0x1004
> +#define QCOM_ICE_REG_TEST_BUS_CONTROL		0x1010
> +#define QCOM_ICE_REG_TEST_BUS_REG		0x1014
> +
> +/* BIST ("built-in self-test"?) status flags */
> +#define QCOM_ICE_BIST_STATUS_MASK		0xF0000000
> +
> +#define QCOM_ICE_FUSE_SETTING_MASK		0x1
> +#define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK	0x2
> +#define QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK	0x4
> +
> +#define qcom_ice_writel(host, val, reg)	\
> +	writel((val), (host)->ice_mmio + (reg))
> +#define qcom_ice_readl(host, reg)	\
> +	readl((host)->ice_mmio + (reg))
> +
> +static bool qcom_ice_supported(struct ufs_qcom_host *host)
> +{
> +	struct device *dev = host->hba->dev;
> +	u32 regval = qcom_ice_readl(host, QCOM_ICE_REG_VERSION);
> +	int major = regval >> 24;
> +	int minor = (regval >> 16) & 0xFF;
> +	int step = regval & 0xFFFF;
> +
> +	/* For now this driver only supports ICE version 3. */
> +	if (major != 3) {
> +		dev_warn(dev, "Unsupported ICE version: v%d.%d.%d\n",
> +			 major, minor, step);
> +		return false;
> +	}
> +
> +	dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
> +		 major, minor, step);
> +
> +	/* If fuses are blown, ICE might not work in the standard way. */
> +	regval = qcom_ice_readl(host, QCOM_ICE_REG_FUSE_SETTING);
> +	if (regval & (QCOM_ICE_FUSE_SETTING_MASK |
> +		      QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK |
> +		      QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK)) {
> +		dev_warn(dev, "Fuses are blown; ICE is unusable!\n");
> +		return false;
> +	}
> +	return true;
> +}
> +
> +int ufs_qcom_ice_init(struct ufs_qcom_host *host)
> +{
> +	struct ufs_hba *hba = host->hba;
> +	struct device *dev = hba->dev;
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct resource *res;
> +	int err;
> +
> +	if (!(ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES) &
> +	      MASK_CRYPTO_SUPPORT))
> +		return 0;
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ice");
> +	if (!res) {
> +		dev_warn(dev, "ICE registers not found\n");
> +		goto disable;
> +	}
> +
> +	if (!qcom_scm_ice_available()) {
> +		dev_warn(dev, "ICE SCM interface not found\n");
> +		goto disable;
> +	}
> +
> +	host->ice_mmio = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(host->ice_mmio)) {
> +		err = PTR_ERR(host->ice_mmio);
> +		dev_err(dev, "Failed to map ICE registers; err=%d\n", err);
> +		return err;
> +	}
> +
> +	if (!qcom_ice_supported(host))
> +		goto disable;
> +
> +	return 0;
> +
> +disable:
> +	dev_warn(dev, "Disabling inline encryption support\n");
> +	hba->caps &= ~UFSHCD_CAP_CRYPTO;
> +	return 0;
> +}
> +
> +static void qcom_ice_low_power_mode_enable(struct ufs_qcom_host *host)
> +{
> +	u32 regval;
> +
> +	regval = qcom_ice_readl(host, QCOM_ICE_REG_ADVANCED_CONTROL);
> +	/*
> +	 * Enable low power mode sequence
> +	 * [0]-0, [1]-0, [2]-0, [3]-E, [4]-0, [5]-0, [6]-0, [7]-0
> +	 */
> +	regval |= 0x7000;
> +	qcom_ice_writel(host, regval, QCOM_ICE_REG_ADVANCED_CONTROL);
> +}
> +
> +static void qcom_ice_optimization_enable(struct ufs_qcom_host *host)
> +{
> +	u32 regval;
> +
> +	/* ICE Optimizations Enable Sequence */
> +	regval = qcom_ice_readl(host, QCOM_ICE_REG_ADVANCED_CONTROL);
> +	regval |= 0xD807100;
> +	/* ICE HPG requires delay before writing */
> +	udelay(5);
> +	qcom_ice_writel(host, regval, QCOM_ICE_REG_ADVANCED_CONTROL);
> +	udelay(5);
> +}
> +
> +int ufs_qcom_ice_enable(struct ufs_qcom_host *host)
> +{
> +	if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
> +		return 0;
> +	qcom_ice_low_power_mode_enable(host);
> +	qcom_ice_optimization_enable(host);
> +	return ufs_qcom_ice_resume(host);
> +}
> +
> +/* Poll until all BIST bits are reset */
> +static int qcom_ice_wait_bist_status(struct ufs_qcom_host *host)
> +{
> +	int count;
> +	u32 reg;
> +
> +	for (count = 0; count < 100; count++) {
> +		reg = qcom_ice_readl(host, QCOM_ICE_REG_BIST_STATUS);
> +		if (!(reg & QCOM_ICE_BIST_STATUS_MASK))
> +			break;
> +		udelay(50);
> +	}
> +	if (reg)
> +		return -ETIMEDOUT;
> +	return 0;
> +}
> +
> +int ufs_qcom_ice_resume(struct ufs_qcom_host *host)
> +{
> +	int err;
> +
> +	if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
> +		return 0;
> +
> +	err = qcom_ice_wait_bist_status(host);
> +	if (err) {
> +		dev_err(host->hba->dev, "BIST status error (%d)\n", err);
> +		return err;
> +	}
> +	return 0;
> +}
> +
> +/*
> + * Program a key into a QC ICE keyslot, or evict a keyslot.  QC ICE requires
> + * vendor-specific SCM calls for this; it doesn't support the standard way.
> + */
> +int ufs_qcom_ice_program_key(struct ufs_hba *hba,
> +			     const union ufs_crypto_cfg_entry *cfg, int slot)
> +{
> +	union ufs_crypto_cap_entry cap;
> +	union {
> +		u8 bytes[AES_256_XTS_KEY_SIZE];
> +		u32 words[AES_256_XTS_KEY_SIZE / sizeof(u32)];
> +	} key;
> +	int i;
> +	int err;
> +
> +	if (!(cfg->config_enable & UFS_CRYPTO_CONFIGURATION_ENABLE))
> +		return qcom_scm_ice_invalidate_key(slot);
> +
> +	/* Only AES-256-XTS has been tested so far. */
> +	cap = hba->crypto_cap_array[cfg->crypto_cap_idx];
> +	if (cap.algorithm_id != UFS_CRYPTO_ALG_AES_XTS ||
> +	    cap.key_size != UFS_CRYPTO_KEY_SIZE_256) {
> +		dev_err_ratelimited(hba->dev,
> +				    "Unhandled crypto capability; algorithm_id=%d, key_size=%d\n",
> +				    cap.algorithm_id, cap.key_size);
> +		return -EINVAL;
> +	}
> +
> +	memcpy(key.bytes, cfg->crypto_key, AES_256_XTS_KEY_SIZE);
> +
> +	/*
> +	 * The SCM call byte-swaps the 32-bit words of the key.  So we have to
> +	 * do the same, in order for the final key be correct.
> +	 */
> +	for (i = 0; i < ARRAY_SIZE(key.words); i++)
> +		__cpu_to_be32s(&key.words[i]);
> +
> +	err = qcom_scm_ice_set_key(slot, key.bytes, AES_256_XTS_KEY_SIZE,
> +				   QCOM_SCM_ICE_CIPHER_AES_256_XTS,
> +				   cfg->data_unit_size);
> +	memzero_explicit(&key, sizeof(key));
> +	return err;
> +}
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index bd0b4ed7b37a..139c3ae05e95 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -365,7 +365,7 @@ static int ufs_qcom_hce_enable_notify(struct ufs_hba *hba,
>  		/* check if UFS PHY moved from DISABLED to HIBERN8 */
>  		err = ufs_qcom_check_hibern8(hba);
>  		ufs_qcom_enable_hw_clk_gating(hba);
> -
> +		ufs_qcom_ice_enable(host);
>  		break;
>  	default:
>  		dev_err(hba->dev, "%s: invalid status %d\n", __func__, status);
> @@ -613,6 +613,10 @@ static int ufs_qcom_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  			return err;
>  	}
>  
> +	err = ufs_qcom_ice_resume(host);
> +	if (err)
> +		return err;
> +
>  	hba->is_sys_suspended = false;
>  	return 0;
>  }
> @@ -1071,6 +1075,7 @@ static void ufs_qcom_set_caps(struct ufs_hba *hba)
>  	hba->caps |= UFSHCD_CAP_CLK_SCALING;
>  	hba->caps |= UFSHCD_CAP_AUTO_BKOPS_SUSPEND;
>  	hba->caps |= UFSHCD_CAP_WB_EN;
> +	hba->caps |= UFSHCD_CAP_CRYPTO;
>  
>  	if (host->hw_ver.major >= 0x2) {
>  		host->caps = UFS_QCOM_CAP_QUNIPRO |
> @@ -1298,6 +1303,10 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>  	ufs_qcom_set_caps(hba);
>  	ufs_qcom_advertise_quirks(hba);
>  
> +	err = ufs_qcom_ice_init(host);
> +	if (err)
> +		goto out_variant_clear;
> +
>  	ufs_qcom_set_bus_vote(hba, true);
>  	ufs_qcom_setup_clocks(hba, true, POST_CHANGE);
>  
> @@ -1736,6 +1745,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops = {
>  	.dbg_register_dump	= ufs_qcom_dump_dbg_regs,
>  	.device_reset		= ufs_qcom_device_reset,
>  	.config_scaling_param = ufs_qcom_config_scaling_param,
> +	.program_key		= ufs_qcom_ice_program_key,
>  };
>  
>  /**
> diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
> index 2d95e7cc7187..97247d17e258 100644
> --- a/drivers/scsi/ufs/ufs-qcom.h
> +++ b/drivers/scsi/ufs/ufs-qcom.h
> @@ -227,6 +227,9 @@ struct ufs_qcom_host {
>  	void __iomem *dev_ref_clk_ctrl_mmio;
>  	bool is_dev_ref_clk_enabled;
>  	struct ufs_hw_version hw_ver;
> +#ifdef CONFIG_SCSI_UFS_CRYPTO
> +	void __iomem *ice_mmio;
> +#endif
>  
>  	u32 dev_ref_clk_en_mask;
>  
> @@ -264,4 +267,28 @@ static inline bool ufs_qcom_cap_qunipro(struct ufs_qcom_host *host)
>  		return false;
>  }
>  
> +/* ufs-qcom-ice.c */
> +
> +#ifdef CONFIG_SCSI_UFS_CRYPTO
> +int ufs_qcom_ice_init(struct ufs_qcom_host *host);
> +int ufs_qcom_ice_enable(struct ufs_qcom_host *host);
> +int ufs_qcom_ice_resume(struct ufs_qcom_host *host);
> +int ufs_qcom_ice_program_key(struct ufs_hba *hba,
> +			     const union ufs_crypto_cfg_entry *cfg, int slot);
> +#else
> +static inline int ufs_qcom_ice_init(struct ufs_qcom_host *host)
> +{
> +	return 0;
> +}
> +static inline int ufs_qcom_ice_enable(struct ufs_qcom_host *host)
> +{
> +	return 0;
> +}
> +static inline int ufs_qcom_ice_resume(struct ufs_qcom_host *host)
> +{
> +	return 0;
> +}
> +#define ufs_qcom_ice_program_key NULL
> +#endif /* !CONFIG_SCSI_UFS_CRYPTO */
> +
>  #endif /* UFS_QCOM_H_ */
> -- 
> 2.27.0
> 

Re: [PATCH v6 0/5] Inline crypto support on DragonBoard 845c

[Martin K. Petersen]

On Fri, 10 Jul 2020 00:20:07 -0700, Eric Biggers wrote:

> This patchset implements UFS inline encryption support on the
> DragonBoard 845c, using the Qualcomm Inline Crypto Engine (ICE)
> that's present on the Snapdragon 845 SoC.
> 
> This is based on top of scsi/5.9/scsi-queue, which contains the
> ufshcd-crypto patches by Satya Tangirala.
> 
> [...]

Applied to 5.9/scsi-queue, thanks!

[1/5] scsi: firmware: qcom_scm: Add support for programming inline crypto keys
      https://git.kernel.org/mkp/scsi/c/e10d24786adb
[2/5] scsi: ufs-qcom: Name the dev_ref_clk_ctrl registers
      https://git.kernel.org/mkp/scsi/c/12700db4f9f7
[4/5] scsi: ufs: Add program_key() variant op
      https://git.kernel.org/mkp/scsi/c/a5fedfacb402
[5/5] scsi: ufs-qcom: Add Inline Crypto Engine support
      https://git.kernel.org/mkp/scsi/c/de9063fbd769

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH v6 0/5] Inline crypto support on DragonBoard 845c

[Eric Biggers]

Hi Martin,

On Wed, Jul 22, 2020 at 12:28:29AM -0400, Martin K. Petersen wrote:
> On Fri, 10 Jul 2020 00:20:07 -0700, Eric Biggers wrote:
> 
> > This patchset implements UFS inline encryption support on the
> > DragonBoard 845c, using the Qualcomm Inline Crypto Engine (ICE)
> > that's present on the Snapdragon 845 SoC.
> > 
> > This is based on top of scsi/5.9/scsi-queue, which contains the
> > ufshcd-crypto patches by Satya Tangirala.
> > 
> > [...]
> 
> Applied to 5.9/scsi-queue, thanks!
> 
> [1/5] scsi: firmware: qcom_scm: Add support for programming inline crypto keys
>       https://git.kernel.org/mkp/scsi/c/e10d24786adb
> [2/5] scsi: ufs-qcom: Name the dev_ref_clk_ctrl registers
>       https://git.kernel.org/mkp/scsi/c/12700db4f9f7
> [4/5] scsi: ufs: Add program_key() variant op
>       https://git.kernel.org/mkp/scsi/c/a5fedfacb402
> [5/5] scsi: ufs-qcom: Add Inline Crypto Engine support
>       https://git.kernel.org/mkp/scsi/c/de9063fbd769

Seems that something went wrong when you applied patch 5.  It's supposed to add
the file ufs-qcom-ice.c, but the committed version doesn't have that file.

- Eric

Re: [PATCH v6 0/5] Inline crypto support on DragonBoard 845c

[Martin K. Petersen]

Eric,

> Seems that something went wrong when you applied patch 5.  It's
> supposed to add the file ufs-qcom-ice.c, but the committed version
> doesn't have that file.

Not sure what happened there, I recall it being a clean b4 am.

I fixed it up. Sorry about that!

-- 
Martin K. Petersen	Oracle Linux Engineering