Re: [PATCH v2 0/3] ASoC: rockchip: Use guard() for spin locks

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

On Thursday, 11 June 2026 21:53:26 Central European Summer Time Mark Brown wrote:
> On Thu, 04 Jun 2026 10:35:50 +0700, phucduc.bui@gmail.com wrote:
> > ASoC: rockchip: Use guard() for spin locks
> > 
> > From: bui duc phuc <phucduc.bui@gmail.com>
> > 
> > Hi all,
> > 
> > This series converts spinlock handling in the Rockchip sound drivers
> > to use guard() helpers.
> > The changes are code cleanup only and should have no functional impact.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
> 
> Thanks!

FWIW, the SAI patch wasn't sent to the proper maintainer e-mail
for it which is why I didn't notice this series at all until now,
and the whole thing is pointless churn that wasn't even tested.

From a cursory glance, whatever LLM was pointed at this and decided
to make the output my problem also didn't do a good job, the scoped
indentation of rockchip_sai_runtime_suspend seems pointless because
it could've been replaced by a pm guard followed by a spinlock guard,
without an additional level of indentation, and `if (ret == 0) {` is
not kernel style.

It's not worth the revert but it sucks that I have to now set up a
new lei search for all the drivers I am supposed to receive mail for
because vibecoders can't be bothered to run get_maintainers as they
pad their CV with nonsense like this.

> 
> [1/3] ASoC: rockchip: rockchip_i2s: Use guard() for spin locks
>       https://git.kernel.org/broonie/sound/c/4bda5af16920
> [2/3] ASoC: rockchip: i2s-tdm: Use guard() for spin locks
>       https://git.kernel.org/broonie/sound/c/ec22437fc41a
> [3/3] ASoC: rockchip: rockchip_sai: Use guard() for spin locks
>       https://git.kernel.org/broonie/sound/c/f7fe9f707360
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
> 
>