Re: [PATCH 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] Bypassing mandatory suspend preparation in azx_prepare() causes concurrent hardware access and crashes if direct-complete is aborted.
--

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

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

This commit allows direct complete during system suspend for HDA
controllers bound to a powered-off switcheroo GPU. It returns 1
in azx_prepare() if the discrete GPU is runtime suspended and
switched off.

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

[ ... ]

> @@ -1025,6 +1048,10 @@ static int azx_prepare(struct device *dev)
>  		return 0;
>  
>  	chip = card->private_data;
> +	/* A powered-off dGPU cannot signal HDA wake events. */
> +	if (azx_vga_is_powered_off(chip))
> +		return 1;
> +

[Severity: High]
Does returning early here bypass setting chip->pm_prepared = 1?

If the PM core aborts direct-complete (for example, if a user enables
wakeup via sysfs, or another device fails to suspend), the fallback
suspend path will execute.

Because chip->pm_prepared is left as 0, when the PCI core triggers a
runtime resume, wouldn't __azx_runtime_resume() incorrectly queue
asynchronous codec resumes via pm_request_resume()?

Could these async resumes execute on the pm_wq workqueue concurrently with
azx_suspend() shutting down the HDA controller, leading to MMIO faults or
system lockups?

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

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