Re: [PATCH] ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error

[Andy Shevchenko]

On Tue, Apr 28, 2026 at 3:13 PM Cássio Gabriel Monteiro Pires
<cassiogabrielcontato@xxxxxxxxx> 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