From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 57DDD3AEF33; Mon, 20 Apr 2026 13:33:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776692012; cv=none; b=P9Nyj8eZ4WYOlECrVnqAz7ffQ0Y6e0+fLxBWEwhPabjNvq8tO/PvDjSEJ7b65goVcdXyrltDXhn/buzyVYiITKWovJVD03tQjw63Moqr27er8JPbppKBbL9kRswIwAUnfOp0xEUrkAr2YbU11HHQmJPY0MrfMkUCkH7r+ZRGL5g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776692012; c=relaxed/simple; bh=mUB1+2XeNXvrylir1UxSDqUc9JqXkWKgZ+TQoWheyXE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IktzHMr/j/xyzjOlSQ87A+r+BdLEjRB+3jiNRKZSqi0ismqYzzh3aJo7w7jhWE+pz281mwjrPrNkrzGq8FiPXtFjt6G7/QjjmkoxzybATYzgvmdC6zVwdbY7lIdTJuTm78B9HXTxjJd2avCv9ITdzFMV5PHd8SaVMceYBf4THyE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kp2+PZuK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kp2+PZuK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A2B8C2BCB6; Mon, 20 Apr 2026 13:33:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776692012; bh=mUB1+2XeNXvrylir1UxSDqUc9JqXkWKgZ+TQoWheyXE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kp2+PZuK9nz1IiOuoEdPzrfEOGgT0o/iGgm48mcxsNtrJeE5/kyKdRvFruMrMv/3U Y8Gf1S6+xsyNfu4sEmA5wdZ2g4KJwugOZUIPgrkVJPunmn2gmpsW3sc/RR/K8UsTC2 ojxwwIvGRPTPRD1DrclDk1W+bH4Op++XOWDupjgof0ztrLLeyH6uMuz+tW1VHnkURc 2aW9b6lMtG4qOCJhjVdxWSksL58WSAjjtsqFSlPds8mel9IG+dFrXi6OKJiqdXgusc T0MrOmapx9Ut51F765gztfyXJwR79KzlN3S+KmgojD5zelxtb+kUJ9e8BHgZempKWW vxLjG9GGKzxVg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Aravind Anilraj , Cezary Rojewski , Mark Brown , Sasha Levin , liam.r.girdwood@linux.intel.com, peter.ujfalusi@linux.intel.com, yung-chuan.liao@linux.intel.com, ranjani.sridharan@linux.intel.com, kai.vehmanen@linux.intel.com, perex@perex.cz, tiwai@suse.com, linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 7.0-5.10] ASoC: Intel: bytcr_rt5640: Fix MCLK leak on platform_clock_control error Date: Mon, 20 Apr 2026 09:21:55 -0400 Message-ID: <20260420132314.1023554-321-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org> References: <20260420132314.1023554-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 7.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Aravind Anilraj [ Upstream commit a02496a29463e7f0d1643e83aab28adb3dd03f1a ] If byt_rt5640_prepare_and_enable_pll1() fails, the function returns without calling clk_disable_unprepare() on priv->mclk, which was already enabled earlier in the same code path. Add the missing cleanup call to prevent the clock from leaking. Signed-off-by: Aravind Anilraj Reviewed-by: Cezary Rojewski Link: https://patch.msgid.link/20260401220507.23557-2-aravindanilraj0702@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Now I have all the information needed for a comprehensive analysis. Let me compile the findings. --- ## PHASE 1: COMMIT MESSAGE FORENSICS **Step 1.1: Subject Line** - Subsystem: `ASoC: Intel: bytcr_rt5640` - Action verb: **Fix** (explicit bug fix) - Summary: Fix MCLK clock leak on `platform_clock_control` error path. **Step 1.2: Tags** - `Signed-off-by: Aravind Anilraj ` - Author - `Reviewed-by: Cezary Rojewski ` - Intel audio developer reviewed - `Link: https://patch.msgid.link/20260401220507.23557-2- aravindanilraj0702@gmail.com` - Lore link - `Signed-off-by: Mark Brown ` - Merged by ASoC subsystem maintainer - No Fixes: tag (expected for this review pipeline) - No Cc: stable (expected) **Step 1.3: Commit Body** The body clearly describes the bug: When `byt_rt5640_prepare_and_enable_pll1()` fails, the function returns without calling `clk_disable_unprepare()` on `priv->mclk`, which was already enabled by `clk_prepare_enable()`. This is a textbook resource leak on an error path. **Step 1.4: Hidden Bug Fix Detection** Not hidden — this is explicitly labeled as a fix. The word "Fix" is in the subject, and the mechanism (clock leak) is clearly described. Record: [ASoC Intel bytcr_rt5640] [fix] [MCLK clock leak on PLL1 enable error path] [Not a hidden fix - explicitly labeled] --- ## PHASE 2: DIFF ANALYSIS **Step 2.1: Inventory** - 1 file changed: `sound/soc/intel/boards/bytcr_rt5640.c` - +2 lines added (only) - Function modified: `platform_clock_control()` - Scope: Single-file surgical fix, extremely minimal **Step 2.2: Code Flow Change** Before: If `byt_rt5640_prepare_and_enable_pll1()` fails at line 291, `ret < 0`, the function falls through to line 305 and returns the error, but `priv->mclk` remains enabled (was enabled at line 286). After: If `byt_rt5640_prepare_and_enable_pll1()` fails, `clk_disable_unprepare(priv->mclk)` is called immediately, releasing the clock before the error return. **Step 2.3: Bug Mechanism** Category: **Error path / resource leak fix**. The clock was enabled via `clk_prepare_enable()` but not cleaned up on failure of the subsequent PLL1 setup. This is a classic missing-cleanup-on-error pattern. **Step 2.4: Fix Quality** - Obviously correct: YES. The symmetry is clear — `clk_prepare_enable()` succeeded, so on failure we must call `clk_disable_unprepare()`. - Minimal/surgical: YES. Only 2 lines added. - Regression risk: Extremely low. The added code only runs on the error path when PLL1 setup fails. Record: [1 file, +2 lines, platform_clock_control()] [Resource leak fix: MCLK left enabled on PLL1 failure] [Obviously correct, zero regression risk] --- ## PHASE 3: GIT HISTORY INVESTIGATION **Step 3.1: Blame** The buggy code pattern was introduced by commit `bcd9a325f0b0f4` (Hans de Goede, 2018-05-08): "ASoC: Intel: bytcr_rt5640: Configure PLL1 before using it". This commit added the `byt_rt5640_prepare_and_enable_pll1()` call after `clk_prepare_enable()` but failed to add cleanup on its failure path. The MCLK handling was further cleaned up by commit `a15ca6e3b8a21f` (Andy Shevchenko, 2021-10-07), which removed the `BYT_RT5640_MCLK_EN` quirk guard but preserved the same missing-cleanup bug. **Step 3.2: Fixes Tag** No Fixes: tag present (expected). The root cause commit is `bcd9a325f0b0f4` from 2018. Verified present in v6.1, v6.6, and all active stable trees. **Step 3.3: File History** Recent changes to the file are mostly DMI quirk additions and cosmetic refactoring. No conflicting changes to the `platform_clock_control()` function. **Step 3.4: Author** Aravind Anilraj has no other commits in this tree — likely a new contributor. However, the patch was reviewed by Cezary Rojewski (Intel audio team) and merged by Mark Brown (ASoC maintainer), providing strong quality assurance. **Step 3.5: Dependencies** None. The fix is 2 self-contained lines. No new functions, structures, or APIs involved. Record: [Bug introduced 2018 in bcd9a325f0b0f4, present in all stable trees] [Reviewed by Intel developer, merged by ASoC maintainer] [Standalone fix, no dependencies] --- ## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH **Step 4.1-4.2**: Lore was inaccessible due to anti-bot protections. However, the `Link:` tag confirms this was submitted and reviewed via normal mailing list processes. The `Reviewed-by: Cezary Rojewski` (Intel audio) confirms expert review. Mark Brown (ASoC maintainer) merged it. **Step 4.3**: No Reported-by tag — this was found by code inspection, not a user report. **Step 4.4**: The same bug exists in sibling driver `bytcr_rt5651.c` (lines 206-231) — identical pattern of `clk_prepare_enable()` followed by `byt_rt5651_prepare_and_enable_pll1()` without cleanup on failure. This confirms it's a systematic, real bug. Record: [Reviewed by Intel audio developer, merged by ASoC maintainer] [Same bug pattern confirmed in sibling driver bytcr_rt5651] --- ## PHASE 5: CODE SEMANTIC ANALYSIS **Step 5.1**: Function modified: `platform_clock_control()` **Step 5.2: Callers** `platform_clock_control` is registered as a DAPM supply widget callback: ```340:350:sound/soc/intel/boards/bytcr_rt5640.c SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0, platform_clock_control, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), ``` This is called by the DAPM framework every time audio playback/capture starts or stops — a **common, hot path** for any Bay Trail tablet/laptop user. **Step 5.3-5.4**: `byt_rt5640_prepare_and_enable_pll1()` calls `snd_soc_dai_set_pll()` and `snd_soc_dai_set_sysclk()`, both of which can fail (e.g., codec communication error). The leak path is reachable from normal audio usage. **Step 5.5**: Identical bug pattern exists in `bytcr_rt5651.c` (confirmed via grep). Record: [platform_clock_control called on every audio start/stop via DAPM] [Bug reachable from normal user audio usage] [Same pattern in sibling driver] --- ## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS **Step 6.1**: Verified that both the root cause commit `bcd9a325f0b0f4` (2018) and the MCLK refactor `a15ca6e3b8a21f` (2021) are ancestors of v6.1 and v6.6. The buggy code exists in **all active stable trees**. **Step 6.2**: The only potential backport complication is commit `e6995aa816557` (DAPM API conversion, Nov 2025), which changed line 276 from the old DAPM API to the new one. This commit is only in v6.19+. For v6.1/v6.6/v6.12/v6.18, the context may differ slightly on line 276, but the fix (+2 lines after line 291) is so localized it should apply cleanly or with trivial fuzz. **Step 6.3**: No related fixes already in stable for this issue. Record: [Bug exists in all active stable trees v6.1+] [Clean apply or trivial fuzz expected] [No existing fixes in stable] --- ## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT **Step 7.1**: Subsystem: `sound/soc/intel/boards` — Intel ASoC machine drivers. Criticality: **IMPORTANT**. Bay Trail RT5640/RT5651 is used on many x86 tablets and low-cost laptops (Asus T100, Lenovo IdeaPad, various Atom-based devices). **Step 7.2**: The file has moderate activity (DMI quirks being added regularly, confirming active hardware user base). Record: [ASoC Intel Bay Trail boards] [IMPORTANT — real hardware with active users] --- ## PHASE 8: IMPACT AND RISK ASSESSMENT **Step 8.1**: Affected: Users of Intel Bay Trail devices with RT5640 codec (common Atom-based tablets and laptops). **Step 8.2**: Trigger: Every audio playback start when `byt_rt5640_prepare_and_enable_pll1()` fails (e.g., I2C communication error with codec). The clock leak accumulates — each failure leaves MCLK enabled, potentially causing power management issues and preventing the clock from being properly reused. **Step 8.3**: Severity: **MEDIUM-HIGH**. Clock resource leak can cause: - Power management problems (clock stays active preventing deeper sleep states) - Potential clock framework warnings/errors on subsequent audio operations - Accumulated leaks over time **Step 8.4**: Risk-Benefit: - BENEFIT: Fixes a real resource leak in a commonly-used audio driver on real hardware - RISK: Extremely low — 2 lines added to an error path only, obviously correct symmetry with `clk_prepare_enable`/`clk_disable_unprepare` - Ratio: **Very favorable** Record: [Bay Trail device users] [Triggered on PLL1 failure during audio start] [Clock leak -> power management issues] [Extremely low risk, moderate-high benefit] --- ## PHASE 9: FINAL SYNTHESIS **Step 9.1: Evidence Summary** FOR backporting: - Fixes a real resource leak (clock not unprepared on error path) - Tiny, surgical fix: only +2 lines - Obviously correct: symmetric cleanup of `clk_prepare_enable()` - Reviewed by Intel audio developer (Cezary Rojewski) - Merged by ASoC maintainer (Mark Brown) - Bug has existed since 2018, present in all stable trees - Affects real hardware (Bay Trail tablets/laptops) - Same bug pattern confirmed in sibling driver (bytcr_rt5651) - No dependencies, self-contained fix AGAINST backporting: - No user-reported symptoms (found by code inspection) - Minor context conflict possible on older stable trees (trivially resolvable) **Step 9.2: Stable Rules Checklist** 1. Obviously correct and tested? **YES** — reviewed by Intel, symmetric cleanup pattern 2. Fixes a real bug? **YES** — clock resource leak on error path 3. Important issue? **YES** — resource leak affecting power management on real devices 4. Small and contained? **YES** — 2 lines, single file, single function 5. No new features or APIs? **YES** — purely a bug fix 6. Can apply to stable? **YES** — clean or trivial fuzz **Step 9.3: Exception Categories** Not an exception case — this is a straightforward bug fix. **Step 9.4: Decision** This is a textbook stable-worthy fix: tiny, obviously correct, fixes a real resource leak in a driver used on real hardware, with expert review. The risk is near zero. --- ## Verification - [Phase 1] Parsed tags: Reviewed-by Cezary Rojewski (Intel), Link to lore, Signed-off-by Mark Brown (maintainer) - [Phase 2] Diff analysis: +2 lines in error path of `platform_clock_control()`, adds missing `clk_disable_unprepare()` after `byt_rt5640_prepare_and_enable_pll1()` failure - [Phase 3] git blame: Bug introduced by `bcd9a325f0b0f4` (Hans de Goede, 2018), MCLK refactored by `a15ca6e3b8a21f` (Andy Shevchenko, 2021) - [Phase 3] `git merge-base --is-ancestor`: Both root cause commits verified present in v6.1 and v6.6 - [Phase 3] Author check: New contributor, but patch reviewed by Intel developer and merged by ASoC maintainer - [Phase 4] Lore inaccessible (anti-bot), but Link: tag confirms normal review process - [Phase 5] DAPM widget registration confirmed: `platform_clock_control` called on every audio PMU/PMD event — common path - [Phase 5] Grep confirmed identical bug pattern in sibling `bytcr_rt5651.c` (lines 206-231) - [Phase 6] `e6995aa816557` (DAPM conversion) only in v6.19+; fix context should apply cleanly to v6.1-v6.18 with trivial fuzz at most - [Phase 6] No existing fixes for this issue in stable - [Phase 8] Failure mode: Clock resource leak on audio error path, severity MEDIUM-HIGH **YES** sound/soc/intel/boards/bytcr_rt5640.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 103e0b445603f..e4c21c9c5b38c 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -289,6 +289,8 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w, return ret; } ret = byt_rt5640_prepare_and_enable_pll1(codec_dai, 48000); + if (ret < 0) + clk_disable_unprepare(priv->mclk); } else { /* * Set codec clock source to internal clock before -- 2.53.0