Re: [PATCH v4 0/5] ufs: rpmb: route OP-TEE RPMB secure storage over UFS

Re: [PATCH v4 0/5] ufs: rpmb: route OP-TEE RPMB secure storage over UFS

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5563 bytes --]

On Mon, Sep 07, 2026 at 10:40:59AM +0200, Jorge Ramirez wrote:
> On 07/09/26 12:47:39, Neha Malcom Francis wrote:
> > Hi Jorge
> >
> > On 07/09/26 12:38, Jorge Ramirez wrote:
> > > On 27/08/26 11:01:41, Jorge Ramirez wrote:
> > >> On 21/08/26 16:02:18, Jorge Ramirez wrote:
> > >>> On 17/08/26 16:38:40, Jorge Ramirez wrote:
> > >>>> On 07/08/26 16:01:05, Jorge Ramirez-Ortiz wrote:
> > >>>>> OP-TEE secure storage (CFG_RPMB_FS) relies on an RPMB partition, but
> > >>>>> U-Boot's OP-TEE RPMB supplicant only speaks the legacy single-command
> > >>>>> interface, which is bound to eMMC. SoCs that are UFS-only and have no
> > >>>>> eMMC (for example the Qualcomm SA8775P) therefore cannot back OP-TEE
> > >>>>> secure storage from U-Boot today. This series adds that support.
> > >>>>>
> > >>>>> It introduces the transport-agnostic OP-TEE RPMB "subsystem" interface
> > >>>>> (PROBE_RESET / PROBE_NEXT / FRAMES), where the normal world enumerates
> > >>>>> the RPMB device and reports its kind, size and CID, then carries the
> > >>>>> signed frames. The legacy eMMC supplicant is preserved unchanged, only
> > >>>>> renamed to rpmb_emmc.c, with the new UFS backend added as a separate
> > >>>>> rpmb_ufs.c; the two are mutually exclusive via Kconfig (SUPPORT_UFS_RPMB
> > >>>>> depends on !SUPPORT_EMMC_RPMB) because the OP-TEE supplicant handles a
> > >>>>> single RPMB transport. The subsystem interface is UFS-only for now; eMMC
> > >>>>> can be migrated onto it later as the legacy path is retired.
> > >>>>>
> > >>>>> On top of that it adds a UFS RPMB transport that moves JEDEC RPMB frames
> > >>>>> to and from the RPMB Well-Known LUN using SCSI SECURITY PROTOCOL IN/OUT.
> > >>>>> The per-region 16-byte CID is derived by BLAKE2b-hashing the exact
> > >>>>> device-id string the Linux kernel builds (ufshcd_create_device_id()
> > >>>>> plus a "-R<region>" suffix), so OP-TEE derives an RPMB key that matches
> > >>>>> the one Linux would use.
> > >>>>>
> > >>>>> The first patch is a standalone UFS descriptor fix the RPMB path depends
> > >>>>> on (UTF-16BE string decoding); the transport patches also include a
> > >>>>> power-on UNIT ATTENTION retry and a DMA-alignment bounce for the RPMB
> > >>>>> WLUN.
> > >>>>>
> > >>>>> Note: reading UFS descriptors reliably also requires the descriptor
> > >>>>> data-segment cache-invalidation fix, which has already been posted and
> > >>>>> merged separately, so this series is based on top of it.
> > >>>>>
> > >>>>> Tested on the Qualcomm IQ-9075-EVK (SA8775P): OP-TEE with CFG_RPMB_FS
> > >>>>> programs the RPMB key through U-Boot and reads/writes secure-storage
> > >>>>> objects, with the derived CID matching the Linux UFS device_id ABI.
> > >>>>>
> > >>>>> Dependencies:
> > >>>>> Linux kernel:
> > >>>>>  https://lore.kernel.org/linux-scsi/20260716083728.2226422-1-jorge.ramirez@oss.qualcomm.com/
> > >>>>> Op-tee
> > >>>>>  https://github.com/OP-TEE/optee_os/pull/7881
> > >>>>>
> > >>>>> v4:
> > >>>>>  - ufs: decode string descriptors: dropped the in-place
> > >>>>>    ufshcd_str_desc_to_cpu() byte-swap helper; instead added an endian
> > >>>>>    argument to utf16_to_utf8() (UTF16_HOST/LITTLE/BIG_ENDIAN) and decode
> > >>>>>    with UTF16_BIG_ENDIAN, mirroring the kernel's utf16s_to_utf8s().
> > >>>>>    Existing EFI callers pass UTF16_HOST_ENDIAN.
> > >>>>>  - ufs: RPMB transport: build the SECURITY PROTOCOL CDB with
> > >>>>>    put_unaligned_be16()/put_unaligned_be32(); drop the
> > >>>>>    rpmb_frame_request() helper in favour of get_unaligned_be16(); move
> > >>>>>    ufs_rpmb_read_geometry() to the patch that first uses it so it is not
> > >>>>>    an unused static function during git bisect.
> > >>>>>  - ufs: per-region CID/size: reject an out-of-range device-reported
> > >>>>>    logical block size before shifting and split the size computation into
> > >>>>>    separate statements for readability; order <u-boot/...> after
> > >>>>>    <linux/...>; note that the serial hex encoding matches the kernel
> > >>>>>    device-id ABI.
> > >>>>>
> > >>>>
> > >>>> any further comments, is it ok to merge?
> > >>>>
> > >>>
> > >>> EOW reminder - this has been pending for a long while
> > >>
> > >>
> > >> anyone care to comment please?
> > >
> > >
> > > kernel changes accepted and op-tee changes merged.
> > > Just this one pending with no comments for nearly a month.
> > >
> > > maybe we can merge?
> > >
> > > thanks
> > > Jorge
> > >
> > >
> > >
> >
> > Looks like you're sending to the old mailing list instead of
> > u-boot@lists.u-boot-project.org
> >
> 
> hi Neah,
> 
> ah interesting, maybe that explains it depending on people'w workflows: I see it hasnt landed on u-boot lore's.
> 
> I just run get_maintainers.pl and the recommended list is
> 
> jramirez@trex:u-boot (ufs-rpmb.v4 $) $ ./scripts/get_maintainer.pl drivers/tee/optee/Makefile
> Jens Wiklander <jens.wiklander@linaro.org> (maintainer:TEE)
> Ilias Apalodimas <ilias.apalodimas@linaro.org> (maintainer:TEE,commit_signer:2/3=67%)
> Tom Rini <trini@konsulko.com> (maintainer:THE REST,authored:1/3=33%,added_lines:1/3=33%,removed_lines:1/2=50%)
> Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> (commit_signer:2/3=67%,authored:2/3=67%,added_lines:2/3=67%,removed_lines:1/2=50%)
> u-boot@lists.denx.de (open list)...
> 
> still I can see it on patchworks with Neil being the gatekeeper.

