From: Eric Biggers <ebiggers@kernel.org>
To: "zheng.gong" <zheng.gong@samsung.com>
Cc: linux-scsi@vger.kernel.org, avri.altman@wdc.com,
bvanassche@acm.org, quic_cang@quicinc.com,
alim.akhtar@samsung.com, martin.petersen@oracle.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/1] scsi: ufs: Add crypto_keyslot_remap variant op
Date: Thu, 27 Nov 2025 19:47:36 -0800 [thread overview]
Message-ID: <20251128034736.GA18644@sol> (raw)
In-Reply-To: <20251128033709.1342579-1-zheng.gong@samsung.com>
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
next prev parent reply other threads:[~2025-11-28 3:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20251112030559epcas5p13358e7b05ca6b39688530b9c8178527e@epcas5p1.samsung.com>
[not found] ` <20251112030524.3545394-1-zheng.gong@samsung.com>
2025-11-12 3:05 ` [PATCH 1/1] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap zheng.gong
2025-11-12 3:10 ` Eric Biggers
2025-11-27 7:06 ` [PATCH v2 0/2] scsi: ufs: Add crypto_keyslot_remap support zheng.gong
2025-11-27 7:06 ` [PATCH v2 1/2] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap zheng.gong
2025-11-27 7:06 ` [PATCH v2 2/2] scsi: ufs: Add crypto keyslot remapping test module zheng.gong
2025-11-27 22:24 ` [PATCH v2 0/2] scsi: ufs: Add crypto_keyslot_remap support Eric Biggers
2025-11-28 3:37 ` [PATCH v3 0/1] scsi: ufs: Add crypto_keyslot_remap variant op zheng.gong
2025-11-28 3:37 ` [PATCH v3 1/1] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap zheng.gong
2025-11-28 3:47 ` Eric Biggers [this message]
2026-01-29 3:10 ` [PATCH v4 0/3] scsi: ufs: Add crypto_keyslot_remap support zheng.gong
2026-01-29 3:10 ` [PATCH v4 1/3] scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap zheng.gong
2026-01-29 16:43 ` Bart Van Assche
2026-01-29 3:10 ` [PATCH v4 2/3] scsi: ufs: exynos: Support crypto keyslot remapping via DT zheng.gong
2026-01-29 3:10 ` [PATCH v4 3/3] dt-bindings: ufs: Add binding for ufs-keyslot-offset zheng.gong
2026-01-29 3:31 ` [PATCH v4 0/3] scsi: ufs: Add crypto_keyslot_remap support Eric Biggers
2026-01-29 6:17 ` zheng.gong
2026-01-29 7:42 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251128034736.GA18644@sol \
--to=ebiggers@kernel.org \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=quic_cang@quicinc.com \
--cc=zheng.gong@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.