Hi Christoph, On Mon, 2020-02-24 at 15:37 -0800, Christoph Hellwig wrote: > On Sun, Feb 23, 2020 at 09:47:36PM +0800, Stanley Chu wrote: > > Yes, MediaTek is keeping work closely with inline encryption patch sets. > > Currently the v6 version can work well (without > > UFSHCD_QUIRK_BROKEN_CRYPTO quirk) at least in our MT6779 SoC platform > > which basic SoC support and some other peripheral drivers are under > > upstreaming as below link, > > > > https://patchwork.kernel.org/project/linux-mediatek/list/?state=% > > 2A&q=6779&series=&submitter=&delegate=&archive=both > > > > The integration with inline encryption patch set needs to patch > > ufs-mediatek and patches are ready in downstream. We plan to upstream > > them soon after inline encryption patch sets get merged. > > What amount of support do you need in ufs-mediatek? It seems like > pretty much every ufs low-level driver needs some kind of specific > support now, right? I wonder if we should instead opt into the support > instead of all the quirking here. The patch in ufs-mediatek is aimed to issue vendor-specific SMC calls for host initialization and configuration. This is because MediaTek UFS host has some "secure-protected" registers/features which need to be accessed/switched in secure world. Such protection is not mentioned by UFSHCI specifications thus inline encryption patch set assumes that every registers in UFSHCI can be accessed normally in kernel. This makes sense and surely the patchset can work fine in any "standard" UFS host. However if host has special design then it can work normally only if some vendor-specific treatment is applied. I think one of the reason to apply UFSHCD_QUIRK_BROKEN_CRYPTO quirk in ufs-qcom host is similar to above case. Thanks, Stanley Chu