Is your tree out of date? That's not what it shows here, we updated that
a while ago.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 0/5] ufs: rpmb: route OP-TEE RPMB secure storage over UFS

[Jorge Ramirez]

On 07/09/26 10:13:39, Tom Rini wrote:
> On Mon, Sep 07, 2026 at 10:40:59AM +0200, Jorge Ramirez wrote:
> > On 07/09/26 12:47:39, Neha Malcom Francis wrote:
> > > Hi Jorge
> > >
> > > On 07/09/26 12:38, Jorge Ramirez wrote:
> > > > On 27/08/26 11:01:41, Jorge Ramirez wrote:
> > > >> On 21/08/26 16:02:18, Jorge Ramirez wrote:
> > > >>> On 17/08/26 16:38:40, Jorge Ramirez wrote:
> > > >>>> On 07/08/26 16:01:05, Jorge Ramirez-Ortiz wrote:
> > > >>>>> OP-TEE secure storage (CFG_RPMB_FS) relies on an RPMB partition, but
> > > >>>>> U-Boot's OP-TEE RPMB supplicant only speaks the legacy single-command
> > > >>>>> interface, which is bound to eMMC. SoCs that are UFS-only and have no
> > > >>>>> eMMC (for example the Qualcomm SA8775P) therefore cannot back OP-TEE
> > > >>>>> secure storage from U-Boot today. This series adds that support.
> > > >>>>>
> > > >>>>> It introduces the transport-agnostic OP-TEE RPMB "subsystem" interface
> > > >>>>> (PROBE_RESET / PROBE_NEXT / FRAMES), where the normal world enumerates
> > > >>>>> the RPMB device and reports its kind, size and CID, then carries the
> > > >>>>> signed frames. The legacy eMMC supplicant is preserved unchanged, only
> > > >>>>> renamed to rpmb_emmc.c, with the new UFS backend added as a separate
> > > >>>>> rpmb_ufs.c; the two are mutually exclusive via Kconfig (SUPPORT_UFS_RPMB
> > > >>>>> depends on !SUPPORT_EMMC_RPMB) because the OP-TEE supplicant handles a
> > > >>>>> single RPMB transport. The subsystem interface is UFS-only for now; eMMC
> > > >>>>> can be migrated onto it later as the legacy path is retired.
> > > >>>>>
> > > >>>>> On top of that it adds a UFS RPMB transport that moves JEDEC RPMB frames
> > > >>>>> to and from the RPMB Well-Known LUN using SCSI SECURITY PROTOCOL IN/OUT.
> > > >>>>> The per-region 16-byte CID is derived by BLAKE2b-hashing the exact
> > > >>>>> device-id string the Linux kernel builds (ufshcd_create_device_id()
> > > >>>>> plus a "-R<region>" suffix), so OP-TEE derives an RPMB key that matches
> > > >>>>> the one Linux would use.
> > > >>>>>
> > > >>>>> The first patch is a standalone UFS descriptor fix the RPMB path depends
> > > >>>>> on (UTF-16BE string decoding); the transport patches also include a
> > > >>>>> power-on UNIT ATTENTION retry and a DMA-alignment bounce for the RPMB
> > > >>>>> WLUN.
> > > >>>>>
> > > >>>>> Note: reading UFS descriptors reliably also requires the descriptor
> > > >>>>> data-segment cache-invalidation fix, which has already been posted and
> > > >>>>> merged separately, so this series is based on top of it.
> > > >>>>>
> > > >>>>> Tested on the Qualcomm IQ-9075-EVK (SA8775P): OP-TEE with CFG_RPMB_FS
> > > >>>>> programs the RPMB key through U-Boot and reads/writes secure-storage
> > > >>>>> objects, with the derived CID matching the Linux UFS device_id ABI.
> > > >>>>>
> > > >>>>> Dependencies:
> > > >>>>> Linux kernel:
> > > >>>>>  https://lore.kernel.org/linux-scsi/20260716083728.2226422-1-jorge.ramirez@oss.qualcomm.com/
> > > >>>>> Op-tee
> > > >>>>>  https://github.com/OP-TEE/optee_os/pull/7881
> > > >>>>>
> > > >>>>> v4:
> > > >>>>>  - ufs: decode string descriptors: dropped the in-place
> > > >>>>>    ufshcd_str_desc_to_cpu() byte-swap helper; instead added an endian
> > > >>>>>    argument to utf16_to_utf8() (UTF16_HOST/LITTLE/BIG_ENDIAN) and decode
> > > >>>>>    with UTF16_BIG_ENDIAN, mirroring the kernel's utf16s_to_utf8s().
> > > >>>>>    Existing EFI callers pass UTF16_HOST_ENDIAN.
> > > >>>>>  - ufs: RPMB transport: build the SECURITY PROTOCOL CDB with
> > > >>>>>    put_unaligned_be16()/put_unaligned_be32(); drop the
> > > >>>>>    rpmb_frame_request() helper in favour of get_unaligned_be16(); move
> > > >>>>>    ufs_rpmb_read_geometry() to the patch that first uses it so it is not
> > > >>>>>    an unused static function during git bisect.
> > > >>>>>  - ufs: per-region CID/size: reject an out-of-range device-reported
> > > >>>>>    logical block size before shifting and split the size computation into
> > > >>>>>    separate statements for readability; order <u-boot/...> after
> > > >>>>>    <linux/...>; note that the serial hex encoding matches the kernel
> > > >>>>>    device-id ABI.
> > > >>>>>
> > > >>>>
> > > >>>> any further comments, is it ok to merge?
> > > >>>>
> > > >>>
> > > >>> EOW reminder - this has been pending for a long while
> > > >>
> > > >>
> > > >> anyone care to comment please?
> > > >
> > > >
> > > > kernel changes accepted and op-tee changes merged.
> > > > Just this one pending with no comments for nearly a month.
> > > >
> > > > maybe we can merge?
> > > >
> > > > thanks
> > > > Jorge
> > > >
> > > >
> > > >
> > >
> > > Looks like you're sending to the old mailing list instead of
> > > u-boot@lists.u-boot-project.org
> > >
> > 
> > hi Neah,
> > 
> > ah interesting, maybe that explains it depending on people'w workflows: I see it hasnt landed on u-boot lore's.
> > 
> > I just run get_maintainers.pl and the recommended list is
> > 
> > jramirez@trex:u-boot (ufs-rpmb.v4 $) $ ./scripts/get_maintainer.pl drivers/tee/optee/Makefile
> > Jens Wiklander <jens.wiklander@linaro.org> (maintainer:TEE)
> > Ilias Apalodimas <ilias.apalodimas@linaro.org> (maintainer:TEE,commit_signer:2/3=67%)
> > Tom Rini <trini@konsulko.com> (maintainer:THE REST,authored:1/3=33%,added_lines:1/3=33%,removed_lines:1/2=50%)
> > Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> (commit_signer:2/3=67%,authored:2/3=67%,added_lines:2/3=67%,removed_lines:1/2=50%)
> > u-boot@lists.denx.de (open list)...
> > 
> > still I can see it on patchworks with Neil being the gatekeeper.
> 
> Is your tree out of date? That's not what it shows here, we updated that
> a while ago.

