Re: [PATCH v2 3/3] ALSA: hda: allow direct complete with a powered-off GPU

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Returning 1 early from `azx_prepare()` for direct-complete skips essential system suspend preparation (`chip->pm_prepared = 1`, `snd_power_change_state()`, and `flush_work()`), breaking the fallback path if direct-complete is aborted.
--

--- Patch [3]: [PATCH v2 3/3] ALSA: hda: allow direct complete with a powered-off GPU ---
commit 512712a6e8db78ff16bf65eb2c4538a62401c892
Author: Andre Eikmeyer <[email protected]>

ALSA: hda: allow direct complete with a powered-off GPU

This commit allows direct complete for the HDA controller when a bound
GPU is powered off and unused. It checks the vga_switcheroo state and
runtime PM status to return 1 from azx_prepare() when appropriate.

> diff --git a/sound/hda/controllers/intel.c b/sound/hda/controllers/intel.c
> index 4b03c64e72ab4..6f1c1d596e2ca 100644
> --- a/sound/hda/controllers/intel.c
> +++ b/sound/hda/controllers/intel.c

[ ... ]

> @@ -1025,6 +1027,10 @@ static int azx_prepare(struct device *dev)
>  		return 0;
>  
>  	chip = card->private_data;
> +	/* A positive return allows the PM core to use direct complete. */
> +	if (azx_vga_is_powered_off(chip))
> +		return 1;
> +

[Severity: High]
By returning 1 early here in azx_prepare(), does this inadvertently skip
setting chip->pm_prepared = 1, calling snd_power_change_state(), and
flushing the asynchronous work queue?

If the PM core or PCI subsystem subsequently aborts direct-complete (for
instance, if device wakeups are enabled via sysfs or a child codec aborts
it), the fallback path will invoke azx_suspend() and azx_resume() on an
unprepared device.

Could this result in the ALSA card remaining in the D0 state instead of
D3hot, failing to block userspace hardware accesses during system suspend?

Furthermore, since flush_work(&azx_bus(chip)->unsol_work) is skipped, is
there a risk of a race between the asynchronous work queue and hardware
shutdown during azx_suspend()?

Finally, during system resume, if chip->pm_prepared remains 0, won't
__azx_runtime_resume() incorrectly request runtime resumes for codecs while
a system resume is still in progress?

>  	chip->pm_prepared = 1;
>  	snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3