From: Aravind Anilraj <aravindanilraj0702@gmail.com>

In three Intel ASoC board drivers, the EVENT_ON path in
platform_clock_control() enables MCLK using clk_prepare_enable(), but
error paths fail to call clk_disable_unprepare(), leaking a clock
reference.

Fix this by calling a clk_disable_unprepare() on error paths after MCLK
has been enabled.

v2: Guard clk_disable_unprepare() with SND_SOC_DAPM_EVENT_ON() to avoid
callling it in the EVENT_OFF error path where MCLK was never enabled.

v3: Restored missing clk_disable_unprepare() guard in patch 2 that 
was accidentally dropped during v2 rebase.

Aravind Anilraj (3):
  ASoC: Intel: bytcr_rt5640: Fix MCLK leak on platform_clock_control
    error
  ASoC: Intel: bytcr_rt5651: Fix MCLK leak on platform_clock_control
    error
  ASoC: Intel: cht_bsw_rt5672: Fix MCLK leak in platform_clock_control

 sound/soc/intel/boards/bytcr_rt5640.c   | 2 ++
 sound/soc/intel/boards/bytcr_rt5651.c   | 4 +++-
 sound/soc/intel/boards/cht_bsw_rt5672.c | 4 +++-
 3 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.47.3

On Fri, Mar 27, 2026 at 05:04:05PM -0400, aravindanilraj0702@gmail.com wrote:
> From: Aravind Anilraj <aravindanilraj0702@gmail.com>
> 
> In three Intel ASoC board drivers, the EVENT_ON path in
> platform_clock_control() enables MCLK using clk_prepare_enable(), but
> error paths fail to call clk_disable_unprepare(), leaking a clock
> reference.

Please don't send new patches in reply to old patches or serieses, this
makes it harder for both people and tools to understand what is going
on - it can bury things in mailboxes and make it difficult to keep track
of what current patches are, both for the new patches and the old ones.

Please don't ignore review comments, people are generally making them
for a reason and are likely to have the same concerns if issues remain
unaddressed.  Having to repeat the same comments can get repetitive and
make people question the value of time spent reviewing.  If you disagree
with the review comments that's fine but you need to reply and discuss
your concerns so that the reviewer can understand your decisions.

Hi Mark,

Thanks for the feedback.

Apologies for the confusion — I sent multiple revisions in quick
succession and incorrectly threaded the newer version as a reply to
the earlier series. I understand this makes tracking harder.

In v4, I have:
Split unrelated changes into a separate patch
Added return codes to dev_err() messages as suggested

I will send future revisions as a new thread instead of replying to
older series.

Thanks for the review.

Regards,
Aravind



On Sat, Mar 28, 2026 at 2:36 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Mar 27, 2026 at 05:04:05PM -0400, aravindanilraj0702@gmail.com wrote:
> > From: Aravind Anilraj <aravindanilraj0702@gmail.com>
> >
> > In three Intel ASoC board drivers, the EVENT_ON path in
> > platform_clock_control() enables MCLK using clk_prepare_enable(), but
> > error paths fail to call clk_disable_unprepare(), leaking a clock
> > reference.
>
> Please don't send new patches in reply to old patches or serieses, this
> makes it harder for both people and tools to understand what is going
> on - it can bury things in mailboxes and make it difficult to keep track
> of what current patches are, both for the new patches and the old ones.
>
> Please don't ignore review comments, people are generally making them
> for a reason and are likely to have the same concerns if issues remain
> unaddressed.  Having to repeat the same comments can get repetitive and
> make people question the value of time spent reviewing.  If you disagree
> with the review comments that's fine but you need to reply and discuss
> your concerns so that the reviewer can understand your decisions.