not as long as this series apparently.. plus maintainers were in copy
and actively reviewing v1/v2/v3

but yeah, These patches were developed on top of "ece349ade29 Prepare
v2026.07" when the development started (so before the list was
updated). 

anyway, so what is the next step. resend posting as v5 on top of
v2026.10-x ?


> 
> -- 
> Tom

Re: [PATCH v4 0/5] ufs: rpmb: route OP-TEE RPMB secure storage over UFS

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6518 bytes --]

On Mon, Sep 07, 2026 at 09:16:36PM +0200, Jorge Ramirez wrote:
> On 07/09/26 10:13:39, Tom Rini wrote:
> > On Mon, Sep 07, 2026 at 10:40:59AM +0200, Jorge Ramirez wrote:
> > > On 07/09/26 12:47:39, Neha Malcom Francis wrote:
> > > > Hi Jorge
> > > >
> > > > On 07/09/26 12:38, Jorge Ramirez wrote:
> > > > > On 27/08/26 11:01:41, Jorge Ramirez wrote:
> > > > >> On 21/08/26 16:02:18, Jorge Ramirez wrote:
> > > > >>> On 17/08/26 16:38:40, Jorge Ramirez wrote:
> > > > >>>> On 07/08/26 16:01:05, Jorge Ramirez-Ortiz wrote:
> > > > >>>>> OP-TEE secure storage (CFG_RPMB_FS) relies on an RPMB partition, but
> > > > >>>>> U-Boot's OP-TEE RPMB supplicant only speaks the legacy single-command
> > > > >>>>> interface, which is bound to eMMC. SoCs that are UFS-only and have no
> > > > >>>>> eMMC (for example the Qualcomm SA8775P) therefore cannot back OP-TEE
> > > > >>>>> secure storage from U-Boot today. This series adds that support.
> > > > >>>>>
> > > > >>>>> It introduces the transport-agnostic OP-TEE RPMB "subsystem" interface
> > > > >>>>> (PROBE_RESET / PROBE_NEXT / FRAMES), where the normal world enumerates
> > > > >>>>> the RPMB device and reports its kind, size and CID, then carries the
> > > > >>>>> signed frames. The legacy eMMC supplicant is preserved unchanged, only
> > > > >>>>> renamed to rpmb_emmc.c, with the new UFS backend added as a separate
> > > > >>>>> rpmb_ufs.c; the two are mutually exclusive via Kconfig (SUPPORT_UFS_RPMB
> > > > >>>>> depends on !SUPPORT_EMMC_RPMB) because the OP-TEE supplicant handles a
> > > > >>>>> single RPMB transport. The subsystem interface is UFS-only for now; eMMC
> > > > >>>>> can be migrated onto it later as the legacy path is retired.
> > > > >>>>>
> > > > >>>>> On top of that it adds a UFS RPMB transport that moves JEDEC RPMB frames
> > > > >>>>> to and from the RPMB Well-Known LUN using SCSI SECURITY PROTOCOL IN/OUT.
> > > > >>>>> The per-region 16-byte CID is derived by BLAKE2b-hashing the exact
> > > > >>>>> device-id string the Linux kernel builds (ufshcd_create_device_id()
> > > > >>>>> plus a "-R<region>" suffix), so OP-TEE derives an RPMB key that matches
> > > > >>>>> the one Linux would use.
> > > > >>>>>
> > > > >>>>> The first patch is a standalone UFS descriptor fix the RPMB path depends
> > > > >>>>> on (UTF-16BE string decoding); the transport patches also include a
> > > > >>>>> power-on UNIT ATTENTION retry and a DMA-alignment bounce for the RPMB
> > > > >>>>> WLUN.
> > > > >>>>>
> > > > >>>>> Note: reading UFS descriptors reliably also requires the descriptor
> > > > >>>>> data-segment cache-invalidation fix, which has already been posted and
> > > > >>>>> merged separately, so this series is based on top of it.
> > > > >>>>>
> > > > >>>>> Tested on the Qualcomm IQ-9075-EVK (SA8775P): OP-TEE with CFG_RPMB_FS
> > > > >>>>> programs the RPMB key through U-Boot and reads/writes secure-storage
> > > > >>>>> objects, with the derived CID matching the Linux UFS device_id ABI.
> > > > >>>>>
> > > > >>>>> Dependencies:
> > > > >>>>> Linux kernel:
> > > > >>>>>  https://lore.kernel.org/linux-scsi/20260716083728.2226422-1-jorge.ramirez@oss.qualcomm.com/
> > > > >>>>> Op-tee
> > > > >>>>>  https://github.com/OP-TEE/optee_os/pull/7881
> > > > >>>>>
> > > > >>>>> v4:
> > > > >>>>>  - ufs: decode string descriptors: dropped the in-place
> > > > >>>>>    ufshcd_str_desc_to_cpu() byte-swap helper; instead added an endian
> > > > >>>>>    argument to utf16_to_utf8() (UTF16_HOST/LITTLE/BIG_ENDIAN) and decode
> > > > >>>>>    with UTF16_BIG_ENDIAN, mirroring the kernel's utf16s_to_utf8s().
> > > > >>>>>    Existing EFI callers pass UTF16_HOST_ENDIAN.
> > > > >>>>>  - ufs: RPMB transport: build the SECURITY PROTOCOL CDB with
> > > > >>>>>    put_unaligned_be16()/put_unaligned_be32(); drop the
> > > > >>>>>    rpmb_frame_request() helper in favour of get_unaligned_be16(); move
> > > > >>>>>    ufs_rpmb_read_geometry() to the patch that first uses it so it is not
> > > > >>>>>    an unused static function during git bisect.
> > > > >>>>>  - ufs: per-region CID/size: reject an out-of-range device-reported
> > > > >>>>>    logical block size before shifting and split the size computation into
> > > > >>>>>    separate statements for readability; order <u-boot/...> after
> > > > >>>>>    <linux/...>; note that the serial hex encoding matches the kernel
> > > > >>>>>    device-id ABI.
> > > > >>>>>
> > > > >>>>
> > > > >>>> any further comments, is it ok to merge?
> > > > >>>>
> > > > >>>
> > > > >>> EOW reminder - this has been pending for a long while
> > > > >>
> > > > >>
> > > > >> anyone care to comment please?
> > > > >
> > > > >
> > > > > kernel changes accepted and op-tee changes merged.
> > > > > Just this one pending with no comments for nearly a month.
> > > > >
> > > > > maybe we can merge?
> > > > >
> > > > > thanks
> > > > > Jorge
> > > > >
> > > > >
> > > > >
> > > >
> > > > Looks like you're sending to the old mailing list instead of
> > > > u-boot@lists.u-boot-project.org
> > > >
> > > 
> > > hi Neah,
> > > 
> > > ah interesting, maybe that explains it depending on people'w workflows: I see it hasnt landed on u-boot lore's.
> > > 
> > > I just run get_maintainers.pl and the recommended list is
> > > 
> > > jramirez@trex:u-boot (ufs-rpmb.v4 $) $ ./scripts/get_maintainer.pl drivers/tee/optee/Makefile
> > > Jens Wiklander <jens.wiklander@linaro.org> (maintainer:TEE)
> > > Ilias Apalodimas <ilias.apalodimas@linaro.org> (maintainer:TEE,commit_signer:2/3=67%)
> > > Tom Rini <trini@konsulko.com> (maintainer:THE REST,authored:1/3=33%,added_lines:1/3=33%,removed_lines:1/2=50%)
> > > Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> (commit_signer:2/3=67%,authored:2/3=67%,added_lines:2/3=67%,removed_lines:1/2=50%)
> > > u-boot@lists.denx.de (open list)...
> > > 
> > > still I can see it on patchworks with Neil being the gatekeeper.
> > 
> > Is your tree out of date? That's not what it shows here, we updated that
> > a while ago.
> 
> not as long as this series apparently.. plus maintainers were in copy
> and actively reviewing v1/v2/v3
> 
> but yeah, These patches were developed on top of "ece349ade29 Prepare
> v2026.07" when the development started (so before the list was
> updated). 
> 
> anyway, so what is the next step. resend posting as v5 on top of
> v2026.10-x ?

