From nobody Sun Sep 27 20:04:00 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 591434968F6; Mon, 31 Aug 2026 13:38:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788183528; cv=none; b=f2T2+88zjl5I0XxJdhHzLhzCPOC8MaRCBnjkR48cVR7Ghl/bLLu8pqU2iIEjohq9Vpa3V22G8113RVZD4a7Tq02Z2dX5WaxjPA+UgfE0SGDTS1OLHbqxh5EFJJgJEyDhq6Kmw1OUivg4sKqECLsSqKzBAVnefvV1k1oofeG0wQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788183528; c=relaxed/simple; bh=hDVWWEqdrziYLZbomuM8rcTjqb4po1Wbb+L2oGl9z/M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Mw34QJcH2i0XEo+vgz456hs7wWnM/sbPwfzhRhOsV/XXTEJK61ppW6Vjjcq6McIfWJQ3506sW+ef+CZIaoccY9vcLAfH80sh5thb3RDijAlewKIMyyQ6Uzvx62U2su/BYy4CET5TzVjN05+lzVaTJR8AyPh2oEQ/p6gp0TzeW5k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fdr8C5gx; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fdr8C5gx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 252C11F00ACA; Mon, 31 Aug 2026 13:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788183526; bh=crpun+QCBVEcyB2Pgb0Ue25kuVuSVt9lQ+ZQUwR0CWk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=fdr8C5gxnIoIkZ9LsuYuJiSnsbzY67hcgF80AguVqYnOgwK5bjiqng7h0prP1BcGQ RSb8tFk3L9e8qJwSmizkB2QXthIR8PuFIbNj1aqh4dQMN7+br4xqxrMZwPlxE+0HCO R9bTPN6COd4zoOTg7xV45NKXBT2SSnv0L9JCGQ6QCWZvEdmj6hInL9ETMH+CIrFt0U 9ybmQUbTvpO5qFet9FJcX6CHiAlFM+cB57DfH87GqxBrQz6O56RhPBwJ57V5/2VkI3 Ss/AwtF3dXHULLkB9b52wC3NVoJyxCPxp9VII/nLUfbVfvpIzHVwHv1UUN8Gt0/V3p IK7khGgz6fIDw== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Osama Abdelkader , Ulf Hansson , Sasha Levin , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-5.10] mmc: davinci: fix mmc_add_host order in probe Date: Mon, 31 Aug 2026 09:22:57 -0400 Message-ID: <20260831133314.4125787-149-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260831133314.4125787-1-sashal@kernel.org> References: <20260831133314.4125787-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.48 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Osama Abdelkader [ Upstream commit d04e0151d316edbdb4f0397a9b92a1936e4a1421 ] mmc_add_host() makes the host visible to the MMC core. Register the interrupt handlers and advertise MMC_CAP_SDIO_IRQ before that, so the core cannot start using the host before IRQ handling is set up. Signed-off-by: Osama Abdelkader Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: # Stable Backport Analysis: `mmc: davinci: fix mmc_add_host order in probe` **Local tree:** Linux **6.18.44** (`git describe HEAD` =E2=86=92 `v6.18.44`) **Commit under review:** `d04e0151d316e` (exists in repo on `all-next` etc., **not** an ancestor of this tree=E2=80=99s HEAD) --- ## PHASE 1: COMMIT MESSAGE FORENSICS ### Step 1.1: Subject line **Record:** `[mmc: davinci]` `[fix]` =E2=80=94 correct probe initialization order so IRQ handlers and SDIO capability are ready before `mmc_add_host()`. ### Step 1.2: Tags **Record:** - **Fixes:** =E2=80=94 none - **Reported-by:** =E2=80=94 none - **Tested-by:** =E2=80=94 none - **Reviewed-by:** =E2=80=94 none - **Acked-by:** =E2=80=94 none - **Link:** =E2=80=94 none in commit message - **Cc: stable@vger.kernel.org** =E2=80=94 none (expected for manual review) - **Signed-off-by:** Osama Abdelkader `` (author) - **Signed-off-by:** Ulf Hansson `` (MMC maintainer merge) Notable: maintainer Signed-off-by; no syzbot/user bug report. ### Step 1.3: Body analysis **Record:** - **Bug:** `mmc_add_host()` exposes the host to the MMC core before IRQ handlers are registered and before `MMC_CAP_SDIO_IRQ` is advertised. - **Symptom:** MMC core may start card detection / I/O while interrupts are not handled =E2=86=92 requests can hang or SDIO IRQ support is mis- advertised. - **Root cause:** Wrong probe ordering; `mmc_add_host()` should be last among setup steps that the core depends on. - **Version info:** none in message. ### Step 1.4: Hidden bug fix? **Record:** No =E2=80=94 this is an explicit probe-order bug fix, not disgu= ised cleanup. --- ## PHASE 2: DIFF ANALYSIS ### Step 2.1: Inventory **Record:** - **File:** `drivers/mmc/host/davinci_mmc.c` (+5 / =E2=88=927 lines) - **Function:** `davinci_mmcsd_probe()` - **Scope:** Single-file surgical fix ### Step 2.2: Code flow per hunk **Record:** 1. **Remove early `mmc_add_host()`** =E2=80=94 before: host registered with= core immediately after cpufreq setup =E2=86=92 after: deferred until IRQ setup completes. 2. **IRQ failure path** =E2=80=94 before: `goto request_irq_fail` =E2=86=92 `mmc_remove_host()` =E2=86=92 after: `goto mmc_add_host_fail` (host was = never added). 3. **Move `mmc_add_host()` after IRQ registration** =E2=80=94 SDIO IRQ hand= ler registered and `MMC_CAP_SDIO_IRQ` set first, then host registered. 4. **Remove `request_irq_fail` label** =E2=80=94 no longer needed since `mmc_add_host()` hasn=E2=80=99t run yet. ### Step 2.3: Bug mechanism **Record:** **Race condition / initialization ordering bug** - `mmc_add_host()` =E2=86=92 `mmc_start_host()` =E2=86=92 `_mmc_detect_chan= ge(host, 0, false)` schedules card-detection work immediately. - Before fix: detection can issue `mmc_davinci_request()` while `devm_request_irq()` for `mmc_davinci_irq` is not yet registered. - Command completion depends on `mmc_davinci_irq()` (interrupt-driven; `mmc_davinci_start_command()` enables `DAVINCI_MMCIM` interrupt mask). - SDIO: `MMC_CAP_SDIO_IRQ` was set after `mmc_add_host()`, so core could probe SDIO before capability was advertised. ### Step 2.4: Fix quality **Record:** - **Obviously correct:** matches established MMC driver pattern (`sdhci.c`, `omap_hsmmc.c`, and prior fixes like `mmc: uniphier-sd: register irqs before registering controller`). - **Minimal:** pure reorder + simplified error path. - **Regression risk:** very low; only changes probe ordering and removes unnecessary `mmc_remove_host()` on IRQ failure. --- ## PHASE 3: GIT HISTORY INVESTIGATION ### Step 3.1: Blame **Record:** Buggy order introduced in **2009** (`b4cff4549b7a8c`, Vipin Bhandari). `mmc_add_host()` before `devm_request_irq()` has been wrong since initial davinci driver integration. `PROBE_PREFER_ASYNCHRONOUS` added in `21b2cec61c04b` (2020), increasing realistic race window with async detect work. ### Step 3.2: Fixes: tag **Record:** N/A =E2=80=94 no Fixes: tag. ### Step 3.3: Related file history **Record:** Same class of fix already in tree history: - `a5d8de1cb7e1d` =E2=80=94 `mmc: uniphier-sd: register irqs before registe= ring controller` - `74f45de394d97` =E2=80=94 `mmc: renesas_sdhi: register irqs before regist= ering controller` Standalone one-patch fix; not part of a series. ### Step 3.4: Author context **Record:** Osama Abdelkader is an active contributor (e.g. Panthor DRM fixes) but not davinci maintainer. Fix merged by Ulf Hansson (MMC subsystem maintainer). ### Step 3.5: Dependencies **Record:** No prerequisites. Self-contained reorder in existing probe function. Applies standalone. --- ## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH ### Step 4.1: Original discussion **Record:** - **URL:** https://lkml.iu.edu/hypermail/linux/kernel/2605.1/03199.html - **Revisions:** single patch (no v2/v3 found) - **Maintainer response:** Ulf Hansson =E2=80=94 =E2=80=9CApplied for next,= thanks!=E2=80=9D (https://lists.openwall.net/linux-kernel/2026/05/29/1414) - **Stable nomination:** none in thread - **NAKs/concerns:** none found ### Step 4.2: Reviewers **Record:** CC=E2=80=99d to `linux-mmc@`, `linux-kernel@`, Ulf Hansson, and other maintainers. Accepted by subsystem maintainer without objections. ### Step 4.3: Bug report **Record:** No external bug report, syzbot, or stack trace. Bug identified by code inspection / correct driver pattern. ### Step 4.4: Related patches **Record:** Precedent patches in same subsystem (uniphier-sd, renesas_sdhi) for identical IRQ-before-`mmc_add_host` ordering. ### Step 4.5: Stable list **Record:** No stable-list discussion found (lore.kernel.org blocked by bot protection for direct search; patch thread has no stable Cc). --- ## PHASE 5: CODE SEMANTIC ANALYSIS ### Step 5.1: Key functions **Record:** `davinci_mmcsd_probe()`, `mmc_add_host()`, `mmc_start_host()`, `_mmc_detect_change()`, `mmc_davinci_irq()`, `mmc_davinci_request()`, `mmc_davinci_start_command()` ### Step 5.2: Callers **Record:** - `davinci_mmcsd_probe()` =E2=80=94 platform driver probe during boot / mod= ule load on `ARCH_DAVINCI` boards. - `mmc_add_host()` =E2=86=92 `mmc_start_host()` =E2=86=92 card detection wo= rkqueue. - `mmc_davinci_request()` =E2=80=94 MMC core callback during card init and = I/O. ### Step 5.3: Callees **Record:** `mmc_add_host()` calls `device_add()`, `mmc_start_host()`; probe uses `devm_request_irq()`, `mmc_davinci_cpufreq_register()`. ### Step 5.4: Reachability **Record:** - Triggered on every DaVinci MMC controller probe with a card present (or during rescan). - Card detection is scheduled from `mmc_start_host()` with **zero delay** (`_mmc_detect_change(host, 0, false)`). - Requests issued before IRQ registration can hang waiting for interrupts that have no handler. - **Userspace reachability:** indirect via boot-time device enumeration; can cause hung boot / unresponsive MMC block device. ### Step 5.5: Similar patterns **Record:** `sdhci.c` (request IRQ at ~4883, `mmc_add_host` at ~4898), `omap_hsmmc.c` (IRQ + `MMC_CAP_SDIO_IRQ` before `mmc_add_host` at ~1944). Davinci was the outlier. --- ## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE (6.18.44) ### Step 6.1: Buggy code present? **Record:** **YES.** Current `drivers/mmc/host/davinci_mmc.c` at lines 1297=E2=80=931312 still has `mmc_add_host()` before `devm_request_irq()`. F= ix commit `d04e0151d316e` is **not** in HEAD (`git merge-base --is- ancestor` =E2=86=92 NOT ancestor). ### Step 6.2: Backport complications **Record:** **Clean apply expected.** Probe structure matches the patch context; no conflicting recent churn in that hunk. `request_irq_fail` / `mmc_remove_host` path still present and removable as in the patch. ### Step 6.3: Related fixes already present? **Record:** uniphier-sd and renesas_sdhi IRQ-ordering fixes are in tree; davinci-specific fix is **not**. --- ## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT ### Step 7.1: Subsystem criticality **Record:** **PERIPHERAL** =E2=80=94 `CONFIG_MMC_DAVINCI` (`ARCH_DAVINCI || COMPILE_TEST`). TI DaVinci embedded platforms (e.g. DM644x, OMAP-L138 class). Small user base but real production embedded deployments. ### Step 7.2: Subsystem activity **Record:** davinci driver receives periodic maintenance (PM macros, devm helpers, bus-width reporting in 2024=E2=80=932025) but is mature/legac= y. --- ## PHASE 8: IMPACT AND RISK ASSESSMENT ### Step 8.1: Who is affected **Record:** Users building kernels with `CONFIG_MMC_DAVINCI=3Dy/m` on DaVinci hardware. Not universal; driver-specific. ### Step 8.2: Trigger conditions **Record:** - Boot or module load with MMC/SD/SDIO media present. - Race between `mmc_start_host()` detect work and remaining probe steps. - More likely since `PROBE_PREFER_ASYNCHRONOUS` (2020). - Unprivileged users cannot directly trigger; impact is at boot/enumeration. ### Step 8.3: Failure mode severity **Record:** - **Hung MMC requests** / boot stall during card detection =E2=86=92 **HIGH= ** for affected hardware. - **SDIO IRQ not advertised** =E2=86=92 SDIO Wi=E2=80=91Fi/BT modules may f= ail =E2=86=92 **HIGH** for SDIO users. - Not a typical security issue; no data-corruption mechanism identified, but boot hang is a serious stability issue. ### Step 8.4: Risk-benefit **Record:** - **Benefit:** Prevents probe-time hangs and SDIO capability mis- registration on DaVinci boards; aligns with maintainer-accepted pattern used in sibling drivers. - **Risk:** Very low =E2=80=94 12-line reorder, no API changes, simpler err= or path. - **Ratio:** Favorable for backport despite narrow hardware scope. --- ## PHASE 9: FINAL SYNTHESIS ### Step 9.1: Evidence summary **FOR backport:** - Real initialization race with concrete mechanism (`mmc_start_host` =E2=86= =92 immediate detect work). - IRQ-dependent request completion in `mmc_davinci_irq()`. - SDIO capability must be set before host registration. - Identical fixes already accepted in MMC subsystem (uniphier-sd, renesas_sdhi). - Matches omap_hsmmc/sdhci canonical ordering. - Tiny, obviously correct, maintainer-merged. - Bug present in 6.18.44; fix not yet applied. **AGAINST backport:** - Very small user population (`ARCH_DAVINCI` only). - No user bug report or syzbot reproduction. - Theoretical race existed since 2009 (may have been rare on synchronous probe). **Unresolved:** No field crash log confirming reproduction on specific DaVinci board (not required for this class of fix). ### Step 9.2: Stable rules checklist 1. Obviously correct and tested? **PASS** =E2=80=94 pattern proven in other= MMC drivers; maintainer merged. 2. Fixes a real bug? **PASS** =E2=80=94 probe ordering race verified in cod= e. 3. Important issue? **PASS** =E2=80=94 boot hang / MMC timeout on affected hardware (HIGH for those users). 4. Small and contained? **PASS** =E2=80=94 1 file, 12 lines. 5. No new features/APIs? **PASS** =E2=80=94 reorder only. 6. Can apply to local tree? **PASS** =E2=80=94 buggy code present; patch sh= ould apply cleanly. ### Step 9.3: Exception categories **Record:** None (not device ID, quirk, DT, build, or docs). Standard driver probe-order bug fix. ### Step 9.4: Decision rationale For **Linux 6.18.44**, this commit fixes a verified probe race in an existing driver where the buggy code is present and the fix is absent. While the hardware audience is narrow, boot-time hangs on embedded systems are exactly the sort of contained, low-risk driver fixes stable trees routinely take=E2=80=94especially when the MMC maintainer has already accepted the same pattern for other host drivers. The patch is minimal, follows established subsystem practice, and introduces negligible regression risk. --- ## Verification - **[Phase 1]** Parsed subject, tags, body from provided commit message. - **[Phase 1]** Confirmed no Reported-by/Tested-by/Fixes/Link tags. - **[Phase 2]** Diff analysis: reorder `mmc_add_host()` after IRQ setup; remove `request_irq_fail` path. - **[Phase 2]** Read `mmc_add_host()` in `drivers/mmc/core/host.c:644-661` =E2=80=94 calls `mmc_start_host()`. - **[Phase 2]** Read `mmc_start_host()` / `_mmc_detect_change()` in `drivers/mmc/core/core.c:2338-2353,1441-1452` =E2=80=94 schedules detect = work with delay 0. - **[Phase 2]** Read `davinci_mmcsd_probe()` buggy ordering at `davinci_mmc.c:1297-1328`. - **[Phase 2]** Read `mmc_davinci_irq()` and `mmc_davinci_request()` =E2=80= =94 IRQ-driven completion path. - **[Phase 3]** `git blame -L 1290,1330 drivers/mmc/host/davinci_mmc.c` =E2=80=94 buggy order since 2009. - **[Phase 3]** `git show 21b2cec61c04b` =E2=80=94 `PROBE_PREFER_ASYNCHRONO= US` on davinci since 2020. - **[Phase 3]** `git log --oneline` =E2=80=94 found precedent commits `a5d8de1cb7e1d`, `74f45de394d97`. - **[Phase 3]** `git show a5d8de1cb7e1d` =E2=80=94 confirmed identical rati= onale for uniphier-sd. - **[Phase 4]** WebFetch lkml.iu.edu patch submission =E2=80=94 original pa= tch found. - **[Phase 4]** WebFetch lists.openwall.net =E2=80=94 Ulf Hansson =E2=80=9C= Applied for next, thanks!=E2=80=9D - **[Phase 4]** `b4 dig -c HEAD` =E2=80=94 failed (commit not in HEAD); `b4= dig -l` =E2=80=94 unsupported syntax. - **[Phase 5]** Compared `omap_hsmmc.c:1916-1946` and `sdhci.c:4883-4898` =E2=80=94 IRQ before `mmc_add_host`. - **[Phase 5]** Read `Kconfig` `CONFIG_MMC_DAVINCI` =E2=80=94 `ARCH_DAVINCI= || COMPILE_TEST`. - **[Phase 6]** `git describe HEAD` =E2=86=92 `v6.18.44`. - **[Phase 6]** `git merge-base --is-ancestor d04e0151d316e HEAD` =E2=86=92= fix **NOT** in tree. - **[Phase 6]** Grep confirmed buggy probe order still present in checked-out tree. - **[Phase 6]** `git show d04e0151d316e` =E2=80=94 verified commit exists a= nd matches provided diff. - **[Phase 7]** `git log --oneline -20 -- drivers/mmc/host/davinci_mmc.c` =E2=80=94 driver actively maintained. - **[Phase 8]** Assessed impact limited to `ARCH_DAVINCI` with boot-time hang severity for those users. **YES** drivers/mmc/host/davinci_mmc.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c index 00adc15956fd2..3d0d05ab1fe48 100644 --- a/drivers/mmc/host/davinci_mmc.c +++ b/drivers/mmc/host/davinci_mmc.c @@ -1294,14 +1294,10 @@ static int davinci_mmcsd_probe(struct platform_devi= ce *pdev) goto cpu_freq_fail; } =20 - ret =3D mmc_add_host(mmc); - if (ret < 0) - goto mmc_add_host_fail; - ret =3D devm_request_irq(&pdev->dev, irq, mmc_davinci_irq, 0, mmc_hostname(mmc), host); if (ret) - goto request_irq_fail; + goto mmc_add_host_fail; =20 if (host->sdio_irq >=3D 0) { ret =3D devm_request_irq(&pdev->dev, host->sdio_irq, @@ -1311,6 +1307,10 @@ static int davinci_mmcsd_probe(struct platform_devic= e *pdev) mmc->caps |=3D MMC_CAP_SDIO_IRQ; } =20 + ret =3D mmc_add_host(mmc); + if (ret < 0) + goto mmc_add_host_fail; + rename_region(mem, mmc_hostname(mmc)); =20 if (mmc->caps & MMC_CAP_8_BIT_DATA) @@ -1324,8 +1324,6 @@ static int davinci_mmcsd_probe(struct platform_device= *pdev) =20 return 0; =20 -request_irq_fail: - mmc_remove_host(mmc); mmc_add_host_fail: mmc_davinci_cpufreq_deregister(host); cpu_freq_fail: --=20 2.53.0