[PATCH v2 00/10] workqueue / drivers: Add device-managed allocate workqueue
Andy Shevchenko
andriy.shevchenko at linux.intel.com
Fri Mar 6 06:28:54 PST 2026
On Thu, Mar 05, 2026 at 10:45:39PM +0100, Krzysztof Kozlowski wrote:
> Merging / Dependency
> ====================
> All further patches depend on the first one, thus this probably should
> go via one tree, e.g. power supply. The first patch might be needed for
> other trees as well, e.g. if more drivers are discovered, so the best if
> it is on dedicated branch in case it has to be shared.
>
> Changes in v2:
> ==============
> - See individual patches
> - Link to v1: https://patch.msgid.link/20260223-workqueue-devm-v1-0-10b3a6087586@oss.qualcomm.com
>
> Description
> ===========
> Add a Resource-managed version of alloc_workqueue() to fix common
> problem of drivers mixing devm() calls with destroy_workqueue. Such
> naive and discouraged driver approach leads to difficult to debug bugs
> when the driver:
>
> 1. Allocates workqueue in standard way and destroys it in driver
> remove() callback,
> 2. Sets work struct with devm_work_autocancel(),
> 3. Registers interrupt handler with devm_request_threaded_irq().
>
> Which leads to following unbind/removal path:
>
> 1. destroy_workqueue() via driver remove(),
> Any interrupt coming now would still execute the interrupt handler,
> which queues work on destroyed workqueue.
> 2. devm_irq_release(),
> 3. devm_work_drop() -> cancel_work_sync() on destroyed workqueue.
>
> devm_alloc_workqueue() has two benefits:
> 1. Solves above problem of mix-and-match devres and non-devres code in
> driver,
> 2. Simplify any sane drivers which were correctly using
> alloc_workqueue() + devm_add_action_or_reset().
Thanks, this version LGTM, FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
--
With Best Regards,
Andy Shevchenko
More information about the Linux-mediatek
mailing list