[PATCH 1/1] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

[PATCH 1/1] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

[zheng.gong]

Add a new variant operation crypto_keyslot_remap to allow platform-specific
remapping of crypto keyslot indices before sending requests to the UFS
controller. This is required on platforms that partition the UFS crypto
engine's keyslots among multiple domains (e.g.virtual machines),
where each domain has a keyslot offset.

To support this, pass the UFS HBA pointer to ufshcd_prepare_lrbp_crypto(),
so the callback can access platform context.

This functionality is used on Samsung ExynosAuto UFS platforms, where
keyslot allocation is per-VM and a runtime offset is applied based on
the VM ID.

Signed-off-by: zheng.gong <zheng.gong@samsung.com>
---
 drivers/ufs/core/ufshcd-crypto.h | 10 ++++++++--
 drivers/ufs/core/ufshcd.c        |  9 +++++----
 include/ufs/ufshcd.h             |  6 ++++++
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/ufs/core/ufshcd-crypto.h b/drivers/ufs/core/ufshcd-crypto.h
index 89bb97c14c15..6dcba6817590 100644
--- a/drivers/ufs/core/ufshcd-crypto.h
+++ b/drivers/ufs/core/ufshcd-crypto.h
@@ -13,7 +13,8 @@
 
 #ifdef CONFIG_SCSI_UFS_CRYPTO
 
-static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
+static inline void ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
+					      struct request *rq,
 					      struct ufshcd_lrb *lrbp)
 {
 	if (!rq || !rq->crypt_keyslot) {
@@ -22,6 +23,10 @@ static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
 	}
 
 	lrbp->crypto_key_slot = blk_crypto_keyslot_index(rq->crypt_keyslot);
+
+	if (hba && hba->vops && hba->vops->crypto_keyslot_remap)
+		return hba->vops->crypto_keyslot_remap(hba, lrbp);
+
 	lrbp->data_unit_num = rq->crypt_ctx->bc_dun[0];
 }
 
@@ -74,7 +79,8 @@ void ufshcd_crypto_register(struct ufs_hba *hba, struct request_queue *q);
 
 #else /* CONFIG_SCSI_UFS_CRYPTO */
 
-static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
+static inline void ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
+					      struct request *rq,
 					      struct ufshcd_lrb *lrbp) { }
 
 static inline void
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 8339fec975b9..7417c6bec81a 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -2902,20 +2902,21 @@ static void ufshcd_comp_scsi_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 	ufshcd_prepare_utp_scsi_cmd_upiu(lrbp, upiu_flags);
 }
 
