If byt_wm5102_prepare_and_enable_pll1() fails in the
SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after
clk_prepare_enable(priv->mclk) without disabling the clock again.

This leaks an MCLK enable reference on failed power-up attempts. Add the
missing clk_disable_unprepare() on the error path, matching the unwind
used by the other Intel platform_clock_control() implementations.

Fixes: 9a87fc1e0619 ("ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102")
Cc: stable@vger.kernel.org
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
 sound/soc/intel/boards/bytcr_wm5102.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/intel/boards/bytcr_wm5102.c b/sound/soc/intel/boards/bytcr_wm5102.c
index 4879f79aef29..4aa0cf49b033 100644
--- a/sound/soc/intel/boards/bytcr_wm5102.c
+++ b/sound/soc/intel/boards/bytcr_wm5102.c
@@ -170,6 +170,7 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w,
 		ret = byt_wm5102_prepare_and_enable_pll1(codec_dai, 48000);
 		if (ret) {
 			dev_err(card->dev, "Error setting codec sysclk: %d\n", ret);
+			clk_disable_unprepare(priv->mclk);
 			return ret;
 		}
 	} else {

---
base-commit: 98421d94a1a6dcc3e8582eb62bedeccecda93339
change-id: 20260427-bytcr-wm5102-mclk-leak-88016072a63c

Best regards,
--  
Cássio Gabriel <cassiogabrielcontato@gmail.com>

On Mon, 27 Apr 2026 23:38:41 -0300, Cássio Gabriel wrote:
> ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1

Thanks!

[1/1] ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error
      https://git.kernel.org/broonie/sound/c/13d30682e8de

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Hi,

On 28-Apr-26 04:38, Cássio Gabriel wrote:
> If byt_wm5102_prepare_and_enable_pll1() fails in the
> SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after
> clk_prepare_enable(priv->mclk) without disabling the clock again.
> 
> This leaks an MCLK enable reference on failed power-up attempts. Add the
> missing clk_disable_unprepare() on the error path, matching the unwind
> used by the other Intel platform_clock_control() implementations.
> 
> Fixes: 9a87fc1e0619 ("ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102")
> Cc: stable@vger.kernel.org
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>

As Andy noted there are other drivers under sound/soc/intel/boards/
which can likely benefit from a similar fix.

Regards,

Hans



> ---
>  sound/soc/intel/boards/bytcr_wm5102.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/soc/intel/boards/bytcr_wm5102.c b/sound/soc/intel/boards/bytcr_wm5102.c
> index 4879f79aef29..4aa0cf49b033 100644
> --- a/sound/soc/intel/boards/bytcr_wm5102.c
> +++ b/sound/soc/intel/boards/bytcr_wm5102.c
> @@ -170,6 +170,7 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w,
>  		ret = byt_wm5102_prepare_and_enable_pll1(codec_dai, 48000);
>  		if (ret) {
>  			dev_err(card->dev, "Error setting codec sysclk: %d\n", ret);
> +			clk_disable_unprepare(priv->mclk);
>  			return ret;
>  		}
>  	} else {
> 
> ---
> base-commit: 98421d94a1a6dcc3e8582eb62bedeccecda93339
> change-id: 20260427-bytcr-wm5102-mclk-leak-88016072a63c
> 
> Best regards,
> --  
> Cássio Gabriel <cassiogabrielcontato@gmail.com>
> 

On 2026-04-28 4:38 AM, Cássio Gabriel wrote:
> If byt_wm5102_prepare_and_enable_pll1() fails in the
> SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after
> clk_prepare_enable(priv->mclk) without disabling the clock again.
> 
> This leaks an MCLK enable reference on failed power-up attempts. Add the
> missing clk_disable_unprepare() on the error path, matching the unwind
> used by the other Intel platform_clock_control() implementations.
> 
> Fixes: 9a87fc1e0619 ("ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102")
> Cc: stable@vger.kernel.org
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> ---
>   sound/soc/intel/boards/bytcr_wm5102.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/sound/soc/intel/boards/bytcr_wm5102.c b/sound/soc/intel/boards/bytcr_wm5102.c
> index 4879f79aef29..4aa0cf49b033 100644
> --- a/sound/soc/intel/boards/bytcr_wm5102.c
> +++ b/sound/soc/intel/boards/bytcr_wm5102.c
> @@ -170,6 +170,7 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w,
>   		ret = byt_wm5102_prepare_and_enable_pll1(codec_dai, 48000);
>   		if (ret) {
>   			dev_err(card->dev, "Error setting codec sysclk: %d\n", ret);
> +			clk_disable_unprepare(priv->mclk);
>   			return ret;
>   		}
>   	} else {
> 

Thank you for the fix.

Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>

On Tue, Apr 28, 2026 at 5:38 AM Cássio Gabriel
<cassiogabrielcontato@gmail.com> wrote:
>
> If byt_wm5102_prepare_and_enable_pll1() fails in the
> SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after
> clk_prepare_enable(priv->mclk) without disabling the clock again.
>
> This leaks an MCLK enable reference on failed power-up attempts. Add the
> missing clk_disable_unprepare() on the error path, matching the unwind
> used by the other Intel platform_clock_control() implementations.

There are 6 drivers that do the same, why is only this one special?
Have you checked the flow on the error path of the caller of this
`platform_clock_control()`? Maybe there it calls with the opposite
event to shut the clock down?

...

TL;DR: If it's a real issue, it has to be fixed for all affected drivers.


-- 
With Best Regards,
Andy Shevchenko

On 4/28/26 03:55, Andy Shevchenko wrote:
> 
> There are 6 drivers that do the same, why is only this one special?
> Have you checked the flow on the error path of the caller of this
> `platform_clock_control()`? Maybe there it calls with the opposite
> event to shut the clock down?
> 
> TL;DR: If it's a real issue, it has to be fixed for all affected drivers.

Yes, I'm going to check the other drivers.

-- 
Thanks,
Cássio

On 4/28/26 07:28, Cássio Gabriel Monteiro Pires wrote:
> On 4/28/26 03:55, Andy Shevchenko wrote:
>>
>> There are 6 drivers that do the same, why is only this one special?
>> Have you checked the flow on the error path of the caller of this
>> `platform_clock_control()`? Maybe there it calls with the opposite
>> event to shut the clock down?
>>
>> TL;DR: If it's a real issue, it has to be fixed for all affected drivers.
> 
> Yes, I'm going to check the other drivers.
> 

I checked the other platform_clock_control() users under
sound/soc/intel/boards/.

The same bug pattern exists when the ON path does:

        clk_prepare_enable()
        <fallible codec PLL/sysclk setup>
        return error without clk_disable_unprepare()

The affected drivers are bytcr_rt5640, bytcr_rt5651, cht_bsw_rt5672 and
bytcr_wm5102. The first three were already fixed by a02496a29463,
b022e5c142ef and dced5a373a96. This patch fixes the remaining one.

The other two MCLK platform_clock_control() users, cht_bsw_rt5645 and
cht_bsw_max98090_ti, only enable MCLK in the ON path and do not perform a
later fallible codec-clock setup in that same path, so I do not see the
same leak there.

I also checked the DAPM event path; failed widget callbacks are logged,
but there is no opposite-event rollback guarantee that would balance the
clock enable from the failed callback.

-- 
Thanks,
Cássio

On Tue, Apr 28, 2026 at 3:13 PM Cássio Gabriel Monteiro Pires
<cassiogabrielcontato@gmail.com> wrote:
> On 4/28/26 07:28, Cássio Gabriel Monteiro Pires wrote:
> > On 4/28/26 03:55, Andy Shevchenko wrote:
> >>
> >> There are 6 drivers that do the same, why is only this one special?
> >> Have you checked the flow on the error path of the caller of this
> >> `platform_clock_control()`? Maybe there it calls with the opposite
> >> event to shut the clock down?
> >>
> >> TL;DR: If it's a real issue, it has to be fixed for all affected drivers.
> >
> > Yes, I'm going to check the other drivers.
>
> I checked the other platform_clock_control() users under
> sound/soc/intel/boards/.
>
> The same bug pattern exists when the ON path does:
>
>         clk_prepare_enable()
>         <fallible codec PLL/sysclk setup>
>         return error without clk_disable_unprepare()
>
> The affected drivers are bytcr_rt5640, bytcr_rt5651, cht_bsw_rt5672 and
> bytcr_wm5102. The first three were already fixed by a02496a29463,
> b022e5c142ef and dced5a373a96. This patch fixes the remaining one.

Thanks for confirming, I based my previous reply(ies) on v7.0 kernel,
it's good that many of the issues were fixed already.

> The other two MCLK platform_clock_control() users, cht_bsw_rt5645 and
> cht_bsw_max98090_ti, only enable MCLK in the ON path and do not perform a
> later fallible codec-clock setup in that same path, so I do not see the
> same leak there.

> I also checked the DAPM event path; failed widget callbacks are logged,
> but there is no opposite-event rollback guarantee that would balance the
> clock enable from the failed callback.

Thanks, this is useful information!

-- 
With Best Regards,
Andy Shevchenko

On 2026-04-28 8:55 AM, Andy Shevchenko wrote:
> On Tue, Apr 28, 2026 at 5:38 AM Cássio Gabriel
> <cassiogabrielcontato@gmail.com> wrote:
>>
>> If byt_wm5102_prepare_and_enable_pll1() fails in the
>> SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after
>> clk_prepare_enable(priv->mclk) without disabling the clock again.
>>
>> This leaks an MCLK enable reference on failed power-up attempts. Add the
>> missing clk_disable_unprepare() on the error path, matching the unwind
>> used by the other Intel platform_clock_control() implementations.
> 
> There are 6 drivers that do the same, why is only this one special?
> Have you checked the flow on the error path of the caller of this
> `platform_clock_control()`? Maybe there it calls with the opposite
> event to shut the clock down?
> 
> ...
> 
> TL;DR: If it's a real issue, it has to be fixed for all affected drivers.


There have been multiple reports regarding similar problem for all three 
ATOM-based generations I believe.  One of the more recent being "ASoC: 
Intel: Fix MCLK leaks and clean up error" [1].  Does not look like there 
is a single owner of that subject.


[1]: 
https://lore.kernel.org/linux-sound/20260401220507.23557-1-aravindanilraj0702@gmail.com/

Kind regards,
Czarek