All of lore.kernel.org
 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: 3+ 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
2026-11-11 20:24 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.