-static void __ufshcd_setup_cmd(struct ufshcd_lrb *lrbp, struct scsi_cmnd *cmd, u8 lun, int tag)
+static void __ufshcd_setup_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
+				  struct scsi_cmnd *cmd, u8 lun, int tag)
 {
 	memset(lrbp->ucd_req_ptr, 0, sizeof(*lrbp->ucd_req_ptr));
 
 	lrbp->cmd = cmd;
 	lrbp->task_tag = tag;
 	lrbp->lun = lun;
-	ufshcd_prepare_lrbp_crypto(cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
+	ufshcd_prepare_lrbp_crypto(hba, cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
 }
 
 static void ufshcd_setup_scsi_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
 				  struct scsi_cmnd *cmd, u8 lun, int tag)
 {
-	__ufshcd_setup_cmd(lrbp, cmd, lun, tag);
+	__ufshcd_setup_cmd(hba, lrbp, cmd, lun, tag);
 	lrbp->intr_cmd = !ufshcd_is_intr_aggr_allowed(hba);
 	lrbp->req_abort_skip = false;
 
@@ -3083,7 +3084,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
 static void ufshcd_setup_dev_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
 			     enum dev_cmd_type cmd_type, u8 lun, int tag)
 {
-	__ufshcd_setup_cmd(lrbp, NULL, lun, tag);
+	__ufshcd_setup_cmd(hba, lrbp, NULL, lun, tag);
 	lrbp->intr_cmd = true; /* No interrupt aggregation */
 	hba->dev_cmd.type = cmd_type;
 }
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 9425cfd9d00e..86b7bcc1da33 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -336,6 +336,10 @@ struct ufs_pwr_mode_info {
  * @config_esi: called to config Event Specific Interrupt
  * @config_scsi_dev: called to configure SCSI device parameters
  * @freq_to_gear_speed: called to map clock frequency to the max supported gear speed
+ * @crypto_keyslot_remap: called to adjust the keyslot index before sending
+ *	a request to the UFS controller. This allows the platform to apply a
+ *	hardware-specific keyslot offset or other mapping logic to determine
+ *	the correct keyslot for inline encryption.
  */
 struct ufs_hba_variant_ops {
 	const char *name;
@@ -385,6 +389,8 @@ struct ufs_hba_variant_ops {
 	int	(*config_esi)(struct ufs_hba *hba);
 	void	(*config_scsi_dev)(struct scsi_device *sdev);
 	u32	(*freq_to_gear_speed)(struct ufs_hba *hba, unsigned long freq);
+	void	(*crypto_keyslot_remap)(struct ufs_hba *hba,
+						struct ufshcd_lrb *lrbp);
 };
 
 /* clock gating state  */
-- 
2.50.1

Re: [PATCH 1/1] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

[Eric Biggers]

On Wed, Nov 12, 2025 at 11:05:24AM +0800, zheng.gong wrote:
> Add a new variant operation crypto_keyslot_remap to allow platform-specific
> remapping of crypto keyslot indices before sending requests to the UFS
> controller. This is required on platforms that partition the UFS crypto
> engine's keyslots among multiple domains (e.g.virtual machines),
> where each domain has a keyslot offset.
> 
> To support this, pass the UFS HBA pointer to ufshcd_prepare_lrbp_crypto(),
> so the callback can access platform context.
> 
> This functionality is used on Samsung ExynosAuto UFS platforms, where
> keyslot allocation is per-VM and a runtime offset is applied based on
> the VM ID.
> 
> Signed-off-by: zheng.gong <zheng.gong@samsung.com>
> ---
>  drivers/ufs/core/ufshcd-crypto.h | 10 ++++++++--
>  drivers/ufs/core/ufshcd.c        |  9 +++++----
>  include/ufs/ufshcd.h             |  6 ++++++
>  3 files changed, 19 insertions(+), 6 deletions(-)

This doesn't make sense by itself.  The patch that uses this new method
needs to be submitted alongside it.

- Eric

[PATCH v2 0/2] scsi: ufs: Add crypto_keyslot_remap support

[zheng.gong]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="1a2s3d4f!@", Size: 1679 bytes --]

This patch series adds support for platform-specific crypto keyslot remapping
in the UFS host driver, enabling secure inline encryption in multi-domain
environments (e.g., VMs).

The first patch introduces a new variant operation:
  ufs_hba_variant_ops::crypto_keyslot_remap
which allows platforms to adjust the keyslot index at request submission time.

The second patch adds a test module (CONFIG_SCSI_UFS_CRYPTO_TEST) to
demonstrate how the new hook is used — by applying a fixed offset to simulate
domain-specific keyslot layout. This patch series is in response to feedback from Eric on the v1 submission,
where he noted that the new callback needed to be used to make sense. Just a demonstration
of the new callback is included in this patch series.

Apologies for the delay in resubmitting — we have now added a test module to demonstrate
the usage of crypto_keyslot_remap in multi-domain environments.

Thank you for the review.

Changes since v1:
  - Added a test module to demonstrate usage of crypto_keyslot_remap
  - Fixed platform_driver.remove type (void, not int)
  - Improved commit message clarity

zheng.gong (2):
  scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap
  scsi: ufs: Add crypto keyslot remapping test module

 drivers/ufs/core/Kconfig              | 17 +++++
 drivers/ufs/core/Makefile             |  1 +
 drivers/ufs/core/ufshcd-crypto-test.c | 90 +++++++++++++++++++++++++++
 drivers/ufs/core/ufshcd-crypto.h      | 10 ++-
 drivers/ufs/core/ufshcd.c             |  9 +--
 include/ufs/ufshcd.h                  |  6 ++
 6 files changed, 127 insertions(+), 6 deletions(-)
 create mode 100644 drivers/ufs/core/ufshcd-crypto-test.c

[PATCH v2 1/2] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

[zheng.gong]

Add a new variant operation crypto_keyslot_remap to allow platform-specific
remapping of crypto keyslot indices before sending requests to the UFS
controller. This is required on platforms that partition the UFS crypto
engine's keyslots among multiple domains (e.g.virtual machines),
where each domain has a keyslot offset.

To support this, pass the UFS HBA pointer to ufshcd_prepare_lrbp_crypto(),
so the callback can access platform context.

This functionality is used on Samsung ExynosAuto UFS platforms, where
keyslot allocation is per-VM and a runtime offset is applied based on
the VM ID.

Signed-off-by: zheng.gong <zheng.gong@samsung.com>
---
 drivers/ufs/core/ufshcd-crypto.h | 10 ++++++++--
 drivers/ufs/core/ufshcd.c        |  9 +++++----
 include/ufs/ufshcd.h             |  6 ++++++
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/ufs/core/ufshcd-crypto.h b/drivers/ufs/core/ufshcd-crypto.h
index 89bb97c14c15..6dcba6817590 100644
--- a/drivers/ufs/core/ufshcd-crypto.h
+++ b/drivers/ufs/core/ufshcd-crypto.h
@@ -13,7 +13,8 @@
 
 #ifdef CONFIG_SCSI_UFS_CRYPTO
 
-static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
+static inline void ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
+					      struct request *rq,
 					      struct ufshcd_lrb *lrbp)
 {
 	if (!rq || !rq->crypt_keyslot) {
@@ -22,6 +23,10 @@ static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
 	}
 
 	lrbp->crypto_key_slot = blk_crypto_keyslot_index(rq->crypt_keyslot);
+
+	if (hba && hba->vops && hba->vops->crypto_keyslot_remap)
+		return hba->vops->crypto_keyslot_remap(hba, lrbp);
+
 	lrbp->data_unit_num = rq->crypt_ctx->bc_dun[0];
 }
 
@@ -74,7 +79,8 @@ void ufshcd_crypto_register(struct ufs_hba *hba, struct request_queue *q);
 
 #else /* CONFIG_SCSI_UFS_CRYPTO */
 
-static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
+static inline void ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
+					      struct request *rq,
 					      struct ufshcd_lrb *lrbp) { }
 
 static inline void
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 8339fec975b9..7417c6bec81a 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -2902,20 +2902,21 @@ static void ufshcd_comp_scsi_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 	ufshcd_prepare_utp_scsi_cmd_upiu(lrbp, upiu_flags);
 }
 
