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

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

On 6/29/2026 3:03 PM, Bui Duc Phuc wrote:


> The only thing I'm still a bit concerned about is splitting the kfree
> and guard() changes into two patches.
> Since the guard() conversion is mainly there to eliminate the goto
> labels, testing them separately might
> introduce issues that wouldn't exist when both patches are applied together.

The CI is run for entire patchset.

> By the way, I'm curious about your CI. What kinds of tests does it cover?
> For example, can it detect regressions related to audio functionality
> only, or is it also able to validate
> audio quality? I imagine things that require someone to actually
> listen to the output would be difficult
> to automate.
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.


Kind regards,
Czarek