From: Alice Chao alice.chao@mediatek.com
[ Upstream commit 979feee0cf43b32d288931649d7c6d9a5524ea55 ]
Assign power mode userdata settings before transitioning to FASTAUTO power mode. This ensures that default timeout values are set for various parameters, enhancing the reliability and performance of the power mode change process.
Signed-off-by: Alice Chao alice.chao@mediatek.com Reviewed-by: Peter Wang peter.wang@mediatek.com Signed-off-by: Peter Wang peter.wang@mediatek.com Link: https://lore.kernel.org/r/20250811131423.3444014-7-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
Rationale - Fixes a real gap in the Mediatek FASTAUTO transition path. In the Mediatek vendor pre-change hook `ufs_mtk_pre_pwr_change()` the driver performs an intermediate power mode switch to HSG1B FASTAUTO by calling `ufshcd_uic_change_pwr_mode(hba, FASTAUTO_MODE << 4 | FASTAUTO_MODE)` without first programming the UniPro power mode userdata timeouts. See the existing call in `drivers/ufs/host/ufs- mediatek.c:1119`. The change adds programming of `PA_PWRMODEUSERDATA[0..5]` and `DME_Local*` timeout attributes immediately before that FASTAUTO change (inside the `if (ufs_mtk_pmc_via_fastauto(...))` block near `drivers/ufs/host/ufs- mediatek.c:1101`), ensuring sane timer values are in place for the intermediate FASTAUTO PWR mode operation. - Aligns Mediatek path with core behavior. The UFS core already sets these exact defaults when it performs a (final) power mode change in `ufshcd_change_power_mode()` (see `drivers/ufs/core/ufshcd.c:4674` through `drivers/ufs/core/ufshcd.c:4693`). Because Mediatek does an extra, vendor-specific FASTAUTO step earlier in the PRE_CHANGE hook, not setting these beforehand can leave the link using unset/legacy timeout values during that intermediate transition, increasing the chance of DL/FC/Replay/AFC timer-related failures (the driver even logs “HSG1B FASTAUTO failed” on error at `drivers/ufs/host/ufs- mediatek.c:1122`). - Small, contained, and low-risk. The patch: - Only touches `drivers/ufs/host/ufs-mediatek.c` and only executes when `UFS_MTK_CAP_PMC_VIA_FASTAUTO` is enabled via DT (“mediatek,ufs-pmc-via-fastauto” in `ufs_mtk_init_host_caps()`). - Uses standard UniPro attributes and the same default values already used by the core (`include/ufs/unipro.h`), so it’s consistent with existing code paths. - Is guarded by `UFSHCD_QUIRK_SKIP_DEF_UNIPRO_TIMEOUT_SETTING`, mirroring core behavior, so it won’t override vendor-specific tunings on platforms that explicitly skip the defaults. - Has no API/ABI changes and doesn’t alter flow outside the Mediatek- specific fastauto path. - Addresses user-visible reliability. While the commit message frames it as improving “reliability and performance,” the operational effect is to prevent misconfigured timeout values during a UIC PWR mode transition that the driver initiates. That is a correctness fix for affected platforms, not a feature.
Backport considerations - No new symbols or dependencies; the macros `PA_PWRMODEUSERDATA*`, `DME_Local*`, and the quirk flag exist in current stable branches (e.g., `include/ufs/unipro.h`, `include/ufs/ufshcd.h:620`). - The surrounding function and fastauto path exist in stable (see `drivers/ufs/host/ufs-mediatek.c:1083` onward), so the change applies cleanly. - Writing these values twice (once before the intermediate FASTAUTO, again before the final power mode change in core) is benign and matches existing practice in other drivers.
Conclusion - This is an important, narrowly scoped reliability fix for Mediatek UFS hosts that perform PMC via FASTAUTO. It follows stable rules (bugfix, minimal risk, no architectural changes, confined to a vendor driver) and should be backported.
drivers/ufs/host/ufs-mediatek.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c index 4171fa672450d..ada21360aa270 100644 --- a/drivers/ufs/host/ufs-mediatek.c +++ b/drivers/ufs/host/ufs-mediatek.c @@ -1349,6 +1349,28 @@ static int ufs_mtk_pre_pwr_change(struct ufs_hba *hba, ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TXHSADAPTTYPE), PA_NO_ADAPT);
+ if (!(hba->quirks & UFSHCD_QUIRK_SKIP_DEF_UNIPRO_TIMEOUT_SETTING)) { + ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA0), + DL_FC0ProtectionTimeOutVal_Default); + ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA1), + DL_TC0ReplayTimeOutVal_Default); + ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA2), + DL_AFC0ReqTimeOutVal_Default); + ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA3), + DL_FC1ProtectionTimeOutVal_Default); + ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA4), + DL_TC1ReplayTimeOutVal_Default); + ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA5), + DL_AFC1ReqTimeOutVal_Default); + + ufshcd_dme_set(hba, UIC_ARG_MIB(DME_LocalFC0ProtectionTimeOutVal), + DL_FC0ProtectionTimeOutVal_Default); + ufshcd_dme_set(hba, UIC_ARG_MIB(DME_LocalTC0ReplayTimeOutVal), + DL_TC0ReplayTimeOutVal_Default); + ufshcd_dme_set(hba, UIC_ARG_MIB(DME_LocalAFC0ReqTimeOutVal), + DL_AFC0ReqTimeOutVal_Default); + } + ret = ufshcd_uic_change_pwr_mode(hba, FASTAUTO_MODE << 4 | FASTAUTO_MODE);