-static void __ufshcd_setup_cmd(struct ufshcd_lrb *lrbp, struct scsi_cmnd *cmd, u8 lun, int tag)
+static void __ufshcd_setup_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
+				  struct scsi_cmnd *cmd, u8 lun, int tag)
 {
 	memset(lrbp->ucd_req_ptr, 0, sizeof(*lrbp->ucd_req_ptr));
 
 	lrbp->cmd = cmd;
 	lrbp->task_tag = tag;
 	lrbp->lun = lun;
-	ufshcd_prepare_lrbp_crypto(cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
+	ufshcd_prepare_lrbp_crypto(hba, cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
 }
 
 static void ufshcd_setup_scsi_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
 				  struct scsi_cmnd *cmd, u8 lun, int tag)
 {
-	__ufshcd_setup_cmd(lrbp, cmd, lun, tag);
+	__ufshcd_setup_cmd(hba, lrbp, cmd, lun, tag);
 	lrbp->intr_cmd = !ufshcd_is_intr_aggr_allowed(hba);
 	lrbp->req_abort_skip = false;
 
@@ -3083,7 +3084,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
 static void ufshcd_setup_dev_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
 			     enum dev_cmd_type cmd_type, u8 lun, int tag)
 {
-	__ufshcd_setup_cmd(lrbp, NULL, lun, tag);
+	__ufshcd_setup_cmd(hba, lrbp, NULL, lun, tag);
 	lrbp->intr_cmd = true; /* No interrupt aggregation */
 	hba->dev_cmd.type = cmd_type;
 }
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 9425cfd9d00e..86b7bcc1da33 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -336,6 +336,10 @@ struct ufs_pwr_mode_info {
  * @config_esi: called to config Event Specific Interrupt
  * @config_scsi_dev: called to configure SCSI device parameters
  * @freq_to_gear_speed: called to map clock frequency to the max supported gear speed
+ * @crypto_keyslot_remap: called to adjust the keyslot index before sending
+ *	a request to the UFS controller. This allows the platform to apply a
+ *	hardware-specific keyslot offset or other mapping logic to determine
+ *	the correct keyslot for inline encryption.
  */
 struct ufs_hba_variant_ops {
 	const char *name;
@@ -385,6 +389,8 @@ struct ufs_hba_variant_ops {
 	int	(*config_esi)(struct ufs_hba *hba);
 	void	(*config_scsi_dev)(struct scsi_device *sdev);
 	u32	(*freq_to_gear_speed)(struct ufs_hba *hba, unsigned long freq);
+	void	(*crypto_keyslot_remap)(struct ufs_hba *hba,
+						struct ufshcd_lrb *lrbp);
 };
 
 /* clock gating state  */
-- 
2.50.1

[PATCH v2 2/2] scsi: ufs: Add crypto keyslot remapping test module

[zheng.gong]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="1a2s3d4f!@", Size: 4988 bytes --]

Add a test module (CONFIG_SCSI_UFS_CRYPTO_TEST) that demonstrates the use
of the new crypto_keyslot_remap variant operation. The module registers a
dummy variant ops that shifts the logical keyslot by a fixed offset (e.g., +8),
simulating a secondary domain in a multi-domain environment.

This is not a production driver, but serves to show that the hook is used.

Note: This patch is intended to illustrate usage. If maintainers prefer not
to include test modules in the core UFS driver, it can be dropped in a future
version.

Signed-off-by: zheng.gong <zheng.gong@samsung.com>
---
 drivers/ufs/core/Kconfig              | 17 +++++
 drivers/ufs/core/Makefile             |  1 +
 drivers/ufs/core/ufshcd-crypto-test.c | 90 +++++++++++++++++++++++++++
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/ufs/core/ufshcd-crypto-test.c

diff --git a/drivers/ufs/core/Kconfig b/drivers/ufs/core/Kconfig
index 817208ee64ec..c5dfd3722365 100644
--- a/drivers/ufs/core/Kconfig
+++ b/drivers/ufs/core/Kconfig
@@ -50,3 +50,20 @@ config SCSI_UFS_HWMON
 	  a hardware monitoring device will be created for the UFS device.
 
 	  If unsure, say N.
+
+config SCSI_UFS_CRYPTO_TEST
+	bool "UFS crypto keyslot remapping test module"
+	depends on SCSI_UFS_CRYPTO
+	help
+	  This option enables a test implementation of the crypto_keyslot_remap
+	  variant operation to demonstrate how platform-specific keyslot remapping
+	  can be used for multi-domain inline encryption (e.g., VM or security
+	  domain isolation).
+
+	  The test module registers a dummy variant ops that shifts the keyslot
+	  by a fixed offset (e.g., +8), simulating a secondary domain.
+
+	  This is for testing and demonstration only. Say Y or M if you want to
+	  verify the remapping hook works end-to-end.
+
+	  If unsure, say N.
diff --git a/drivers/ufs/core/Makefile b/drivers/ufs/core/Makefile
index cf820fa09a04..cf85fee26afb 100644
--- a/drivers/ufs/core/Makefile
+++ b/drivers/ufs/core/Makefile
@@ -7,3 +7,4 @@ ufshcd-core-$(CONFIG_SCSI_UFS_BSG)	+= ufs_bsg.o
 ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO)	+= ufshcd-crypto.o
 ufshcd-core-$(CONFIG_SCSI_UFS_FAULT_INJECTION) += ufs-fault-injection.o
 ufshcd-core-$(CONFIG_SCSI_UFS_HWMON)	+= ufs-hwmon.o
+ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO_TEST) += ufshcd-crypto-test.o
diff --git a/drivers/ufs/core/ufshcd-crypto-test.c b/drivers/ufs/core/ufshcd-crypto-test.c
new file mode 100644
index 000000000000..96706a5b3b56
--- /dev/null
+++ b/drivers/ufs/core/ufshcd-crypto-test.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2025 Samsung Electronics Co., Ltd.
+ */
+
+#include <ufs/ufshcd.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#ifdef CONFIG_SCSI_UFS_CRYPTO_TEST
+
+static void ufs_crypto_test_keyslot_remap(struct ufs_hba *hba,
+										  struct ufshcd_lrb *lrbp)
+{
+	/*
+	 * Simulate a platform that uses non-zero keyslot base for certain domains.
+	 * For example:
+	 *   - Domain 0: keyslots [0–7]
+	 *   - Domain 1: keyslots [8–15]
+	 *
+	 * This is done by adding a fixed offset to the logical keyslot.
+	 *
+	 * In real platforms, this offset might depend on VM ID, security level,
+	 * or other runtime context.
+	 */
+	const int keyslot_offset = 8;
+
+	if (lrbp->crypto_key_slot >= 0) {
+		lrbp->crypto_key_slot += keyslot_offset;
+		pr_debug("remapped keyslot %d -> %d\n",
+				 lrbp->crypto_key_slot - keyslot_offset,
+				 lrbp->crypto_key_slot);
+	}
+}
+
+static struct ufs_hba_variant_ops ufs_crypto_test_variant_ops = {
+	.name = "ufs-crypto-test",
+	.crypto_keyslot_remap = ufs_crypto_test_keyslot_remap,
+};
+
+/* Only register if no platform ops are already set (for test purposes) */
+static int ufs_crypto_test_probe(struct platform_device *pdev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(&pdev->dev);
+
+	if (!hba) {
+		dev_err(&pdev->dev, "no UFS HBA found\n");
+		return -ENODEV;
+	}
+
+	if (hba->vops) {
+		dev_info(&pdev->dev,
+			"HBA already has variant ops (%s), not registering test ops\n",
+			hba->vops->name);
+		return -EBUSY;
+	}
+
+	hba->vops = &ufs_crypto_test_variant_ops;
+	dev_info(&pdev->dev, "registered crypto_keyslot_remap test hook\n");
+
+	return 0;
+}
+
+static void ufs_crypto_test_remove(struct platform_device *pdev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(&pdev->dev);
+
+	if (hba && hba->vops == &ufs_crypto_test_variant_ops) {
+		pr_info("unregistered crypto_keyslot_remap test hook\n");
+		hba->vops = NULL;
+	}
+}
+
+static struct platform_driver ufs_crypto_test_plat_drv = {
+	.probe = ufs_crypto_test_probe,
+	.remove = ufs_crypto_test_remove,
+	.driver = {
+		.name = "ufs-crypto-test",
+		.owner = THIS_MODULE,
+	},
+};
+
+module_platform_driver(ufs_crypto_test_plat_drv);
+
+MODULE_AUTHOR("Zheng Gong <zheng.gong@samsung.com>");
+MODULE_DESCRIPTION("UFS Crypto Keyslot Remapping Test Module");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:ufs-crypto-test");
+
+#endif /* CONFIG_SCSI_UFS_CRYPTO_TEST */
\ No newline at end of file
-- 
2.50.1

