[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251025160905.3857885-293-sashal@kernel.org>
Date: Sat, 25 Oct 2025 11:58:44 -0400
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
stable@...r.kernel.org
Cc: Alice Chao <alice.chao@...iatek.com>,
Peter Wang <peter.wang@...iatek.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Sasha Levin <sashal@...nel.org>,
matthias.bgg@...il.com,
angelogioacchino.delregno@...labora.com,
linux-scsi@...r.kernel.org,
linux-mediatek@...ts.infradead.org,
linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: [PATCH AUTOSEL 6.17-6.1] scsi: ufs: host: mediatek: Assign power mode userdata before FASTAUTO mode change
From: Alice Chao <alice.chao@...iatek.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@...iatek.com>
Reviewed-by: Peter Wang <peter.wang@...iatek.com>
Signed-off-by: Peter Wang <peter.wang@...iatek.com>
Link: https://lore.kernel.org/r/20250811131423.3444014-7-peter.wang@mediatek.com
Signed-off-by: Martin K. Petersen <martin.petersen@...cle.com>
Signed-off-by: Sasha Levin <sashal@...nel.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
Powered by blists - more mailing lists