[...] > > > > > > > > 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 > > Got it. That's quite reasonable for taking the current implementation. > MediaTek will try to propose the vendor specific helper functions > and and upstream other backends for some downstream > implementation. Hope this could be happened soon. Thanks for taking > time to read the previous reply. >
YW and FWIW I'd really like to see that. What Jorge is proposing here is easily extendable with extra algorithms with a Kconfig option or weak per platform functions. Thanks /Ilias > Best regards, > Macpaul Lin >