Re: [PATCH v2 0/2] scsi: ufs: Add crypto_keyslot_remap support

[Eric Biggers]

On Thu, Nov 27, 2025 at 03:06:57PM +0800, zheng.gong wrote:
> This patch series adds support for platform-specific crypto keyslot remapping
> in the UFS host driver, enabling secure inline encryption in multi-domain
> environments (e.g., VMs).
> 
> The first patch introduces a new variant operation:
>   ufs_hba_variant_ops::crypto_keyslot_remap
> which allows platforms to adjust the keyslot index at request submission time.
> 
> The second patch adds a test module (CONFIG_SCSI_UFS_CRYPTO_TEST) to
> demonstrate how the new hook is used — by applying a fixed offset to simulate
> domain-specific keyslot layout. This patch series is in response to feedback from Eric on the v1 submission,
> where he noted that the new callback needed to be used to make sense. Just a demonstration
> of the new callback is included in this patch series.

There has to be a real user, not just a useless example module.

Perhaps you intend for this functionality to be used in ufs-exynos.c?
But you haven't sent any corresponding patch.

- Eric

[PATCH v3 0/1] scsi: ufs: Add crypto_keyslot_remap variant op

[zheng.gong]

Thank you very much for your feedback, Eric. I truly appreciate your review and the time you've taken to point out that a real user is required.
You're right. Adding a new variant op without a clear use case would not be acceptable. Let me clarify the context behind this patch.

This hook is not theoretical. It is designed to replace an existing out-of-tree variant op (`crypto_keyslot_cfg`) used in Samsung's ExynosAuto UFS driver for multi-VM inline encryption.
In production, each VM has its own keyslot range per hardware allocation, and the keyslot is remapped at request time:

    lrbp->crypto_key_slot += vm_id * UFS_KEYSLOTS;

This was already in use on automotive platforms.

But the reason this usage isn't visible in mainline is due to ExynosAuto's kernel architecture:

Starting from kernel 6.1, we adopt the dual-repository model (similar to Android Common Kernel):
- `kernel.git`: Mainline-based, minimal patches
- `exynosauto-modules.git`: Hosts platform-specific drivers (as .ko or built-in)

Our UFS driver, including FMP and IOV support, resides in `exynosauto-modules/drivers/ufs/*`. It couldnot be upstreamed due to:
- Hardware-specific SMC calls
- Security-specific key management
- Non-public register interfaces

Despite this, we aim to minimize out-of-tree divergence by upstreaming reusable hooks like this one.

Purpose of the Patch
This change:
- Replaces the private `crypto_keyslot_cfg` with a clean, upstreamable interface
- Eliminates the need for out-of-tree patching
- Reduces rebase effort across kernel versions
- Maintains backward compatibility (no impact if not implemented)

Design Principles
- Minimal: only adds one callback
- Reusable: fits existing `variant_ops` model
- Non-intrusive: no changes to core crypto logic
- Generic: can support virtualization, multi-domain, or security-isolated keyslots

While `ufs-exynosauto.c` is separate from mainline `ufs-exynos.c`, they share the same goal: enabling robust UFS support on Exynos platforms. This hook benefits not only us, but potentially other vendors with similar scenrios.
I'm fully open to feedback. If there are concerns about naming, placement, or future-proofing, i`m happy to adjust.

Thank you again for your guidance. I hope this explanation helps bridge the context gap while supporting real-world use cases.

Changes since v2:
  - Removed test module (ufshcd-crypto-test.c) per feedback
  - Clarified that this hook replaces an existing out-of-tree feature

zheng.gong (1):
  scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

 drivers/ufs/core/ufshcd-crypto.h | 10 ++++++++--
 drivers/ufs/core/ufshcd.c        |  9 +++++----
 include/ufs/ufshcd.h             |  6 ++++++
 3 files changed, 19 insertions(+), 6 deletions(-)

