Re: [PATCH 04/20] ASoC: Intel: avs: probes: Use guard() for spin locks

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

On 6/12/2026 6:48 AM, Bui Duc Phuc wrote:

...

>> Well, maybe one patch per driver suggestion of mine was a little too
>> much.. Let's separate guard() changes from scoped_guard() ones.
>> guard()s carry no readability cost.
>>
>> I'm not a fan of scoped_guard() update for any existing code block that
>> looks like below:
>>
>>          lock()
>>          one_liner()
>>          unlock()
>>
>> Adding tab to the picture ruins readability.  The cost of tab is OK if
>> there are more operations between the locking/unlocking though.
>>
> 
> 
> To save both of our time and avoid endless revisions, here is the plan for v2:
> 
> 1. I will keep the patch structure exactly as it is now (individual
> patches per file/driver),
>      instead of combining them into 2 big patches.
> 2. I will completely drop the scoped_guard() changes for those short
> 1-2 liner blocks.
> 3. For the remaining code, I will only apply guard() or scoped_guard()
>      where it genuinely improves readability.
> 
> Does this approach work for you? If so, I'll send out v2.
1. per-driver approach.  I haven't checked if there are any non-liner 
cases for scoped_guard() but if there were any:

	ASoC: Intel: avs: Use guard() for locking
	ASoC: Intel: avs: Use scoped_guard() for scoped locking
	ASoC: Intel: atom: Use guard() for locking
	ASoC: Intel: atom: Use scoped_guard() for scoped locking

2. yes
3. leave guard() as is. As I mentioned, guard() carries no readability 
cost what cannot be said about its scoped_guard() friend.