Does v4 apply cleanly to the current next branch?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 0/5] ufs: rpmb: route OP-TEE RPMB secure storage over UFS

[Jorge Ramirez]

On 07/09/26 13:36:08, Tom Rini wrote:
> On Mon, Sep 07, 2026 at 09:16:36PM +0200, Jorge Ramirez wrote:
> > On 07/09/26 10:13:39, Tom Rini wrote:
> > > On Mon, Sep 07, 2026 at 10:40:59AM +0200, Jorge Ramirez wrote:
> > > > On 07/09/26 12:47:39, Neha Malcom Francis wrote:
> > > > > Hi Jorge
> > > > >
> > > > > On 07/09/26 12:38, Jorge Ramirez wrote:
> > > > > > On 27/08/26 11:01:41, Jorge Ramirez wrote:
> > > > > >> On 21/08/26 16:02:18, Jorge Ramirez wrote:
> > > > > >>> On 17/08/26 16:38:40, Jorge Ramirez wrote:
> > > > > >>>> On 07/08/26 16:01:05, Jorge Ramirez-Ortiz wrote:
> > > > > >>>>> OP-TEE secure storage (CFG_RPMB_FS) relies on an RPMB partition, but
> > > > > >>>>> U-Boot's OP-TEE RPMB supplicant only speaks the legacy single-command
> > > > > >>>>> interface, which is bound to eMMC. SoCs that are UFS-only and have no
> > > > > >>>>> eMMC (for example the Qualcomm SA8775P) therefore cannot back OP-TEE
> > > > > >>>>> secure storage from U-Boot today. This series adds that support.
> > > > > >>>>>
> > > > > >>>>> It introduces the transport-agnostic OP-TEE RPMB "subsystem" interface
> > > > > >>>>> (PROBE_RESET / PROBE_NEXT / FRAMES), where the normal world enumerates
> > > > > >>>>> the RPMB device and reports its kind, size and CID, then carries the
> > > > > >>>>> signed frames. The legacy eMMC supplicant is preserved unchanged, only
> > > > > >>>>> renamed to rpmb_emmc.c, with the new UFS backend added as a separate
> > > > > >>>>> rpmb_ufs.c; the two are mutually exclusive via Kconfig (SUPPORT_UFS_RPMB
> > > > > >>>>> depends on !SUPPORT_EMMC_RPMB) because the OP-TEE supplicant handles a
> > > > > >>>>> single RPMB transport. The subsystem interface is UFS-only for now; eMMC
> > > > > >>>>> can be migrated onto it later as the legacy path is retired.
> > > > > >>>>>
> > > > > >>>>> On top of that it adds a UFS RPMB transport that moves JEDEC RPMB frames
> > > > > >>>>> to and from the RPMB Well-Known LUN using SCSI SECURITY PROTOCOL IN/OUT.
> > > > > >>>>> The per-region 16-byte CID is derived by BLAKE2b-hashing the exact
> > > > > >>>>> device-id string the Linux kernel builds (ufshcd_create_device_id()
> > > > > >>>>> plus a "-R<region>" suffix), so OP-TEE derives an RPMB key that matches
> > > > > >>>>> the one Linux would use.
> > > > > >>>>>
> > > > > >>>>> The first patch is a standalone UFS descriptor fix the RPMB path depends
> > > > > >>>>> on (UTF-16BE string decoding); the transport patches also include a
> > > > > >>>>> power-on UNIT ATTENTION retry and a DMA-alignment bounce for the RPMB
> > > > > >>>>> WLUN.
> > > > > >>>>>
> > > > > >>>>> Note: reading UFS descriptors reliably also requires the descriptor
> > > > > >>>>> data-segment cache-invalidation fix, which has already been posted and
> > > > > >>>>> merged separately, so this series is based on top of it.
> > > > > >>>>>
> > > > > >>>>> Tested on the Qualcomm IQ-9075-EVK (SA8775P): OP-TEE with CFG_RPMB_FS
> > > > > >>>>> programs the RPMB key through U-Boot and reads/writes secure-storage
> > > > > >>>>> objects, with the derived CID matching the Linux UFS device_id ABI.
> > > > > >>>>>
> > > > > >>>>> Dependencies:
> > > > > >>>>> Linux kernel:
> > > > > >>>>>  https://lore.kernel.org/linux-scsi/20260716083728.2226422-1-jorge.ramirez@oss.qualcomm.com/
> > > > > >>>>> Op-tee
> > > > > >>>>>  https://github.com/OP-TEE/optee_os/pull/7881
> > > > > >>>>>
> > > > > >>>>> v4:
> > > > > >>>>>  - ufs: decode string descriptors: dropped the in-place
> > > > > >>>>>    ufshcd_str_desc_to_cpu() byte-swap helper; instead added an endian
> > > > > >>>>>    argument to utf16_to_utf8() (UTF16_HOST/LITTLE/BIG_ENDIAN) and decode
> > > > > >>>>>    with UTF16_BIG_ENDIAN, mirroring the kernel's utf16s_to_utf8s().
> > > > > >>>>>    Existing EFI callers pass UTF16_HOST_ENDIAN.
> > > > > >>>>>  - ufs: RPMB transport: build the SECURITY PROTOCOL CDB with
> > > > > >>>>>    put_unaligned_be16()/put_unaligned_be32(); drop the
> > > > > >>>>>    rpmb_frame_request() helper in favour of get_unaligned_be16(); move
> > > > > >>>>>    ufs_rpmb_read_geometry() to the patch that first uses it so it is not
> > > > > >>>>>    an unused static function during git bisect.
> > > > > >>>>>  - ufs: per-region CID/size: reject an out-of-range device-reported
> > > > > >>>>>    logical block size before shifting and split the size computation into
> > > > > >>>>>    separate statements for readability; order <u-boot/...> after
> > > > > >>>>>    <linux/...>; note that the serial hex encoding matches the kernel
> > > > > >>>>>    device-id ABI.
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> any further comments, is it ok to merge?
> > > > > >>>>
> > > > > >>>
> > > > > >>> EOW reminder - this has been pending for a long while
> > > > > >>
> > > > > >>
> > > > > >> anyone care to comment please?
> > > > > >
> > > > > >
> > > > > > kernel changes accepted and op-tee changes merged.
> > > > > > Just this one pending with no comments for nearly a month.
> > > > > >
> > > > > > maybe we can merge?
> > > > > >
> > > > > > thanks
> > > > > > Jorge
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > Looks like you're sending to the old mailing list instead of
> > > > > u-boot@lists.u-boot-project.org
> > > > >
> > > > 
> > > > hi Neah,
> > > > 
> > > > ah interesting, maybe that explains it depending on people'w workflows: I see it hasnt landed on u-boot lore's.
> > > > 
> > > > I just run get_maintainers.pl and the recommended list is
> > > > 
> > > > jramirez@trex:u-boot (ufs-rpmb.v4 $) $ ./scripts/get_maintainer.pl drivers/tee/optee/Makefile
> > > > Jens Wiklander <jens.wiklander@linaro.org> (maintainer:TEE)
> > > > Ilias Apalodimas <ilias.apalodimas@linaro.org> (maintainer:TEE,commit_signer:2/3=67%)
> > > > Tom Rini <trini@konsulko.com> (maintainer:THE REST,authored:1/3=33%,added_lines:1/3=33%,removed_lines:1/2=50%)
> > > > Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> (commit_signer:2/3=67%,authored:2/3=67%,added_lines:2/3=67%,removed_lines:1/2=50%)
> > > > u-boot@lists.denx.de (open list)...
> > > > 
> > > > still I can see it on patchworks with Neil being the gatekeeper.
> > > 
> > > Is your tree out of date? That's not what it shows here, we updated that
> > > a while ago.
> > 
> > not as long as this series apparently.. plus maintainers were in copy
> > and actively reviewing v1/v2/v3
> > 
> > but yeah, These patches were developed on top of "ece349ade29 Prepare
> > v2026.07" when the development started (so before the list was
> > updated). 
> > 
> > anyway, so what is the next step. resend posting as v5 on top of
> > v2026.10-x ?
> 
> Does v4 apply cleanly to the current next branch?
>

