[PATCH AUTOSEL 6.17-6.1] scsi: ufs: host: mediatek: Assign power mode userdata before FASTAUTO mode change

Sasha Levin sashal at kernel.org
Sat Oct 25 08:58:44 PDT 2025


From: Alice Chao <alice.chao at 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 at mediatek.com>
Reviewed-by: Peter Wang <peter.wang at mediatek.com>
Signed-off-by: Peter Wang <peter.wang at mediatek.com>
Link: https://lore.kernel.org/r/20250811131423.3444014-7-peter.wang@mediatek.com
Signed-off-by: Martin K. Petersen <martin.petersen at oracle.com>
Signed-off-by: Sasha Levin <sashal at 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




More information about the Linux-mediatek mailing list