[PATCH v7 18/23] scsi: ufs: mediatek: Don't acquire dvfsrc-vcore twice
AngeloGioacchino Del Regno
angelogioacchino.delregno at collabora.com
Thu Feb 26 02:33:28 PST 2026
Il 26/02/26 04:45, Peter Wang (王信友) ha scritto:
> On Wed, 2026-02-25 at 13:37 +0100, AngeloGioacchino Del Regno wrote:
>> We need to check both because UFS_MTK_CAP_BOOST_CRYPT_ENGINE depends
>> on:
>> 1. reg_vcore
>> 2. clocks (crypt_mux, crypt_lp, crypt_perf).
>>
>> Failing to check for both ufs_mtk_is_boost_crypt_enabled() and
>> reg_vcore here
>> will introduce a bug that may result in storage corruption.
>>
>> So yes, Nicolas is checking both because it is *required* to check
>> both.
>>
>> Regards,
>> Angelo
>
> Hi AngeloGioacchino,
>
> To clarify, BCE stands for UFS_MTK_CAP_BOOST_CRYPT_ENGINE.
>
> BCE reg_vcore Action
> true true If check is false, continue
> true false This case cannot happen (X)
> false true If check is true, return
> false false If check is true, return
> Therefore, we only need to check whether BCE is
> true (to continue) or false (to return).
>
Thanks for the information.
Now I agree. There's no need to check for that twice, as the cap is set
only when all clocks and when reg_vcore is not NULL - I missed the first
lines of the ufs_mtk_init_boost_crypt_function() from this patch, where
Nicolas is adding a check for that at the very beginning of this function.
This means that the UFS_MTK_CAP_BOOST_CRYPT_ENGINE flag is being set only
when all of the prerequisites (reg_vcore and clocks) are satisfied.
I agree with you, Peter, there's no need to check for both the vreg and
caps, as the cap can only be set if the vreg+clocks are present.
Nicolas, can you please fix that and send a v8 ASAP?
Thanks,
Angelo
> Thanks
> Peter
More information about the linux-arm-kernel
mailing list