yes it does

> -- 
> Tom

Re: [PATCH v4 0/5] ufs: rpmb: route OP-TEE RPMB secure storage over UFS

[Peter Robinson]

> > > still I can see it on patchworks with Neil being the gatekeeper.
> >
> > Is your tree out of date? That's not what it shows here, we updated that
> > a while ago.
>
> not as long as this series apparently.. plus maintainers were in copy
> and actively reviewing v1/v2/v3
>
> but yeah, These patches were developed on top of "ece349ade29 Prepare
> v2026.07" when the development started (so before the list was
> updated).

Also note the key development branch is now called main not master.

> anyway, so what is the next step. resend posting as v5 on top of
> v2026.10-x ?

Like the kernel probably the latest -rc1 or -next depending on dependencies.

Re: [PATCH v4 0/5] ufs: rpmb: route OP-TEE RPMB secure storage over UFS

[Jorge Ramirez]

On 08/09/26 09:43:14, neil.armstrong@linaro.org wrote:
> On 9/7/26 10:40, Jorge Ramirez wrote:
> > On 07/09/26 12:47:39, Neha Malcom Francis wrote:
> > > Hi Jorge
> > > 
> > > On 07/09/26 12:38, Jorge Ramirez wrote:
> > > > On 27/08/26 11:01:41, Jorge Ramirez wrote:
> > > > > On 21/08/26 16:02:18, Jorge Ramirez wrote:
> > > > > > On 17/08/26 16:38:40, Jorge Ramirez wrote:
> > > > > > > On 07/08/26 16:01:05, Jorge Ramirez-Ortiz wrote:
> > > > > > > > OP-TEE secure storage (CFG_RPMB_FS) relies on an RPMB partition, but
> > > > > > > > U-Boot's OP-TEE RPMB supplicant only speaks the legacy single-command
> > > > > > > > interface, which is bound to eMMC. SoCs that are UFS-only and have no
> > > > > > > > eMMC (for example the Qualcomm SA8775P) therefore cannot back OP-TEE
> > > > > > > > secure storage from U-Boot today. This series adds that support.
> > > > > > > > 
> > > > > > > > It introduces the transport-agnostic OP-TEE RPMB "subsystem" interface
> > > > > > > > (PROBE_RESET / PROBE_NEXT / FRAMES), where the normal world enumerates
> > > > > > > > the RPMB device and reports its kind, size and CID, then carries the
> > > > > > > > signed frames. The legacy eMMC supplicant is preserved unchanged, only
> > > > > > > > renamed to rpmb_emmc.c, with the new UFS backend added as a separate
> > > > > > > > rpmb_ufs.c; the two are mutually exclusive via Kconfig (SUPPORT_UFS_RPMB
> > > > > > > > depends on !SUPPORT_EMMC_RPMB) because the OP-TEE supplicant handles a
> > > > > > > > single RPMB transport. The subsystem interface is UFS-only for now; eMMC
> > > > > > > > can be migrated onto it later as the legacy path is retired.
> > > > > > > > 
> > > > > > > > On top of that it adds a UFS RPMB transport that moves JEDEC RPMB frames
> > > > > > > > to and from the RPMB Well-Known LUN using SCSI SECURITY PROTOCOL IN/OUT.
> > > > > > > > The per-region 16-byte CID is derived by BLAKE2b-hashing the exact
> > > > > > > > device-id string the Linux kernel builds (ufshcd_create_device_id()
> > > > > > > > plus a "-R<region>" suffix), so OP-TEE derives an RPMB key that matches
> > > > > > > > the one Linux would use.
> > > > > > > > 
> > > > > > > > The first patch is a standalone UFS descriptor fix the RPMB path depends
> > > > > > > > on (UTF-16BE string decoding); the transport patches also include a
> > > > > > > > power-on UNIT ATTENTION retry and a DMA-alignment bounce for the RPMB
> > > > > > > > WLUN.
> > > > > > > > 
> > > > > > > > Note: reading UFS descriptors reliably also requires the descriptor
> > > > > > > > data-segment cache-invalidation fix, which has already been posted and
> > > > > > > > merged separately, so this series is based on top of it.
> > > > > > > > 
> > > > > > > > Tested on the Qualcomm IQ-9075-EVK (SA8775P): OP-TEE with CFG_RPMB_FS
> > > > > > > > programs the RPMB key through U-Boot and reads/writes secure-storage
> > > > > > > > objects, with the derived CID matching the Linux UFS device_id ABI.
> > > > > > > > 
> > > > > > > > Dependencies:
> > > > > > > > Linux kernel:
> > > > > > > >   https://lore.kernel.org/linux-scsi/20260716083728.2226422-1-jorge.ramirez@oss.qualcomm.com/
> > > > > > > > Op-tee
> > > > > > > >   https://github.com/OP-TEE/optee_os/pull/7881
> > > > > > > > 
> > > > > > > > v4:
> > > > > > > >   - ufs: decode string descriptors: dropped the in-place
> > > > > > > >     ufshcd_str_desc_to_cpu() byte-swap helper; instead added an endian
> > > > > > > >     argument to utf16_to_utf8() (UTF16_HOST/LITTLE/BIG_ENDIAN) and decode
> > > > > > > >     with UTF16_BIG_ENDIAN, mirroring the kernel's utf16s_to_utf8s().
> > > > > > > >     Existing EFI callers pass UTF16_HOST_ENDIAN.
> > > > > > > >   - ufs: RPMB transport: build the SECURITY PROTOCOL CDB with
> > > > > > > >     put_unaligned_be16()/put_unaligned_be32(); drop the
> > > > > > > >     rpmb_frame_request() helper in favour of get_unaligned_be16(); move
> > > > > > > >     ufs_rpmb_read_geometry() to the patch that first uses it so it is not
> > > > > > > >     an unused static function during git bisect.
> > > > > > > >   - ufs: per-region CID/size: reject an out-of-range device-reported
> > > > > > > >     logical block size before shifting and split the size computation into
> > > > > > > >     separate statements for readability; order <u-boot/...> after
> > > > > > > >     <linux/...>; note that the serial hex encoding matches the kernel
> > > > > > > >     device-id ABI.
> > > > > > > > 
> > > > > > > 
> > > > > > > any further comments, is it ok to merge?
> > > > > > > 
> > > > > > 
> > > > > > EOW reminder - this has been pending for a long while
> > > > > 
> > > > > 
> > > > > anyone care to comment please?
> > > > 
> > > > 
> > > > kernel changes accepted and op-tee changes merged.
> > > > Just this one pending with no comments for nearly a month.
> > > > 
> > > > maybe we can merge?
> > > > 
> > > > thanks
> > > > Jorge
> > > > 
> > > > 
> > > > 
> > > 
> > > Looks like you're sending to the old mailing list instead of
> > > u-boot@lists.u-boot-project.org
> > > 
> > 
> > hi Neah,
> > 
> > ah interesting, maybe that explains it depending on people'w workflows: I see it hasnt landed on u-boot lore's.
> > 
> > I just run get_maintainers.pl and the recommended list is
> > 
> > jramirez@trex:u-boot (ufs-rpmb.v4 $) $ ./scripts/get_maintainer.pl drivers/tee/optee/Makefile
> > Jens Wiklander <jens.wiklander@linaro.org> (maintainer:TEE)
> > Ilias Apalodimas <ilias.apalodimas@linaro.org> (maintainer:TEE,commit_signer:2/3=67%)
> > Tom Rini <trini@konsulko.com> (maintainer:THE REST,authored:1/3=33%,added_lines:1/3=33%,removed_lines:1/2=50%)
> > Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> (commit_signer:2/3=67%,authored:2/3=67%,added_lines:2/3=67%,removed_lines:1/2=50%)
> > u-boot@lists.denx.de (open list)...
> > 
> > still I can see it on patchworks with Neil being the gatekeeper.
> > 
> > I hope he can work from there without me having to resend
> 
> I'd like some review on the optee side before picking the UFS changes, which are fine.
> 
> I'm worried about the clash with Jan's changeset on the optee side.
> 
> Neil


