linux-kernel - [PATCH AUTOSEL 6.17] scsi: ufs: host: mediatek: Fix adapt issue after PA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251025160905.3857885-277-sashal@kernel.org>
Date: Sat, 25 Oct 2025 11:58:28 -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] scsi: ufs: host: mediatek: Fix adapt issue after PA_Init

From: Alice Chao <alice.chao@...iatek.com>

[ Upstream commit d73836cb8535b3078e4d2a57913f301baec58a33 ]

Address the issue where the host does not send adapt to the device after
PA_Init success. Ensure the adapt process is correctly initiated for
devices with IP version MT6899 and above, resolving communication issues
between the host and device.

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>
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

- What it fixes: The host wasn’t initiating the adaptation phase after a
  successful PA_Init, causing communication/link reliability issues on
  newer MediaTek UFS IPs. The patch explicitly triggers adapt for those
  chips.

- Where it changes code:
  - Adds an adapt trigger in `ufs_mtk_post_link()` by setting
    `VS_DEBUGOMC` bit `0x100` for IP versions MT6899 and newer:
    `drivers/ufs/host/ufs-mediatek.c:1557-1566`.
  - The adapt step runs in the post-link stage via
    `ufs_mtk_link_startup_notify()` → `POST_CHANGE` →
    `ufs_mtk_post_link()`: `drivers/ufs/host/ufs-mediatek.c:1576-1583`.
  - The IP version gating this logic is well-defined in the platform
    header: `drivers/ufs/host/ufs-mediatek.h:208-217`.
  - The UniPro vendor attribute `VS_DEBUGOMC` is a standard symbol in
    the tree: `include/ufs/unipro.h:176`.

- How it works:
  - After link startup, for `host->ip_ver >= IP_VER_MT6899`, it reads
    `VS_DEBUGOMC`, ORs in `0x100`, and writes it back to trigger the
    device adapt: `drivers/ufs/host/ufs-mediatek.c:1559-1565`.
  - This is analogous to existing, targeted use of `VS_DEBUGOMC` for
    MT6989 (bit `0x10`) already in the pre-link path, demonstrating
    prior, chip-specific, safe use of the same attribute:
    `drivers/ufs/host/ufs-mediatek.c:1543-1550`.

- Why it’s a good stable backport:
  - Bugfix that affects users: Without adapt, devices on MT6899+ may
    exhibit link/communication issues after PA_Init, which is a
    functional defect rather than a new feature.
  - Small, contained change: Touches a single driver file and one
    function body in a guarded, post-link path.
  - Minimal risk: Gated by `host->ip_ver >= IP_VER_MT6899` so it does
    not affect older IPs; no API or architectural changes; leverages an
    existing attribute already used safely for a nearby IP generation.
  - Side effects are narrow and intended: It only sets a vendor-specific
    UniPro debug attribute after link-up on specific SoCs, then proceeds
    to the pre-existing UniPro clock gating enable, keeping previous
    sequencing intact.

- Notes on robustness:
  - The new `ufshcd_dme_get()`/`set()` calls do not check return values
    in `ufs_mtk_post_link()` (drivers/ufs/host/ufs-
    mediatek.c:1559-1565). While typical for benign post-link tuning
    where failures shouldn’t abort link-up, adding error checks would be
    slightly safer. However, given this is vendor-guarded and called
    post link-up, the practical risk is low and consistent with similar
    driver patterns.

- Stable criteria assessment:
  - Important bugfix: Yes (link/communication reliability on MT6899+).
  - Not a feature/No arch changes: Yes.
  - Minimal regression risk: Yes (chip-gated, vendor-specific).
  - Self-contained and small: Yes.
  - Explicit stable tag: Not present, but merits backport based on
    impact and scope.

Conclusion: This is a focused, SoC-gated fix that addresses a real
interoperability bug with minimal risk. It fits stable backporting
guidelines well.

 drivers/ufs/host/ufs-mediatek.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index 3defb5f135e33..c0acbd3f8fc36 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -1503,8 +1503,19 @@ static int ufs_mtk_pre_link(struct ufs_hba *hba)
 
 	return ret;
 }
+
 static void ufs_mtk_post_link(struct ufs_hba *hba)
 {
+	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+	u32 tmp;
+
+	/* fix device PA_INIT no adapt */
+	if (host->ip_ver >= IP_VER_MT6899) {
+		ufshcd_dme_get(hba, UIC_ARG_MIB(VS_DEBUGOMC), &tmp);
+		tmp |= 0x100;
+		ufshcd_dme_set(hba, UIC_ARG_MIB(VS_DEBUGOMC), tmp);
+	}
+
 	/* enable unipro clock gating feature */
 	ufs_mtk_cfg_unipro_cg(hba, true);
 }
-- 
2.51.0