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

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