Re: [PATCH 00/20] ASoC: Intel: Use guard() for mutex & spin locks

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

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

>> Recent changes took care of catpt-driver [1], so the first two patches
>> can be dropped.  While I wanted to follow up with the avs-driver, I see
>> no reason why I shouldn't let you do that instead.
>>
> 
> Thank you for the feedback and for clarifying the status of the
> catpt-driver patches. I'd be happy to take over the avs-driver changes
> as well!
> By the way, since the catpt changes were already taken care of by someone
> else, could you share how you usually check for this so I can avoid duplicate
> work in the future?

Assuming someone is new to a subsystem (here, ASoC), it is advised to 
check the MAINTAINERS file and the kernel.org git repository list [1]. 
In our case we're looking for sound/soc subsystem maintainer.  Both the 
file and the repository list will point out: Mark.  From there, fetch 
their "-next" branch, typically "for-next".  Checking out a for-next 
branch and applying proposed changed on top of it, recompiling and 
retesting solves majority of problems.


[1]: https://git.kernel.org/pub/scm/linux/kernel/git

>> Now on to the review - there is no need to be as granular as you're
>> here.  Two drivers are being updated here: the avs-driver and the
>> atom-driver (assuming the catpt-driver patches are already gone).
>> Sending a patch per file creates unnecessary traffic, so let's limit the
>> set to two changes.
>>
>> Please use the following scopes for those:
>>          ASoC: Intel: avs:
>>          ASoC: Intel: atom:
>>
> 
> I initially split the series more finely because I was thinking about
> bisectability,
> but grouping the changes per driver also makes sense.
> I'll rework the series accordingly.

One could treat the conversion of open locking into guard() as 
"feature".  If a portion of such feature causes problems, it is usually 
better to revert the feature, fix the problems and apply it again.  When 
reverting, it's good to do so for the entire entity e.g.: the avs-driver.

At the same time there may be no need to revert for everyone e.g.: the 
second driver, the atom-driver, if only the avs-driver presented 
problems.  Per-file would translate to quite a few reverts, again, 
unnecessary traffic.

>> Last but not least, your name and surname are not capitalized.  That's
>> clearly not the case here, in the cover letter.  Please adjust.
>>
> 
> Regarding my name, leaving it lowercase is a small trick to quickly find myself
> at the bottom of contribution stats (like LWN:
> https://lwn.net/Articles/1075574/).
> I capitalize it in emails just for communication.
> Unless it's strictly against kernel rules, I'd prefer to keep it this way.
OK, thanks for explaining.