From: "Stefan Binding \(Opensource\)" <sbinding@opensource.cirrus.com>
To: "'Charles Keepax'" <ckeepax@opensource.cirrus.com>,
"'Cássio Gabriel'" <cassiogabrielcontato@gmail.com>
Cc: "'David Rhodes'" <david.rhodes@cirrus.com>,
"'Richard Fitzgerald'" <rf@opensource.cirrus.com>,
"'Takashi Iwai'" <tiwai@suse.com>,
"'Vitaly Rodionov'" <vitalyr@opensource.cirrus.com>,
"'Jaroslav Kysela'" <perex@perex.cz>,
<linux-sound@vger.kernel.org>, <patches@opensource.cirrus.com>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: RE: [PATCH RESEND] ALSA: hda/cs35l41: Fix firmware load work teardown
Date: Fri, 15 May 2026 16:08:14 +0100 [thread overview]
Message-ID: <002f01dce47c$a7859760$f690c620$@opensource.cirrus.com> (raw)
In-Reply-To: <agbxffucE1h67TRI@opensource.cirrus.com>
Hi,
> -----Original Message-----
> From: Charles Keepax <ckeepax@opensource.cirrus.com>
> Sent: Friday, May 15, 2026 11:12 AM
> To: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> Cc: David Rhodes <david.rhodes@cirrus.com>; Richard Fitzgerald
> <rf@opensource.cirrus.com>; Takashi Iwai <tiwai@suse.com>; Stefan Binding
> <sbinding@opensource.cirrus.com>; Vitaly Rodionov
> <vitalyr@opensource.cirrus.com>; Jaroslav Kysela <perex@perex.cz>; linux-
> sound@vger.kernel.org; patches@opensource.cirrus.com; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH RESEND] ALSA: hda/cs35l41: Fix firmware load work
> teardown
>
> On Mon, May 11, 2026 at 01:29:34AM -0300, Cássio Gabriel wrote:
> > cs35l41_hda creates ALSA controls whose private data points at the
> > cs35l41_hda object. The firmware load control can also queue
> > fw_load_work.
> >
> > Those controls are not removed on component unbind, and device remove
> > only cancels fw_load_work through cs35l41_remove_dsp(). That helper is
> > skipped when halo_initialized is false. With firmware_autostart
> > disabled, a firmware load can be requested before the DSP has been
> > initialized. If the component or device is removed before the queued
> > work runs, the worker can run after teardown and dereference driver
> > state that is no longer valid.
> >
> > Track the created controls and remove them on unbind so no new control
> > callback can reach the driver data or queue more work. Then cancel
> > fw_load_work to drain any request that was already queued. Also cancel
> > the work unconditionally during device remove before runtime PM
teardown.
> >
> > Fixes: 47ceabd99a28 ("ALSA: hda: cs35l41: Support Firmware switching
> > and reloading")
> > Fixes: 4c870513fbb0 ("ALSA: hda: cs35l41: Add read-only ALSA control
> > for forced mute")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> > ---
> > static bool cs35l41_dsm_supported(acpi_handle handle, unsigned int
> > commands) @@ -1522,6 +1550,10 @@ static void cs35l41_hda_unbind(struct
> device *dev, struct device *master, void *
> > device_link_remove(&cs35l41->codec->core.dev, cs35l41->dev);
> > unlock_system_sleep(sleep_flags);
> > memset(comp, 0, sizeof(*comp));
> > +
> > + cs35l41_remove_controls(cs35l41);
> > + cancel_work_sync(&cs35l41->fw_load_work);
> > + cs35l41->codec = NULL;
>
> Hmm... are we sure the controls are actually still accessible from
user-space
> here? Feels like generally it would make more sense to make all the cards
> controls inaccessible before we start tearing the card down as a core
feature.
>
> Adding the cancel works looks very sensible.
>
> @Stefan, could you also please have a look.
I think this is fine to do, and I did some tests to make sure it doesnt
break anything.
Reviewed-by: Stefan Binding <sbinding@opensource.cirrus.com>
>
> Thanks,
> Charles
next prev parent reply other threads:[~2026-05-15 15:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 4:29 [PATCH RESEND] ALSA: hda/cs35l41: Fix firmware load work teardown Cássio Gabriel
2026-05-15 9:07 ` Takashi Iwai
2026-05-15 10:12 ` Charles Keepax
2026-05-15 15:08 ` Stefan Binding (Opensource) [this message]
2026-05-15 15:49 ` Charles Keepax
2026-05-15 15:56 ` Takashi Iwai
2026-05-15 16:02 ` Cássio Gabriel Monteiro Pires
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='002f01dce47c$a7859760$f690c620$@opensource.cirrus.com' \
--to=sbinding@opensource.cirrus.com \
--cc=cassiogabrielcontato@gmail.com \
--cc=ckeepax@opensource.cirrus.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 \
--cc=vitalyr@opensource.cirrus.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.