Re: [PATCH v4 0/5] ASoC: Intel: Convert locking to guard()/scoped_guard()

[Bui Duc Phuc]

On Mon, Jun 29, 2026 at 8:25 PM Cezary Rojewski
<cezary.rojewski@xxxxxxxxx> wrote:
>

>
> The CI is run for entire patchset.
>

> Cannot share the details but I'm talking about actual long-term-support
> CI with large amount of corporate resources invested.  A lab, high
> number of physical setups with intention to cover every Intel's AudioDSP
> architecture version (starting from Haswell) and streaming-interface
> type (HDAudio, DMIC etc.).
>
> All functional tests are fully automated - imitate every single scenario
> we do expose for our clients, regardless of the OS type.  While again, I
> cannot list the tests, the basics are quite simple - bucket the
> "functions" e.g.: system states (SXes), device states (DXes),
> multi-threading, clocking (the list goes on) and do: atomic test and
> then a combination for each feature from each bucket (if valid).
> Incomplete example for basic playback:
>
> - 1x default endpoint pb before s3
> - 1x default endpoint pb during s3
> - 1x default endpoint pb after s3
> - 1x default endpoint pb before s4
> - 1x default endpoint pb during s4
> - 1x default endpoint pb after s4
>
> Wait, does that mean the tests go in thousands?  Yeah, several thousands.
>
> However, without such investment, people like me would not be able to
> propose and provide reliable contributions for Intel and ASoC both.
>

Thanks for the detailed explanation.

That sounds like a very impressive CI infrastructure. Having such a well-funded
and comprehensive validation system is clearly a huge advantage when developing
and reviewing patches. Running thousands of functional scenarios
across different
DSP generations and streaming interfaces certainly gives much higher confidence
in changes.

That said, it also made me think about the `sst_media_open()` case.
Unless I misunderstood something, the CI didn't catch the memory leak
caused by `kfree(stream)` when `snd_pcm_hw_constraint_integer()`
returns an error.
That issue only became apparent while doing the cleanup work.

So perhaps the patch  ASoC: intel: atom: Use __free(kfree) for stream pointer
 is not merely a cleanup patch after all—it also fixes a real memory leak.

Out of curiosity, has this function been covered by the CI before?
Or is this simply one of those corner cases that are difficult to exercise,
even with such extensive functional testing?

Best regards,
Phuc