Hi Jorge,
On Sun, 27 Sept 2026 at 00:09, Jorge Ramirez <[email protected]> wrote: > > On 26/09/26 22:41:00, Jorge Ramirez wrote: > > On 25/09/26 12:59:28, Ilias Apalodimas wrote: > > > Thanks for the detailed analysis. > > > > > > I am pulling in Jens for OP-TEE and I'll have a closer look next week as > > > well. > > > > the concernt I read - please correct me if I am wrong - is that this code > > affects > > downstream projects. > > > > This is just not acceptable to me - downstream implementations should have > > been > > posted to prevent exactly these kind issues. > > > > We spent time and effort doing an implementation and sharing it with the > > community - it wouldnt be fair to us to block this merge on the basis of > > downstream projects being impacted. > > > > > > in summary and to be very clear > > 1- the upstream CID derivation is the u-boot/op-tee contract that > matches mainline linux's ufshcd_create_device_id(). The contract is an > OP-TEE-defined ABI, not a Global Platform spec. > > 2. Moreover CID-key is OP-TEE's own HUK-based derivation, not GP, not JEDEC. > > 3- Nothing here blocks anyone from overriding the static ufs_rpmb_build_cid() > downstream. > > 3- if downstream scheme differs, that's the cost of having kept it out of > tree, > not a reason to hold this series for speculative plug-in infrastructure with a > single backend. +1. Macpaul is there anything else you can review apart from the downstream breakage. TBH since you didn;t bother upstreaming that, objecting to code that adds real support doesn't really stand as an arguement. Jorge, I did a quick pass and I don't see any big issues with the series. I'll do another pass later this week and send a PR if the CI agrees. Cheers /Ilias
