[PATCH AUTOSEL 7.0-5.10] ASoC: Intel: bytcr_rt5640: Fix MCLK leak on platform_clock_control error
From: Sasha Levin
Date: Mon Apr 20 2026 - 12:15:40 EST
From: Aravind Anilraj <aravindanilraj0702@xxxxxxxxx>
[ 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 <aravindanilraj0702@xxxxxxxxx>
Reviewed-by: Cezary Rojewski <cezary.rojewski@xxxxxxxxx>
Link: https://patch.msgid.link/20260401220507.23557-2-aravindanilraj0702@xxxxxxxxx
Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
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 <aravindanilraj0702@xxxxxxxxx>` -
Author
- `Reviewed-by: Cezary Rojewski <cezary.rojewski@xxxxxxxxx>` - Intel
audio developer reviewed
- `Link: https://patch.msgid.link/20260401220507.23557-2-
aravindanilraj0702@xxxxxxxxx` - Lore link
- `Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>` - 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