linux-stable.git/sound/soc/soc-devres.c, branch linux-rolling-stable

ASoC: core: Complete support for card rebinding

2025-04-06T22:25:11+00:00

Since commit e894efef9ac7 ("ASoC: core: add support to card rebind")
there is a support for card rebind. The support is only partial though.
Let's consider the following scenarios both of which aim to enumerate a
sound card:

1)
    snd_soc_add_component(comp1);
    (...)
    snd_soc_register_card(card1);

2)
    snd_soc_register_card(card1);
    (...)
    snd_soc_add_component(comp1);

For the sake of simplicity, let comp1 be the last dependency needed for
the card1 to enumerate.
Case 1) will end up succeeding whereas 2) is a certain fail -
snd_soc_bind_card() does not honor unbind_card_list so even a non-fatal
return code of EPROBE_DEFER will cause the card to collapse. Given the
typical usecase of platform_device serving as a card->dev and its
probe() ending with:

int carddev_probe(struct platform_device *pdev)
{
	(...)
	return devm_snd_soc_register_card(dev, card);
}

failure to register card triggers device_unbind_cleanup() -
really_probe() in dd.c.

To allow for card registration to be deferred while being friendly
towards existing users of devm_snd_soc_register_card(), add new
card->devres_dev field, and devm_xxx() variants for card registration:

	devm_snd_soc_register_deferrable_card() (external)
	devm_snd_soc_bind_card() (internal)

In essence, if requested, devm_snd_soc_bind_card() replaces
snd_soc_bind_card(). The rebind procedure takes care of destroying
old devres before attempting the new bind. This makes sure nothing is
left hanging if binding fails and card becomes unbound but is still
registered to the ASoC framework.

To allow snd_soc_bind_card() to be reused by the deferrable friends,
move 'client_mutex' locking to the function's callers and select between
devm_xxx and non-devm_xxx variants of snd_soc_bind_card() based on
card->devres_dev.

On top of the feature, the refactoring brings two benefits:
a) single lock/unlock of 'client_mutex' in snd_soc_add_component()
   instead of ambiguous unlock and immediate lock in
   snd_soc_try_rebind_card()
b) all unbind_card_list manipulations done under 'client_mutex'

Reviewed-by: Amadeusz Sławiński 
Signed-off-by: Cezary Rojewski 
Link: https://patch.msgid.link/20250404101622.3673850-1-cezary.rojewski@intel.com
Signed-off-by: Mark Brown

ASoC: soc-devres: Remove unused devm_snd_soc_register_dai

2024-10-28T12:23:27+00:00

The last use of devm_snd_soc_register_dai() was removed by
commit fc4cb1e15f0c ("ASoC: topology: Properly unregister DAI on removal")
in 2021.

Remove it, and the helper it used.

Signed-off-by: Dr. David Alan Gilbert 
Link: https://patch.msgid.link/20241028021226.477909-1-linux@treblig.org
Signed-off-by: Mark Brown

ASoC: core: Remove only the registered component in devm functions

2020-07-07T10:55:46+00:00

The ASoC devm_ functions that register a component
(devm_snd_soc_register_component and devm_snd_dmaengine_pcm_register) will
clean their component by running snd_soc_unregister_component.

snd_soc_unregister_component will then remove all the components for the
device that was used to register the component in the first place.

However, some drivers register several components (such as a DAI and a
dmaengine PCM) on the same device, and if the dmaengine PCM is registered
first, then the DAI will be cleaned up first and
snd_dmaengine_pcm_unregister will be called next.

snd_dmaengine_pcm_unregister will then lookup the dmaengine PCM component
on the device, and if there's one unregister that component and release its
dmaengine channels. That doesn't happen in practice though since the first
call to snd_soc_unregister_component removed all the components, so we
never get the chance to release the dmaengine channels.

In order to fix this, instead of removing all the components for a given
device, we can simply remove the component that was registered in the first
place. We should have the same number of component registration than we
have components, so it should work just fine.

Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20200707074237.287171-1-maxime@cerno.tech
Signed-off-by: Mark Brown

ASoC: soc-devres: add devm_snd_soc_register_dai()

2020-06-15T13:15:11+00:00

The registration of DAIs may be done at two distinct times, once
during a component registration and later when loading a
topology. Since devm_ managed resources are freed in the reverse order
they were allocated, when a component starts unregistering DAIs by
walking through the DAI list, the memory allocated for the
topology-registered DAIs was freed already, which leads to 100%
reproducible KASAN use-after-free reports.

This patch suggests a new devm_ function to force the DAI list to be
updated prior to freeing the memory chunks referenced by the list
pointers.

Suggested-by: Bard Liao 
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Bard Liao 
Reviewed-by: Kai Vehmanen 
BugLink: https://github.com/thesofproject/linux/issues/2186
Link: https://lore.kernel.org/r/20200612205938.26415-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown

ASoC: soc-devres.c: convert to SPDX identifiers

2018-07-02T09:55:22+00:00

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown

ASoC: Remove platform code now everything is componentised

2018-04-26T11:24:43+00:00

As all drivers have been moved over to the new generic component
code remove the now unused platform specific code.

Signed-off-by: Charles Keepax 
Acked-by: Vinod Koul 
Signed-off-by: Mark Brown

ASoC: Fix warning with make xmldocs caused by soc-devres.c

2015-01-28T11:36:03+00:00

This patch fix warning while "make xmldocs".

Warning(.//sound/soc/soc-devres.c:70): No description
 found for parameter 'platform_drv'
Warning(.//sound/soc/soc-devres.c:70): Excess function
 parameter 'platform' description in 'devm_snd_soc_register_platform'

Signed-off-by: Masanari Iida 
Signed-off-by: Mark Brown

ASoC: Export devm_snd_soc_register_platform()

2014-04-22T21:00:42+00:00

devm_snd_soc_register_platform() is used in drivers which can be build as
modules, so it needs to be exported to avoid linkers errors like:

	ERROR: "devm_snd_soc_register_platform" [sound/soc/omap/snd-soc-omap.ko] undefined!
	ERROR: "devm_snd_soc_register_platform" [sound/soc/davinci/snd-soc-davinci.ko] undefined!

Fixes: 8931bf620 ("ASoC: Add resource managed snd_soc_register_platform()")
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Mark Brown

ASoC: Add resource managed snd_soc_register_platform()

2014-04-18T16:59:59+00:00

Simplify error handling and remove repetitive (and rarely executed) code
for unregistration by providing a devm_snd_soc_register_platform()
platform.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Mark Brown

Merge remote-tracking branch 'asoc/topic/dma' into asoc-next

2014-01-02T13:01:52+00:00