From: Takashi Iwai <tiwai@suse.de>
To: "Cássio Gabriel" <cassiogabrielcontato@gmail.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Russ Weight <russ.weight@linux.dev>,
Danilo Krummrich <dakr@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Takashi Iwai <tiwai@suse.com>,
Shenghao Ding <shenghao-ding@ti.com>, Kevin Lu <kevin-lu@ti.com>,
Baojun Xu <baojun.xu@ti.com>, Jaroslav Kysela <perex@perex.cz>,
driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-sound@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v4 0/2] firmware_loader/ALSA: Fix TAS2781 async firmware teardown
Date: Wed, 06 May 2026 10:05:30 +0200 [thread overview]
Message-ID: <874iklt12t.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260505-alsa-hda-tas2781-fw-callback-teardown-v4-0-e7c4bf930dc8@gmail.com>
On Tue, 05 May 2026 13:18:15 +0200,
Cássio Gabriel wrote:
>
> TAS2781 HDA I2C and SPI queue RCA firmware loading with
> request_firmware_nowait() during component bind. The firmware loader
> keeps the callback module pinned and holds a device reference, but it
> does not provide a way for drivers to cancel or synchronize the queued
> callback before tearing down driver-private state.
>
> Add a small firmware-loader helper to cancel or synchronize async firmware
> requests, then use it from TAS2781 HDA unbind before controls and DSP state
> are removed.
>
> No hardware runtime test was available.
>
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> ---
> Changes in v4:
> - Use spin_lock_irq() in the worker and cancel paths, which run from
> sleepable contexts.
> - Fold kfree(fw_work) into firmware_work_free().
> - Keep irqsave in the request path so GFP_ATOMIC callers do not depend on
> IRQ state assumptions.
> - Link to v3: https://patch.msgid.link/20260501-alsa-hda-tas2781-fw-callback-teardown-v3-0-8d9f873b97bd@gmail.com
>
> Changes in v3:
> - Keep request_firmware_nowait() manually managed instead of making the
> existing API implicitly devres-managed.
> - Track scheduled async firmware work in an internal list protected by a
> spinlock so request_firmware_nowait_cancel() can find and synchronize a
> pending request without weakening the GFP_ATOMIC caller contract.
> - Match pending requests by device, callback context and callback function
> instead of matching by callback alone.
> - Avoid the devres_add() / schedule_work() ordering race pointed out in
> review.
> - Leave devres-managed support for a separate devm_request_firmware_nowait()
> API if needed.
> - Link to v2: https://patch.msgid.link/20260430-alsa-hda-tas2781-fw-callback-teardown-v2-0-2c7d89cb3175@gmail.com
>
> Changes in v2:
> - Add request_firmware_nowait_cancel() in the firmware loader instead of
> tracking the callback lifetime locally in the TAS2781 HDA driver.
> - Keep the TAS2781 change to a cancel/sync call in I2C and SPI unbind.
> - Drop the unrelated cached kcontrol pointer cleanup from the previous
> local-driver version.
> - Link to v1: https://patch.msgid.link/20260430-alsa-hda-tas2781-fw-callback-teardown-v1-1-874367d6b41b@gmail.com
>
> ---
> Cássio Gabriel (2):
> firmware_loader: Add cancel helper for async requests
> ALSA: hda/tas2781: Cancel async firmware request at unbind
I guess this could go via driver tree? Or I can take both if I get an
ack, too.
In anyway, for the series:
Reviewed-by: Takashi Iwai <tiwai@suse.de>
thanks,
Takashi
next prev parent reply other threads:[~2026-05-06 8:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 11:18 [PATCH v4 0/2] firmware_loader/ALSA: Fix TAS2781 async firmware teardown Cássio Gabriel
2026-05-05 11:18 ` [PATCH v4 1/2] firmware_loader: Add cancel helper for async requests Cássio Gabriel
2026-05-05 11:18 ` [PATCH v4 2/2] ALSA: hda/tas2781: Cancel async firmware request at unbind Cássio Gabriel
2026-05-06 8:05 ` Takashi Iwai [this message]
2026-05-06 9:34 ` [PATCH v4 0/2] firmware_loader/ALSA: Fix TAS2781 async firmware teardown Danilo Krummrich
2026-05-06 11:14 ` Takashi Iwai
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=874iklt12t.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=baojun.xu@ti.com \
--cc=cassiogabrielcontato@gmail.com \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=kevin-lu@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=perex@perex.cz \
--cc=rafael@kernel.org \
--cc=russ.weight@linux.dev \
--cc=shenghao-ding@ti.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.