[PATCH] ASoC: sun4i-spdif: Use guard() for spin locks

[PATCH] ASoC: sun4i-spdif: Use guard() for spin locks

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 sound/soc/sunxi/sun4i-spdif.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index c2ec19437cd7..ec00779182db 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -427,10 +427,9 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
 	struct snd_soc_dai *cpu_dai = snd_kcontrol_chip(kcontrol);
 	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
 	u8 *status = ucontrol->value.iec958.status;
-	unsigned long flags;
 	unsigned int reg;
 
-	spin_lock_irqsave(&host->lock, flags);
+	guard(spinlock_irqsave)(&host->lock);
 
 	regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, &reg);
 
@@ -444,8 +443,6 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
 	status[4] = reg & 0xff;
 	status[5] = (reg >> 8) & 0x3;
 
-	spin_unlock_irqrestore(&host->lock, flags);
-
 	return 0;
 }
 
@@ -455,11 +452,10 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
 	struct snd_soc_dai *cpu_dai = snd_kcontrol_chip(kcontrol);
 	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
 	u8 *status = ucontrol->value.iec958.status;
-	unsigned long flags;
 	unsigned int reg;
 	bool chg0, chg1;
 
-	spin_lock_irqsave(&host->lock, flags);
+	guard(spinlock_irqsave)(&host->lock);
 
 	reg = (u32)status[3] << 24;
 	reg |= (u32)status[2] << 16;
@@ -483,8 +479,6 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
 			   SUN4I_SPDIF_TXCFG_CHSTMODE |
 			   SUN4I_SPDIF_TXCFG_NONAUDIO, reg);
 
-	spin_unlock_irqrestore(&host->lock, flags);
-
 	return chg0 || chg1;
 }
 
-- 
2.43.0

Re: [PATCH] ASoC: sun4i-spdif: Use guard() for spin locks

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware State / PM Violation leading to bus hang
--

commit 0686001584788d984a0f16403183bcad78fe4176
Author: bui duc phuc <phucduc.bui@gmail.com>

ASoC: sun4i-spdif: Use guard() for spin locks

This commit refactors the locking in the sun4i-spdif driver to use the
guard() macro for spinlocks. It replaces manual spin_lock_irqsave() and
spin_unlock_irqrestore() calls with scope-based cleanup.

> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> --- a/sound/soc/sunxi/sun4i-spdif.c
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -427,10 +427,9 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
>  	struct snd_soc_dai *cpu_dai = snd_kcontrol_chip(kcontrol);
>  	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
>  	u8 *status = ucontrol->value.iec958.status;
> -	unsigned long flags;
>  	unsigned int reg;
>  
> -	spin_lock_irqsave(&host->lock, flags);
> +	guard(spinlock_irqsave)(&host->lock);
>  
>  	regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, &reg);

While this issue isn't new to this patch, does this code risk a bus hang if
the device is runtime-suspended?

The regmap configuration lacks a cache, and these ALSA kcontrols can be
accessed by userspace at any time. If the audio stream is idle, the device
will be runtime-suspended and its APB bus clock (apb_clk) will be disabled.

Accessing the physical registers with the clock disabled will trigger an
asynchronous external abort.

Would it make sense to ensure the device is runtime-resumed (perhaps via
pm_runtime_get_sync() outside the spinlock guard) before touching the
hardware?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513105003.81880-1-phucduc.bui@gmail.com?part=1

Re: [PATCH] ASoC: sun4i-spdif: Use guard() for spin locks

[Bui Duc Phuc]

Thanks for the review.

This seems to be pre-existing behavior rather than something
introduced by this patch, since the current change only converts
the locking to use guard() helpers and does not modify the
runtime PM handling.

If this turns out to be a real issue, it would probably be better
addressed separately from this cleanup patch.


On Thu, May 14, 2026 at 11:33 AM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Hardware State / PM Violation leading to bus hang
> --
>
> commit 0686001584788d984a0f16403183bcad78fe4176
> Author: bui duc phuc <phucduc.bui@gmail.com>
>
> ASoC: sun4i-spdif: Use guard() for spin locks
>
> This commit refactors the locking in the sun4i-spdif driver to use the
> guard() macro for spinlocks. It replaces manual spin_lock_irqsave() and
> spin_unlock_irqrestore() calls with scope-based cleanup.
>
> > diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> > --- a/sound/soc/sunxi/sun4i-spdif.c
> > +++ b/sound/soc/sunxi/sun4i-spdif.c
> > @@ -427,10 +427,9 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
> >       struct snd_soc_dai *cpu_dai = snd_kcontrol_chip(kcontrol);
> >       struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
> >       u8 *status = ucontrol->value.iec958.status;
> > -     unsigned long flags;
> >       unsigned int reg;
> >
> > -     spin_lock_irqsave(&host->lock, flags);
> > +     guard(spinlock_irqsave)(&host->lock);
> >
> >       regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, &reg);
>
> While this issue isn't new to this patch, does this code risk a bus hang if
> the device is runtime-suspended?
>
> The regmap configuration lacks a cache, and these ALSA kcontrols can be
> accessed by userspace at any time. If the audio stream is idle, the device
> will be runtime-suspended and its APB bus clock (apb_clk) will be disabled.
>
> Accessing the physical registers with the clock disabled will trigger an
> asynchronous external abort.
>
> Would it make sense to ensure the device is runtime-resumed (perhaps via
> pm_runtime_get_sync() outside the spinlock guard) before touching the
> hardware?
>
> [ ... ]
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260513105003.81880-1-phucduc.bui@gmail.com?part=1