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

[Bui Duc Phuc]

Hi Crazek

>
> The order is off just by looking at it.  On top of what I mentioned in
> 1/5, please fix the ordering so that both avs and atom drivers receive
> updates in the same manner.
>
> TLDR:
>
> 1. ASoC: Intel: avs: Use guard() for locking
> 2. ASoC: Intel: avs: Use scoped_guard() for scoped locking
> 3. ASoC: Intel: atom: Use guard() for locking
> 4. ASoC: Intel: atom: Use scoped_guard() for scoped locking
> 5. ASoC: Intel: atom: Use __free(kfree) for stream pointer
>

As mentioned in my reply to patch 1/5, we cannot place the __free(kfree)
patch at the very end (as patch 5) because the locking updates in atom
still rely on the goto labels for kfree. Moving __free(kfree) after the locking
patches would force us to temporarily mix guard/scoped_guard with goto,
which is highly discouraged.

To keep the driver groups consistent while respecting this dependency,
I can reorder the patchset in one of the following ways:

Option 1:

ASoC: Intel: avs: Use guard() for locking

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

ASoC: Intel: atom: Use __free(kfree) for stream pointer

ASoC: Intel: atom: Use guard() for locking

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

Option 2 (Most convenient for me):

ASoC: Intel: avs: Use guard() for locking

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

ASoC: Intel: atom: Use __free(kfree) for stream pointer

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

ASoC: Intel: atom: Use guard() for locking

The reason Option 2 is much more convenient for me is that atom has very few
scoped_guard() instances, making it very easy to separate them first
using git add -p.
On the other hand, guard() instances are quite numerous,
so leaving them for the final patch makes the staging process much smoother.

Please let me know which option you prefer, and I will roll out v4 accordingly.

Regards,
Phuc