adding the correct mailing list now

> 
> > 
> > thanks for the heads up though!
> > Jorge
> > 
> > 
> > > --
> > > Thanking You
> > > Neha Malcom Francis
> > > 
> 

Re: [PATCH v4 1/5] ufs: decode string descriptors as UTF-16 big-endian

[David Lechner]

On 8/7/26 9:01 AM, Jorge Ramirez-Ortiz wrote:
> UFS string descriptors are UTF-16 big-endian (JESD220), but
> ufshcd_read_string_desc() fed the raw bytes to utf16_to_utf8(), which reads
> host-endian code units, leaving dev_desc->model blank.
> 
> Add an endian parameter to utf16_to_utf8() so the caller can specify the byte
> order of the source, and pass UTF16_BIG_ENDIAN from the UFS driver, matching
> the kernel's utf16s_to_utf8s(..., UTF16_BIG_ENDIAN). Existing callers keep
> their current behaviour via UTF16_HOST_ENDIAN.

I'm not sure host-endian ever makes sense. UTF-16 is either going to be
coming over a network or from a file, so needs to be big or little according
to the protocol or defined file format.

> 
> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
> ---
>  drivers/ufs/ufs-uclass.c  |  7 ++++---
>  include/charset.h         | 17 ++++++++++++++++-
>  lib/charset.c             | 15 ++++++++++++++-
>  lib/efi_loader/efi_file.c |  4 ++--
>  4 files changed, 36 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c
> index 6a51f337e47..5cde2ab70be 100644
> --- a/drivers/ufs/ufs-uclass.c
> +++ b/drivers/ufs/ufs-uclass.c
> @@ -1766,11 +1766,12 @@ static int ufshcd_read_string_desc(struct ufs_hba *hba, int desc_index,
>  		}
>  
>  		/*
> -		 * the descriptor contains string in UTF16 format
> -		 * we need to convert to utf-8 so it can be displayed
> +		 * the descriptor contains a big-endian UTF-16 string, convert
> +		 * it to utf-8 so it can be displayed
>  		 */
>  		utf16_to_utf8(buff_ascii,
> -			      (uint16_t *)&buf[QUERY_DESC_HDR_SIZE], ascii_len);
> +			      (uint16_t *)&buf[QUERY_DESC_HDR_SIZE], ascii_len,
> +			      UTF16_BIG_ENDIAN);
>  
>  		/* replace non-printable or non-ASCII characters with spaces */
>  		for (i = 0; i < ascii_len; i++)
> diff --git a/include/charset.h b/include/charset.h
> index 348bad5883a..442cc44d077 100644
> --- a/include/charset.h
> +++ b/include/charset.h
> @@ -13,6 +13,19 @@
>  
>  #define MAX_UTF8_PER_UTF16 3
>  
> +/**
> + * enum utf16_endian - byte order of a UTF-16 string
> + *
> + * @UTF16_HOST_ENDIAN:	code units are in host byte order
> + * @UTF16_LITTLE_ENDIAN:	code units are little-endian
> + * @UTF16_BIG_ENDIAN:	code units are big-endian
> + */
> +enum utf16_endian {
> +	UTF16_HOST_ENDIAN,
> +	UTF16_LITTLE_ENDIAN,
> +	UTF16_BIG_ENDIAN,
> +};
> +
>  /*
>   * codepage_437 - Unicode to codepage 437 translation table
>   */
> @@ -299,9 +312,11 @@ size_t u16_strlcat(u16 *dest, const u16 *src, size_t count);
>   * @dest:	the destination buffer to write the utf8 characters
>   * @src:	the source utf16 string
>   * @size:	the number of utf16 characters to convert
> + * @endian:	byte order of the code units in 'src'
>   * Return:	the pointer to the first unwritten byte in 'dest'
>   */
> -uint8_t *utf16_to_utf8(uint8_t *dest, const uint16_t *src, size_t size);
> +uint8_t *utf16_to_utf8(uint8_t *dest, const uint16_t *src, size_t size,
> +		       enum utf16_endian endian);
>  
>  /**
>   * utf_to_cp() - translate Unicode code point to 8bit codepage
> diff --git a/lib/charset.c b/lib/charset.c
> index 182c92a50c4..e5861ba96f8 100644
> --- a/lib/charset.c
> +++ b/lib/charset.c
> @@ -11,6 +11,7 @@
>  #include <efi_loader.h>
>  #include <errno.h>
>  #include <malloc.h>
> +#include <asm/byteorder.h>
>  
>  /**
>   * codepage_437 - Unicode to codepage 437 translation table
> @@ -458,13 +459,25 @@ size_t u16_strlcat(u16 *dest, const u16 *src, size_t count)
>  }
>  
>  /* Convert UTF-16 to UTF-8.  */
> -uint8_t *utf16_to_utf8(uint8_t *dest, const uint16_t *src, size_t size)
> +uint8_t *utf16_to_utf8(uint8_t *dest, const uint16_t *src, size_t size,
> +		       enum utf16_endian endian)
>  {
>  	uint32_t code_high = 0;
>  
>  	while (size--) {
>  		uint32_t code = *src++;
>  
> +		switch (endian) {
> +		case UTF16_LITTLE_ENDIAN:
> +			code = le16_to_cpu(code);
> +			break;
> +		case UTF16_BIG_ENDIAN:
> +			code = be16_to_cpu(code);
> +			break;
> +		case UTF16_HOST_ENDIAN:
> +			break;
> +		}
> +
>  		if (code_high) {
>  			if (code >= 0xDC00 && code <= 0xDFFF) {
>  				/* Surrogate pair.  */
> diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
> index 19b43c4a625..b0faae2d716 100644
> --- a/lib/efi_loader/efi_file.c
> +++ b/lib/efi_loader/efi_file.c
> @@ -184,7 +184,7 @@ static struct efi_file_handle *file_open(struct file_system *fs,
>  	int flen = 0;
>  
>  	if (file_name) {
> -		utf16_to_utf8((u8 *)f0, file_name, 1);
> +		utf16_to_utf8((u8 *)f0, file_name, 1, UTF16_HOST_ENDIAN);

I'm assuming this should be UTF16_LITTLE_ENDIAN (because FAT file system).
The bytes read from the file are not going to swap themselves on a
big-endian system.

>  		flen = u16_strlen(file_name);
>  	}
>  
> @@ -216,7 +216,7 @@ static struct efi_file_handle *file_open(struct file_system *fs,
>  			*p++ = '/';
>  		}
>  
> -		utf16_to_utf8((u8 *)p, file_name, flen);
> +		utf16_to_utf8((u8 *)p, file_name, flen, UTF16_HOST_ENDIAN);

ditto

>  
>  		if (sanitize_path(fh->path))
>  			goto error;

Re: [PATCH v4 1/5] ufs: decode string descriptors as UTF-16 big-endian

[David Lechner]

On 9/9/26 11:11 AM, David Lechner wrote:
> On 8/7/26 9:01 AM, Jorge Ramirez-Ortiz wrote:
>> UFS string descriptors are UTF-16 big-endian (JESD220), but
>> ufshcd_read_string_desc() fed the raw bytes to utf16_to_utf8(), which reads
>> host-endian code units, leaving dev_desc->model blank.
>>
>> Add an endian parameter to utf16_to_utf8() so the caller can specify the byte
>> order of the source, and pass UTF16_BIG_ENDIAN from the UFS driver, matching
>> the kernel's utf16s_to_utf8s(..., UTF16_BIG_ENDIAN). Existing callers keep
>> their current behaviour via UTF16_HOST_ENDIAN.
> 
Probably deserves a Fixes: tag as well.