Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: "Stefan Binding \(Opensource\)" <sbinding@opensource.cirrus.com>
To: <alban.kernel@gmail.com>,
	"'David Rhodes'" <david.rhodes@cirrus.com>,
	"'Richard Fitzgerald'" <rf@opensource.cirrus.com>,
	"'Jaroslav Kysela'" <perex@perex.cz>,
	"'Takashi Iwai'" <tiwai@suse.com>
Cc: <linux-sound@vger.kernel.org>, <patches@opensource.cirrus.com>,
	<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: RE: [PATCH] ALSA: hda: cs35l41: Fix hibernation deadlock with the firmware reload
Date: Thu, 12 Nov 2026 14:02:44 -0000	[thread overview]
Message-ID: <006d01dd72ae$7e02eda0$7a08c8e0$@opensource.cirrus.com> (raw)
In-Reply-To: <20261111-cs35l41-freezable-fw-load-v1-1-ebcaf549b2f7@gmail.com>

Hi,

I've been looking into the same issue (alongside another issue system suspend Issue).
Whilst I agree that this work item needs to be moved to the freezable workqueue,
I think there are a few more loose ends in the driver that need to be addressed as well.

I have a larger chain of patches to fix a couple of system suspend issues in CS35L41
HDA Driver - including this issue - coming.

Thanks,
Stefan

> -----Original Message-----
> From: Alban Munari via B4 Relay
> <devnull+alban.kernel.gmail.com@kernel.org>
> Sent: Wednesday, November 11, 2026 8:25 PM
> To: David Rhodes <david.rhodes@cirrus.com>; Richard Fitzgerald
> <rf@opensource.cirrus.com>; Jaroslav Kysela <perex@perex.cz>; Takashi Iwai
> <tiwai@suse.com>; Stefan Binding <sbinding@opensource.cirrus.com>
> Cc: linux-sound@vger.kernel.org; patches@opensource.cirrus.com; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Alban Munari
> <alban.kernel@gmail.com>
> Subject: [PATCH] ALSA: hda: cs35l41: Fix hibernation deadlock with the
> firmware reload
> 
> From: Alban Munari <alban.kernel@gmail.com>
> 
> cs35l41_system_resume() is also the .thaw and .restore callback, and it
> schedules fw_load_work on system_wq. During hibernation, .thaw runs right
> after the snapshot is created, while tasks and freezable workqueues stay
> frozen until the system powers off. The work calls
> request_firmware() with fw_mutex held. When the firmware files are not
> cached, the lookup waits for filesystem I/O whose completion runs on a
> freezable workqueue (btrfs completes reads on its endio workqueues, which
> are WQ_FREEZABLE), so it never returns. The next step of hibernation then
> waits for fw_mutex in cs35l41_system_suspend_prep(), and the machine
> stays on after the image has been written.
> 
> Blocked tasks on an ASUS ROG Strix G17 (G713PI) after the image was saved,
> from SysRq-W:
> 
>   task:systemd-sleep state:D
>    __mutex_lock.constprop.0
>    cs35l41_system_suspend_prep [snd_hda_scodec_cs35l41]
>    dpm_prepare
>    dpm_suspend_start
>    hibernation_platform_enter
>    hibernate.cold
> 
>   task:kworker/15:2 state:D
>   Workqueue: events cs35l41_fw_load_work [snd_hda_scodec_cs35l41]
>    bit_wait_io
>    read_extent_buffer_pages [btrfs]
>    btrfs_lookup [btrfs]
>    path_openat
>    kernel_read_file_from_path_initns
>    fw_get_filesystem_firmware
>    _request_firmware
>    cs35l41_request_firmware_file [snd_hda_scodec_cs35l41]
>    cs35l41_smart_amp [snd_hda_scodec_cs35l41]
>    cs35l41_fw_load_work [snd_hda_scodec_cs35l41]
> 
> Queue the work on system_freezable_wq. After .thaw it then stays pending
> until the system powers off, and on resume it runs once tasks are thawed and
> the firmware files can be read.
> 
> Fixes: 88672826e2a4 ("ALSA: hda: cs35l41: Support System Suspend")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alban Munari <alban.kernel@gmail.com>
> ---
> Testing: ASUS ROG Strix G17 (G713PI), two CS35L41 amplifiers (CSC3551),
> 7.2.14-zen1 with this change applied. Before it, every hibernation since
> 2026-11-02 left the machine on after writing the image; with it, three
> hibernations powered off, on mains and on battery, and both amplifiers
> reloaded their firmware about one second after tasks restarted. Without the
> change, setting "L0 DSP1 Firmware Load" and "R0 DSP1 Firmware Load"
> to off before hibernating also avoided the hang. On sound/for-next the
> change was build-tested only.
> 
> AI assistance: the fix was developed in an interactive session with Claude Code
> (Claude Opus 5.5, Anthropic). The model read the journals and the kernel
> source, proposed hypotheses and experiments, decoded the pm_trace value
> and the pstore records, and wrote the change, the changelog and these notes.
> I directed the investigation with a troubleshooting procedure I wrote for the
> assistant (research before experiments, one variable per test), supplied the
> observations, ran every experiment on the machine, reviewed the change and
> tested it as described above.
> ---
>  sound/hda/codecs/side-codecs/cs35l41_hda.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/hda/codecs/side-codecs/cs35l41_hda.c
> b/sound/hda/codecs/side-codecs/cs35l41_hda.c
> index 6fbc194d3347..efe937d18330 100644
> --- a/sound/hda/codecs/side-codecs/cs35l41_hda.c
> +++ b/sound/hda/codecs/side-codecs/cs35l41_hda.c
> @@ -1012,7 +1012,7 @@ static int cs35l41_system_resume(struct device
> *dev)
> 
>  	if (cs35l41->request_fw_load && !cs35l41->fw_request_ongoing) {
>  		cs35l41->fw_request_ongoing = true;
> -		schedule_work(&cs35l41->fw_load_work);
> +		queue_work(system_freezable_wq, &cs35l41-
> >fw_load_work);
>  	}
> 
>  	return ret;
> 
> ---
> base-commit: 291d8707fa439ed4ec72552e7770177f6b6514e4
> change-id: 20261111-cs35l41-freezable-fw-load-c9542cf8bda7
> 
> Best regards,
> --
> Alban Munari <alban.kernel@gmail.com>
> 
> 



      reply	other threads:[~2026-11-12 14:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11 20:24 [PATCH] ALSA: hda: cs35l41: Fix hibernation deadlock with the firmware reload Alban Munari via B4 Relay
2026-11-12 14:02 ` Stefan Binding (Opensource) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='006d01dd72ae$7e02eda0$7a08c8e0$@opensource.cirrus.com' \
    --to=sbinding@opensource.cirrus.com \
    --cc=alban.kernel@gmail.com \
    --cc=david.rhodes@cirrus.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=perex@perex.cz \
    --cc=rf@opensource.cirrus.com \
    --cc=stable@vger.kernel.org \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox