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

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 6/29/2026 4:26 PM, Bui Duc Phuc wrote:
> On Mon, Jun 29, 2026 at 8:25 PM Cezary Rojewski
> <cezary.rojewski@intel.com> 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 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?
No CI is not 100% bullet-proof window, it never is going to find 
everything, that's why you need still us - developers.