Re: [PATCH v4 0/5] ASoC: Intel: Convert locking to guard()/scoped_guard()
From: Cezary Rojewski
Date: Mon Jun 29 2026 - 11:08:56 EST
On 6/29/2026 4:26 PM, Bui Duc Phuc wrote:
On Mon, Jun 29, 2026 at 8:25 PM Cezary Rojewski
<cezary.rojewski@xxxxxxxxx> wrote:
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.
Nah, the CI hasn't been run yet. Maintenance takes a long time :)
Unfortunately for "atom", it's outside of the support window. My Tested-by: would go for the platforms support by avs (and catpt) driver.
So perhaps the patch ASoC: intel: atom: Use __free(kfree) for stream pointerNo CI is not 100% bullet-proof window, it never is going to find everything, that's why you need still us - developers.
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?