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/[email protected]/ > > > >>>>> 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 > > > [email protected] > > > > > > > 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 <[email protected]> (maintainer:TEE) > > Ilias Apalodimas <[email protected]> > > (maintainer:TEE,commit_signer:2/3=67%) > > Tom Rini <[email protected]> (maintainer:THE > > REST,authored:1/3=33%,added_lines:1/3=33%,removed_lines:1/2=50%) > > Jorge Ramirez-Ortiz <[email protected]> > > (commit_signer:2/3=67%,authored:2/3=67%,added_lines:2/3=67%,removed_lines:1/2=50%) > > [email protected] (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
