ASoC: codecs: Fix resource leaks across card bind/unbind

Chancel Liu <chancel.liu@oss.nxp.com> says:

For an ASoC component, component->dev is the underlying bus device
(I2C / SPI / platform). Its devres lifetime is tied to the physical
device's probe/remove, not to the ASoC card's bind/unbind.

A card bind (snd_soc_bind_card()) / unbind (snd_soc_unbind_card())
runs the component .probe / .remove callbacks, but the bus device
itself stays bound across the cycle. Resources requested from the
component .probe (or from a runtime DAI callback) with
devm_*(component->dev, ...), or allocated there and only released when
the bus device is removed, therefore outlive a card unbind and
accumulate one extra copy on every bind/unbind cycle.

Each codec is fixed following one of two principles, chosen by what the
resource actually depends on:

1. Pure hardware resources (clk / regulator / regmap / GPIO / board
   description) only depend on the physical device, not on the ASoC
   component.

   Their acquisition is moved to the bus probe (i2c / spi / platform probe)
   using devm_*(&client->dev, ...), so their devres lifetime correctly
   follows the device and they are not re-requested on every bind.

2. Resources that genuinely depend on the card/component (they are bound
   to the component, or must be torn down when the card is unbound)

   They are kept in the component .probe, but switched from devm to
   plain allocation and released in a paired component .remove:
   memory (kzalloc/kcalloc + kfree), IRQ (request_irq + free_irq),
   delayed work (cancel), wakeup source and mutex.

While working on the card re-bind resource leaks fixed in
https://lore.kernel.org/linux-sound/20260913101531.2787654-1-chancel.liu@oss.nxp.com/

I noticed that the same devm-on-component->dev pattern is present in
many other codecs, leaking resources in the same way.

This series is the result of code analysis only, based on the same
devm-without-remove leak pattern I confirmed by repeated card bind/unbind
with wm8962. The individual fixes have not been tested on hardware, as I
do not have access to these codecs; review of the resource lifetimes
is therefore appreciated.

Link: https://patch.msgid.link/20260923061305.4041197-1-chancel.liu@oss.nxp.com

0 files changed, 0 insertions, 0 deletions