-- 
2.50.1

[PATCH v3 1/1] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

[zheng.gong]

Add a new variant operation crypto_keyslot_remap to allow platform-specific
remapping of crypto keyslot indices before sending requests to the UFS
controller. This is required on platforms that partition the UFS crypto
engine's keyslots among multiple domains (e.g.virtual machines),
where each domain has a keyslot offset.

To support this, pass the UFS HBA pointer to ufshcd_prepare_lrbp_crypto(),
so the callback can access platform context.

This functionality is used on Samsung ExynosAuto UFS platforms, where
keyslot allocation is per-VM and a runtime offset is applied based on
the VM ID.

Signed-off-by: zheng.gong <zheng.gong@samsung.com>
---
 drivers/ufs/core/ufshcd-crypto.h | 10 ++++++++--
 drivers/ufs/core/ufshcd.c        |  9 +++++----
 include/ufs/ufshcd.h             |  6 ++++++
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/ufs/core/ufshcd-crypto.h b/drivers/ufs/core/ufshcd-crypto.h
index 89bb97c14c15..6dcba6817590 100644
--- a/drivers/ufs/core/ufshcd-crypto.h
+++ b/drivers/ufs/core/ufshcd-crypto.h
@@ -13,7 +13,8 @@
 
 #ifdef CONFIG_SCSI_UFS_CRYPTO
 
-static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
+static inline void ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
+					      struct request *rq,
 					      struct ufshcd_lrb *lrbp)
 {
 	if (!rq || !rq->crypt_keyslot) {
@@ -22,6 +23,10 @@ static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
 	}
 
 	lrbp->crypto_key_slot = blk_crypto_keyslot_index(rq->crypt_keyslot);
+
+	if (hba && hba->vops && hba->vops->crypto_keyslot_remap)
+		return hba->vops->crypto_keyslot_remap(hba, lrbp);
+
 	lrbp->data_unit_num = rq->crypt_ctx->bc_dun[0];
 }
 
@@ -74,7 +79,8 @@ void ufshcd_crypto_register(struct ufs_hba *hba, struct request_queue *q);
 
 #else /* CONFIG_SCSI_UFS_CRYPTO */
 
-static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
+static inline void ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
+					      struct request *rq,
 					      struct ufshcd_lrb *lrbp) { }
 
 static inline void
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 8339fec975b9..7417c6bec81a 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -2902,20 +2902,21 @@ static void ufshcd_comp_scsi_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 	ufshcd_prepare_utp_scsi_cmd_upiu(lrbp, upiu_flags);
 }
 
