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

[Cezary Rojewski]

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.