[PATCH AUTOSEL 6.17-6.1] scsi: ufs: host: mediatek: Assign power mode userdata before FASTAUTO mode change
STALE337d
REVIEWED: 1 (1M)
From: Sasha Levin <sashal@kernel.org>
Date: 2025-10-25 16:22:48
Also in:
linux-mediatek, linux-patches, linux-scsi, lkml, stable
Subsystem:
scsi subsystem, the rest, universal flash storage host controller driver mediatek hooks · Maintainers:
"James E.J. Bottomley", "Martin K. Petersen", Linus Torvalds, Peter Wang, Chaotian Jing
1 review trailer (1 from subsystem maintainers).
From: Alice Chao <redacted> [ 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 <redacted> 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 (local) Signed-off-by: Martin K. Petersen <redacted> 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);
--
2.51.0