-static void __ufshcd_setup_cmd(struct ufshcd_lrb *lrbp, struct scsi_cmnd *cmd, u8 lun, int tag)
+static void __ufshcd_setup_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
+				  struct scsi_cmnd *cmd, u8 lun, int tag)
 {
 	memset(lrbp->ucd_req_ptr, 0, sizeof(*lrbp->ucd_req_ptr));
 
 	lrbp->cmd = cmd;
 	lrbp->task_tag = tag;
 	lrbp->lun = lun;
-	ufshcd_prepare_lrbp_crypto(cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
+	ufshcd_prepare_lrbp_crypto(hba, cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
 }
 
 static void ufshcd_setup_scsi_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
 				  struct scsi_cmnd *cmd, u8 lun, int tag)
 {
-	__ufshcd_setup_cmd(lrbp, cmd, lun, tag);
+	__ufshcd_setup_cmd(hba, lrbp, cmd, lun, tag);
 	lrbp->intr_cmd = !ufshcd_is_intr_aggr_allowed(hba);
 	lrbp->req_abort_skip = false;
 
@@ -3083,7 +3084,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
 static void ufshcd_setup_dev_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
 			     enum dev_cmd_type cmd_type, u8 lun, int tag)
 {
-	__ufshcd_setup_cmd(lrbp, NULL, lun, tag);
+	__ufshcd_setup_cmd(hba, lrbp, NULL, lun, tag);
 	lrbp->intr_cmd = true; /* No interrupt aggregation */
 	hba->dev_cmd.type = cmd_type;
 }
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 9425cfd9d00e..86b7bcc1da33 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -336,6 +336,10 @@ struct ufs_pwr_mode_info {
  * @config_esi: called to config Event Specific Interrupt
  * @config_scsi_dev: called to configure SCSI device parameters
  * @freq_to_gear_speed: called to map clock frequency to the max supported gear speed
+ * @crypto_keyslot_remap: called to adjust the keyslot index before sending
+ *	a request to the UFS controller. This allows the platform to apply a
+ *	hardware-specific keyslot offset or other mapping logic to determine
+ *	the correct keyslot for inline encryption.
  */
 struct ufs_hba_variant_ops {
 	const char *name;
@@ -385,6 +389,8 @@ struct ufs_hba_variant_ops {
 	int	(*config_esi)(struct ufs_hba *hba);
 	void	(*config_scsi_dev)(struct scsi_device *sdev);
 	u32	(*freq_to_gear_speed)(struct ufs_hba *hba, unsigned long freq);
+	void	(*crypto_keyslot_remap)(struct ufs_hba *hba,
+						struct ufshcd_lrb *lrbp);
 };
 
 /* clock gating state  */
-- 
2.50.1

Re: [PATCH v3 0/1] scsi: ufs: Add crypto_keyslot_remap variant op

[Eric Biggers]

On Fri, Nov 28, 2025 at 11:37:08AM +0800, zheng.gong wrote:
> Thank you very much for your feedback, Eric. I truly appreciate your review and the time you've taken to point out that a real user is required.
> You're right. Adding a new variant op without a clear use case would not be acceptable. Let me clarify the context behind this patch.

To clarify, there has to be an in-tree user.

> This hook is not theoretical. It is designed to replace an existing out-of-tree variant op (`crypto_keyslot_cfg`) used in Samsung's ExynosAuto UFS driver for multi-VM inline encryption.
> In production, each VM has its own keyslot range per hardware allocation, and the keyslot is remapped at request time:
> 
>     lrbp->crypto_key_slot += vm_id * UFS_KEYSLOTS;
> 
> This was already in use on automotive platforms.
> 
> But the reason this usage isn't visible in mainline is due to ExynosAuto's kernel architecture:
> 
> Starting from kernel 6.1, we adopt the dual-repository model (similar to Android Common Kernel):
> - `kernel.git`: Mainline-based, minimal patches
> - `exynosauto-modules.git`: Hosts platform-specific drivers (as .ko or built-in)
> 
> Our UFS driver, including FMP and IOV support, resides in `exynosauto-modules/drivers/ufs/*`. It couldnot be upstreamed due to:
> - Hardware-specific SMC calls
> - Security-specific key management
> - Non-public register interfaces

The upstream driver is drivers/ufs/host/ufs-exynos.c, so you'll need to
focus on adding this functionality to there, if it's actually needed.
What's happening downstream is irrelevant.

- Eric

[PATCH v4 0/3] scsi: ufs: Add crypto_keyslot_remap support

[zheng.gong]

Hello Eric,

Sorry for late due to other affairs.

Readjuest the patchset adds support for platform-specific crypto keyslot
remapping in the exynos UFS host driver.

The 1st patch raise a new variant op:
  ufs_hba_variant_ops::crypto_keyslot_remap
which allows platforms to adjust the keyslot index at io request period.

The 2nd patch adds a real, upstream user in ufs-exynos.c that supports
remapping via device tree. This makes the hook justifiable for mainline
inclusion.

The 3rd patch adds DT binding description for the new property
'ufs-keyslot-offset'.

zheng.gong (3):
  scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap
  scsi: ufs: exynos: Support crypto keyslot remapping via DT
  dt-bindings: ufs: Add binding for ufs-keyslot-offset

 .../bindings/ufs/samsung,exynos-ufs.yaml         |  5 +++++
 drivers/ufs/core/ufshcd-crypto.h                 | 10 ++++++++--
 drivers/ufs/core/ufshcd.c                        |  9 +++++----
 drivers/ufs/host/ufs-exynos.c                    | 16 ++++++++++++++++
 include/ufs/ufshcd.h                             |  6 ++++++
 5 files changed, 40 insertions(+), 6 deletions(-)

-- 
2.50.1

[PATCH v4 1/3] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

[zheng.gong]

Add a new variant operation crypto_keyslot_remap to allow platform-specific
remapping of crypto keyslot indices before sending requests to the UFS
controller. This is required on platforms that partition the UFS crypto
engine's keyslots among multiple domains (e.g.virtual machines),
where each domain has a keyslot offset.

To support this, pass the UFS HBA pointer to ufshcd_prepare_lrbp_crypto(),
so the callback can access platform context.

This functionality is used on Samsung ExynosAuto UFS platforms, where
keyslot allocation is per-VM and a runtime offset is applied based on
the VM ID.

Signed-off-by: zheng.gong <zheng.gong@samsung.com>
---
 drivers/ufs/core/ufshcd-crypto.h | 10 ++++++++--
 drivers/ufs/core/ufshcd.c        |  9 +++++----
 include/ufs/ufshcd.h             |  6 ++++++
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/ufs/core/ufshcd-crypto.h b/drivers/ufs/core/ufshcd-crypto.h
index 89bb97c14c15..6dcba6817590 100644
--- a/drivers/ufs/core/ufshcd-crypto.h
+++ b/drivers/ufs/core/ufshcd-crypto.h
@@ -13,7 +13,8 @@
 
 #ifdef CONFIG_SCSI_UFS_CRYPTO
 
-static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
+static inline void ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
+					      struct request *rq,
 					      struct ufshcd_lrb *lrbp)
 {
 	if (!rq || !rq->crypt_keyslot) {
@@ -22,6 +23,10 @@ static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
 	}
 
 	lrbp->crypto_key_slot = blk_crypto_keyslot_index(rq->crypt_keyslot);
+
+	if (hba && hba->vops && hba->vops->crypto_keyslot_remap)
+		return hba->vops->crypto_keyslot_remap(hba, lrbp);
+
 	lrbp->data_unit_num = rq->crypt_ctx->bc_dun[0];
 }
 
@@ -74,7 +79,8 @@ void ufshcd_crypto_register(struct ufs_hba *hba, struct request_queue *q);
 
 #else /* CONFIG_SCSI_UFS_CRYPTO */
 
-static inline void ufshcd_prepare_lrbp_crypto(struct request *rq,
+static inline void ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba,
+					      struct request *rq,
 					      struct ufshcd_lrb *lrbp) { }
 
 static inline void
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 8339fec975b9..7417c6bec81a 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -2902,20 +2902,21 @@ static void ufshcd_comp_scsi_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 	ufshcd_prepare_utp_scsi_cmd_upiu(lrbp, upiu_flags);
 }
 
-static void __ufshcd_setup_cmd(struct ufshcd_lrb *lrbp, struct scsi_cmnd *cmd, u8 lun, int tag)
+static void __ufshcd_setup_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
+				  struct scsi_cmnd *cmd, u8 lun, int tag)
 {
 	memset(lrbp->ucd_req_ptr, 0, sizeof(*lrbp->ucd_req_ptr));
 
 	lrbp->cmd = cmd;
 	lrbp->task_tag = tag;
 	lrbp->lun = lun;
-	ufshcd_prepare_lrbp_crypto(cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
+	ufshcd_prepare_lrbp_crypto(hba, cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
 }
 
 static void ufshcd_setup_scsi_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
 				  struct scsi_cmnd *cmd, u8 lun, int tag)
 {
-	__ufshcd_setup_cmd(lrbp, cmd, lun, tag);
+	__ufshcd_setup_cmd(hba, lrbp, cmd, lun, tag);
 	lrbp->intr_cmd = !ufshcd_is_intr_aggr_allowed(hba);
 	lrbp->req_abort_skip = false;
 
@@ -3083,7 +3084,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
 static void ufshcd_setup_dev_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
 			     enum dev_cmd_type cmd_type, u8 lun, int tag)
 {
-	__ufshcd_setup_cmd(lrbp, NULL, lun, tag);
+	__ufshcd_setup_cmd(hba, lrbp, NULL, lun, tag);
 	lrbp->intr_cmd = true; /* No interrupt aggregation */
 	hba->dev_cmd.type = cmd_type;
 }
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 9425cfd9d00e..86b7bcc1da33 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -336,6 +336,10 @@ struct ufs_pwr_mode_info {
  * @config_esi: called to config Event Specific Interrupt
  * @config_scsi_dev: called to configure SCSI device parameters
  * @freq_to_gear_speed: called to map clock frequency to the max supported gear speed
+ * @crypto_keyslot_remap: called to adjust the keyslot index before sending
+ *	a request to the UFS controller. This allows the platform to apply a
+ *	hardware-specific keyslot offset or other mapping logic to determine
+ *	the correct keyslot for inline encryption.
  */
 struct ufs_hba_variant_ops {
 	const char *name;
@@ -385,6 +389,8 @@ struct ufs_hba_variant_ops {
 	int	(*config_esi)(struct ufs_hba *hba);
 	void	(*config_scsi_dev)(struct scsi_device *sdev);
 	u32	(*freq_to_gear_speed)(struct ufs_hba *hba, unsigned long freq);
+	void	(*crypto_keyslot_remap)(struct ufs_hba *hba,
+						struct ufshcd_lrb *lrbp);
 };
 
 /* clock gating state  */
-- 
2.50.1

Re: [PATCH v4 1/3] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

[Bart Van Assche]

On 1/28/26 7:10 PM, zheng.gong wrote:
> +static void __ufshcd_setup_cmd(struct ufs_hba *hba, struct ufshcd_lrb *lrbp,
> +				  struct scsi_cmnd *cmd, u8 lun, int tag)
>   {
>   	memset(lrbp->ucd_req_ptr, 0, sizeof(*lrbp->ucd_req_ptr));
>   
>   	lrbp->cmd = cmd;
>   	lrbp->task_tag = tag;
>   	lrbp->lun = lun;
> -	ufshcd_prepare_lrbp_crypto(cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
> +	ufshcd_prepare_lrbp_crypto(hba, cmd ? scsi_cmd_to_rq(cmd) : NULL, lrbp);
>   }

lrbp->cmd has been removed recently. Please use Martin's staging branch 
when preparing patches for the upstream kernel.

Bart.

[PATCH v4 2/3] scsi: ufs: exynos: Support crypto keyslot remapping via DT

[zheng.gong]

Add support for crypto keyslot remapping in the exynos UFS driver using
the device tree property 'ufs-keyslot-offset'.

This allows platforms to apply a fixed offset to the logical keyslot,
enabling secure inline encryption in virtualized or multi-domain
environments.

The implementation is generic and optional which only active if the DT
property is present.

Signed-off-by: zheng.gong <zheng.gong@samsung.com>
---
 drivers/ufs/host/ufs-exynos.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c
index 70d195179eba..dc63900ebbee 100644
--- a/drivers/ufs/host/ufs-exynos.c
+++ b/drivers/ufs/host/ufs-exynos.c
@@ -1437,6 +1437,19 @@ static int exynos_ufs_fmp_fill_prdt(struct ufs_hba *hba,
 	return 0;
 }
 
+static void exynos_ufs_fmp_crypto_keyslot_remap(struct ufs_hba *hba,
+				    struct ufshcd_lrb *lrbp)
+{
+	struct device_node *np = hba->dev->of_node;
+	u32 offset;
+
+	/* If dt property is not present, use identity mapping still.*/
+	if (of_property_read_u32(np, "ufs-keyslot-offset", &offset) == 0) {
+		if (lrbp->crypto_key_slot >= 0)
+			lrbp->crypto_key_slot += offset;
+	}
+}
+
 #else /* CONFIG_SCSI_UFS_CRYPTO */
 
 static void exynos_ufs_fmp_init(struct ufs_hba *hba, struct exynos_ufs *ufs)
@@ -1449,6 +1462,8 @@ static void exynos_ufs_fmp_resume(struct ufs_hba *hba)
 
 #define exynos_ufs_fmp_fill_prdt NULL
 
+#define exynos_ufs_fmp_crypto_keyslot_remap NULL
+
 #endif /* !CONFIG_SCSI_UFS_CRYPTO */
 
 static int exynos_ufs_init(struct ufs_hba *hba)
@@ -2013,6 +2028,7 @@ static const struct ufs_hba_variant_ops ufs_hba_exynos_ops = {
 	.suspend			= exynos_ufs_suspend,
 	.resume				= exynos_ufs_resume,
 	.fill_crypto_prdt		= exynos_ufs_fmp_fill_prdt,
+	.crypto_keyslot_remap = exynos_ufs_fmp_crypto_keyslot_remap,
 };
 
 static struct ufs_hba_variant_ops ufs_hba_exynosauto_vh_ops = {
-- 
2.50.1

[PATCH v4 3/3] dt-bindings: ufs: Add binding for ufs-keyslot-offset

[zheng.gong]

Document the new 'ufs-keyslot-offset' dt property used to configure
a fixed offset for crypto keyslot remapping in UFS host controllers.

This is useful in virtualized or multi-domain environments where keyslot
layout is partitioned (e.g., per-VM isolation). If the property is not
present, the keyslot is used as-is (identity mapping).

The binding is used by the exynos UFS driver to support secure inline
encryption in domain-isolated scenarios.

Signed-off-by: zheng.gong <zheng.gong@samsung.com>
---
 .../devicetree/bindings/ufs/samsung,exynos-ufs.yaml          | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
index b4e744ebffd1..0ed60bbd959e 100644
--- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
@@ -72,6 +72,11 @@ properties:
 
   dma-coherent: true
 
+  ufs-keyslot-offset:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Offset added to logical crypto keyslot for multi-domain isolation.
+
 required:
   - compatible
   - reg
-- 
2.50.1

Re: [PATCH v4 0/3] scsi: ufs: Add crypto_keyslot_remap support

[Eric Biggers]

On Thu, Jan 29, 2026 at 11:10:30AM +0800, zheng.gong wrote:
> Hello Eric,
> 
> Sorry for late due to other affairs.
> 
> Readjuest the patchset adds support for platform-specific crypto keyslot
> remapping in the exynos UFS host driver.
> 
> The 1st patch raise a new variant op:
>   ufs_hba_variant_ops::crypto_keyslot_remap
> which allows platforms to adjust the keyslot index at io request period.
> 
> The 2nd patch adds a real, upstream user in ufs-exynos.c that supports
> remapping via device tree. This makes the hook justifiable for mainline
> inclusion.
> 
> The 3rd patch adds DT binding description for the new property
> 'ufs-keyslot-offset'.

I don't think it's plausible that this actually works, considering that
ufs-exynos.c installs a custom blk_crypto_profile that doesn't have any
keyslots.  (It does that because the Exynos UFS host controller takes
the raw key directly in the PRDT on a per-block basis.)  With no
keyslots, the concept of remapping them is meaningless.

Could you clarify what exactly this patchset is meant to do, and how you
tested it?

Do you perhaps have additional patches that this depends on?  Perhaps
patches that add support for a version of the Exynos UFS host controller
that does have keyslots?

- Eric

Re:Re: [PATCH v4 0/3] scsi: ufs: Add crypto_keyslot_remap support

[zheng.gong]

Hi Eric,

Thank you for ur kind question. I understand your concern.
the confusion arises from the coexistence of two different UFS drivers on Exynos platforms.

There are two distinct UFS host controller implementations on Samsung Exynos:
- ufs-exynos.c
- ufs-exynosautovX.c

But ufs-exynosautovX is not mainlined, which:
- Uses a hardware crypto engine that does support keyslots
- Assigns keyslots to VMs (e.g., QNX, Linux, Android)
- Needs to remap logical keyslot + VM-specific offset at request time

We added a minimal, DT-based remap in ufs-exynos.c not because mobile uses it, but to:
- Prove that the hook has a real, upstream-mergeable use pattern
- Show that the mechanism can be used by actual platform

It is a generic, not tied to one usecase.

As for how we use it in our platform.

In our driver, we implement as like:

void exynos_ufs_fmp_crypto_keyslot_remap(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
{
    struct exynosauto_ufs *ufs = to_exynosauto_ufs(hba);
    u32 vm_id = ufs->iov->vm_id;
    u32 offset = vm_id * UFS_KEYSLOTS;

    if (lrbp->crypto_key_slot >= 0)
        lrbp->crypto_key_slot += offset;
}

We have tested this on ExynosAuto V920 platform with:
4 virtual machines: QNX, Linux, Linux, Android.
Each VM has its own UFS VH and keyslot range as per allocation.
Inline encryption is enabled for all VMs. offset is configured in dt for each VH node.

Despite driver resides in our out-of-tree exynosauto-modules and cannot be upstreamed easily,
but the use case is real and actively used in production platform.

To help move this forward, could you please let us know what additional 
information or changes would be needed to make this patch acceptable?

If it is not plausible for mainline, do u have any suggestion in terms of this kind of case?

Appreciate it.

Re: Re: [PATCH v4 0/3] scsi: ufs: Add crypto_keyslot_remap support

[Eric Biggers]

On Thu, Jan 29, 2026 at 02:17:58PM +0800, zheng.gong wrote:
> Hi Eric,
> 
> Thank you for ur kind question. I understand your concern.
> the confusion arises from the coexistence of two different UFS drivers on Exynos platforms.
> 
> There are two distinct UFS host controller implementations on Samsung Exynos:
> - ufs-exynos.c
> - ufs-exynosautovX.c
> 
> But ufs-exynosautovX is not mainlined, which:
> - Uses a hardware crypto engine that does support keyslots
> - Assigns keyslots to VMs (e.g., QNX, Linux, Android)
> - Needs to remap logical keyslot + VM-specific offset at request time
> 
> We added a minimal, DT-based remap in ufs-exynos.c not because mobile uses it, but to:
> - Prove that the hook has a real, upstream-mergeable use pattern
> - Show that the mechanism can be used by actual platform
> 
> It is a generic, not tied to one usecase.
> 
> As for how we use it in our platform.
> 
> In our driver, we implement as like:
> 
> void exynos_ufs_fmp_crypto_keyslot_remap(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
> {
>     struct exynosauto_ufs *ufs = to_exynosauto_ufs(hba);
>     u32 vm_id = ufs->iov->vm_id;
>     u32 offset = vm_id * UFS_KEYSLOTS;
> 
>     if (lrbp->crypto_key_slot >= 0)
>         lrbp->crypto_key_slot += offset;
> }
> 
> We have tested this on ExynosAuto V920 platform with:
> 4 virtual machines: QNX, Linux, Linux, Android.
> Each VM has its own UFS VH and keyslot range as per allocation.
> Inline encryption is enabled for all VMs. offset is configured in dt for each VH node.
> 
> Despite driver resides in our out-of-tree exynosauto-modules and cannot be upstreamed easily,
> but the use case is real and actively used in production platform.
> 
> To help move this forward, could you please let us know what additional 
> information or changes would be needed to make this patch acceptable?
> 
> If it is not plausible for mainline, do u have any suggestion in terms of this kind of case?

Well, you should start working on upstreaming support for the platform
that needs this feature.

Until that is done, this patch series won't go anywhere.

- Eric