Current ALSA SoC is directly using dai->driver->xxx,
thus, it has deep nested bracket, and it makes code unreadable.
This patch adds new snd_soc_dai_suspend() and use it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87muh6hn2x.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Current ALSA SoC has many snd_soc_dai_xxx() function which is
using dai->driver->ops->xxx.
But, some of them are implemented as snd_soc_dai_xxx(),
but others are directly using dai->driver->ops->xxx.
Because of it, the code is not easy to read.

This patch creats new soc-dai.c and moves snd_soc_dai_xxx()
functions into it.
One exception is snd_soc_dai_is_dummy() which is based on
soc-utils local variable. We need to keep it as-is there.

Others which is directly using dai->driver->ops->xxx will be
implemented at soc-dai.c by incremental patches.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871ryij1r6.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

It makes it easier for common code to work with snd_soc_dai_set_channel_map()
by distinguishing between operation not being supported and an error.
This is done inline with others snd_soc_dai.* apis.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20190703123002.12427-1-srinivas.kandagatla@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Add support platforms_num != 1 in dai_link. Initially, the main purpose of
this change was to make the platform optional in the dai_link, instead of
inserting the dummy platform driver.

This particular case had just been solved by Kuninori Morimoto with
commit 1d768989 ("ASoC: soc-core: allow no Platform on dai_link").

However, this change may still be useful for those who need multiple
platform components on a single dai_link (it solves one of the FIXME
note in soc-core)
Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Like cpus and platforms, defer sound card initialization if the codec
component is missing when initializing the dai_link
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

commit b9f2e25c ("ASoC: soc-core: use soc_find_component() at
snd_soc_find_dai()") used soc_find_component() at snd_soc_find_dai(),
but, some CPU driver has CPU component for DAI and Platform component,
for example generic DMAEngine component.
In such case, CPU component and Platform component have same
of_node / name.

Here soc_find_component() returns *1st* found component.
Thus, we shouldn't use soc_find_component() at snd_soc_find_dai().
This patch fixup this it, and add comment to indicate this limitation.

Fixes: commit b9f2e25c ("ASoC: soc-core: use soc_find_component() at snd_soc_find_dai()")
Reported-by: NDmitry Osipenko <digetx@gmail.com>
Reported-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

snd_soc_find_dai() finds component first via specified
snd_soc_dai_link_component, and find DAI from it.

We already have soc_find_component() to find component,
but soc_find_dai() has original implementation to find component.

We shouldn't have duplicate implementation to do same things.
This patch uses soc_find_component() at soc_find_dai()
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

soc_find_component() is using "of_node" and "name" to finding component,
but we should use snd_soc_dai_link_component now, because it is created
to such purpose.

This patch uses snd_soc_dai_link_component for soc_find_component().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

ALSA SoC already has snd_soc_is_matching_component() to confirming
matching component, but, soc_find_component() has original
implementation to confirm component.

We shouldn't have duplicate implementation to do same things.
This patch uses snd_soc_is_matching_component() at soc_find_component()
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

move soc_find_component() next to snd_soc_is_matching_component().
This is prepare for soc_find_component() cleanup
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Back in ff9fb72b (debugfs: return error values, not NULL) the
debugfs APIs were changed to return error pointers rather than NULL
pointers on error, breaking the error checking in ASoC. Update the
code to use IS_ERR() and log the codes that are returned as part of
the error messages.

Fixes: ff9fb72b (debugfs: return error values, not NULL)
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: NMark Brown <broonie@kernel.org>

commit 34ac3c3e ("ASoC: core: lock client_mutex while removing
link components") added mutex_lock() at soc_remove_link_components().

Is is called from snd_soc_unbind_card()

	snd_soc_unbind_card()
=>		soc_remove_link_components()
		soc_cleanup_card_resources()
			soc_remove_dai_links()
=>				soc_remove_link_components()

And, there are 2 way to call it.

(1)
	snd_soc_unregister_component()
**		mutex_lock()
			snd_soc_component_del_unlocked()
=>				snd_soc_unbind_card()
**		mutex_unlock()

(2)
	snd_soc_unregister_card()
=>		snd_soc_unbind_card()

(1) case is already using mutex_lock() when it calles
snd_soc_unbind_card(), thus, we will get lockdep warning.

commit 495f926c ("ASoC: core: Fix deadlock in
snd_soc_instantiate_card()") tried to fixup it, but still not
enough. We still have lockdep warning when we try unbind/bind.

We need mutex_lock() under snd_soc_unregister_card()
instead of snd_remove_link_components()/snd_soc_unbind_card().

Fixes: 34ac3c3e ("ASoC: core: lock client_mutex while removing link components")
Fixes: 495f926c ("ASoC: core: Fix deadlock in snd_soc_instantiate_card()")
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

dai_link is used to selecting Component (= CPU/Codec/Platform) and
DAI (= CPU/Codec). And selected CPU/Codec/Platform components are
*listed* on Card.

Many drivers don't need special Platform component, but was
mandatory at legacy style ALSA SoC.
Thus, there is this kind of settings on many drivers.

	dai_link->platform_of_node = dai_link->cpu_of_node;

In this case, soc_bind_dai_link() will pick-up "CPU component" as
"Platform component", and try to add it to snd_soc_pcm_runtime.
But it will be ignored, because it is already added when CPU bindings.

Historically, this kind of "CPU component" is used/selected as
"Platform" on many ALSA SoC drivers.
OTOH, Dummy Platform will be selected automatically by ALSA SoC if
driver doesn't have Platform settings.

These indicates that there are 2 type of Platforms exist at current
ALSA SoC if driver doesn't need special Platform.

	1) use Dummy Platform as Platform component
	2) use CPU component  as Platform component

ALSA SoC will call Dummy Platform callback function if it is using
Dummy Platform, but it is completely pointless. Because it is the
sound card which doesn't need special Platform.

Thus, the behavior we request to ALSA SoC is selecting 2) automatically
instead of 1) if sound card doesn't need special Platform.
And, 2) means "do nothing" as above explain.

These were needed at legacy style dai_link, but is no longer needed
at modern style dai_link anymore.

This patch allows "no Platform" settings on dai_link, and will do
nothing for it if there was no platform settings. This is same as 2).

By this patch, all drivers which is selecting "CPU component" as
"Platform" can remove such settings.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Move the client_mutex lock to snd_soc_unbind_card() before
removing link components. This prevents the deadlock
in the error path in snd_soc_instantiate_card().

Fixes: 34ac3c3e (ASoC: core: lock client_mutex while removing
link components)
Reported-by: Nkernelci.org bot <bot@kernelci.org>
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When soc_init_dai_link() call at the beginning of snd_soc_instantiate_card
function fails soc_cleanup_card_resources() and then snd_soc_dapm_free()
gets called with an incompletely initialized card->dapm. In particular
card->dapm.card is NULL and it gets dereferenced in dapm_free_widgets().
Also dapm->list is invalid and there is an invalid pointer dereference
from list_del().

The function call stack (deferred probing) on Chromebook Snow where this
issue has shown up in today's -next is:

 snd_soc_dapm_free
 soc_cleanup_card_resources
 snd_soc_instantiate_card
 snd_soc_register_card
 devm_snd_soc_register_card
 snow_probe

In patch 70fc5373 "ASoC: core: move DAI pre-links initiation to
snd_soc_instantiate_card" there is an soc_cleanup_platform() call instead
of soc_cleanup_card_resources() as in current -next.

soc_cleanup_platform got renamed to soc_cleanup_legacy, then removed
in commit adb76b5b "ASoC: soc-core: remove legacy style dai_link".

It seems in merge conflict resolution the soc_cleanup_platform() call got
renamed to soc_cleanup_card_resources(), instead of being removed.

Correct this by removing an unnecessary soc_cleanup_card_resources() call.

Fixes: a8e99234 ("Merge branch 'asoc-5.2' into asoc-5.3")
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Suggested-by: NTzung-Bi Shih <tzungbi@google.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

All drivers switched to modern style dai_link
(= struct snd_soc_dai_link_component).
Let's remove legacy style dai_link.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Modern style dai_link requests CPU/Codec/Platform component
pointer array and its size, but it will be very verbose code.
To avoid such scene, this patch adds dai_link connection macro.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

current ALSA SoC is starting to support modern style dai_linke
(= struct snd_soc_dai_link_component) which is mainly used for
multipul DAI/component connection.
Now Codec has full multi-codec support, Platform is using modern
style but still for single Platform.
Only CPU is not yet supporting modern style yet.
If we could support it for CPU, we can switch to modern style
dai_link on all CPU/Codec/Platform, and remove legacy style
from ALSA SoC.

Multi-CPU will be supported in the future.
This patch is initial support for modern style for CPU
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When component is being removed we should disable jack, otherwise some
codecs will try to trigger interrupt using freed structures.
Signed-off-by: NAmadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Kernel crashes when an ASoC component rebinding.

The dai_link->platforms has been reset to NULL by soc_cleanup_platform()
in soc_cleanup_card_resources() when un-registering component.  However,
it has no chance to re-allocate the dai_link->platforms when registering
the component again.

Move the DAI pre-links initiation from snd_soc_register_card() to
snd_soc_instantiate_card() to make sure all DAI pre-links get initiated
when component rebinding.

As an example, by using the following commands:
- echo -n max98357a > /sys/bus/platform/drivers/max98357a/unbind
- echo -n max98357a > /sys/bus/platform/drivers/max98357a/bind

Got the error message:
"Unable to handle kernel NULL pointer dereference at virtual address".

The call trace:
snd_soc_is_matching_component+0x30/0x6c
soc_bind_dai_link+0x16c/0x240
snd_soc_bind_card+0x1e4/0xb10
snd_soc_add_component+0x270/0x300
snd_soc_register_component+0x54/0x6c
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Using component driver as a name is not unique and it breaks audio in
certain configurations, e.g. Hardkernel Odroid XU3 board where following
components are registered:
 - "3830000.i2s" with driver name "snd_dmaengine_pcm"
 - "3830000.i2s-sec" with driver name "snd_dmaengine_pcm"
 - "3830000.i2s" with driver name "samsung-i2s"

This reverts commit b19671d6.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

fmt_single_name() uses device name to determine component name.  If
multiple components bind to the same device, the debugfs creation in
soc_init_component_debugfs() would fail due to duplicated entity
names.

Name provided by component driver is unique enough to represent each
component.  Use component driver name as the component name to avoid
name duplication.
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

commit 53e947a0 ("ASoC: soc-core: merge card resources cleanup
method") merged cleanup method of snd_soc_instantiate_card() and
soc_cleanup_card_resources().

But, after this commit, if user uses unbind/bind to Component factor
drivers, Kernel might indicates refcount error at
soc_cleanup_card_resources().

The 1st reason is card->snd_card is still exist even though
snd_card_free() was called, but it is already cleaned.
We need to set NULL to it.

2nd is card->dapm and card create debugfs, but its dentry is still
exist even though it was removed. We need to set NULL to it.

Fixes: 53e947a0 ("ASoC: soc-core: merge card resources cleanup method")
Cc: stable@vger.kernel.org # for v5.1
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Removing link components results in topology unloading. So,
acquire the client_mutex before removing components in
soc_remove_link_components. This will prevent the lockdep warning
seen when dai links are removed during topology removal.
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

soc_probe_component() has WARN() under if (component->driver->probe),
but, this WARN() check is not related to .probe callback.
So, it should be called at (B) instead of (A).
This patch moves it out of if().

	if (component->driver->probe) {
		ret = component->driver->probe(component);
		...
(A)		WARN(...)
	}
(B)	WARN(...)
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

soc-core core already has soc_find_component() which find
component from device node.
Let's use existing function to find component.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Many function are getting device_node from component
with caring its parent component.
This patch adds new soc_component_to_node() and share
same code.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Many code at soc_bind_dai_link() was changed, and its comment is
now a little bit anbalanced.
This patch tidyup these.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Current soc_bind_dai_link() is substituting rtd->codec_dais to
codec_dais, and sets found DAI into it.
But, it is a little bit un-readable / un-understandable to
know detail of rtd, and it will make difficult to understand
rtd->cpu_dais if Multi CPU was supported.
This patch cleanup it and prepare for Multi CPU support.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch uses "int i" instead of "int j" on snd_soc_resume(),
and moves struct snd_soc_dai *codec_dai to top of this function.
This is cleanup and prepare for Multi CPU support
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Recently, for Intel platforms the "ignore_module_refcount" field
was introduced for the component driver. In order to avoid a
deadlock preventing the PCI modules from being removed
even when the card was idle, the refcounts were not incremented
for the device driver module during component probe.

However, this change introduced a nasty side effect:
the device driver module can be unloaded while a pcm stream is open.

This patch proposes to change the field to be renamed as
"module_get_upon_open". When this field is set, the module
refcount should be incremented on pcm open amd decremented
upon pcm close. This will enable modules to be removed
when no PCM playback/capture happens and prevent removal
when the component is actually in use.

Also, align with the skylake component driver with the new name.

Fixes: b450b878('ASoC: core: don't increase component module refcount
                 unconditionally'
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When the card is registered by the machine driver,
dai link components are probed after the snd_card is
created. This is done in snd_soc_bind_card() which calls
snd_soc_instantiate_card() to first create the snd_card
and then probes the link components by calling
soc_probe_link_components(). The snd_card is used by the
component driver to add the kcontrols associated
with dapm widgets to the card.

When the machine driver is unregistered, the snd_card
is freed when the card resources are cleaned up.
But the snd_card needs to be valid while unloading the
topology dapm widgets in order to remove the kcontrols
from the card.

Since, unloading topology is done when the component
driver is removed, the link components should be removed
in snd_soc_unbind_card(). This will ensure that the kcontrols
are removed before the card resources are cleaned up and
the snd_card itself is freed.
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When the same machine driver is reused between platforms but with a
different alias, using the driver name is not enough. Add additional
fallback case to use the card device name.

Tested on GeminiLake with bxt_da7219_max98357a machine driver
Suggested-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The dpcm get from fe_clients/be_clients
may be free before use

Add a spin lock at snd_soc_card level,
to protect the dpcm instance.
The lock may be used in atomic context, so use spin lock.

possible race condition between
void dpcm_be_disconnect(
	...
	list_del(&dpcm->list_be);
	list_del(&dpcm->list_fe);
	kfree(dpcm);
	...

and
	for_each_dpcm_fe()
	for_each_dpcm_be*()

race condition example
Thread 1:
    snd_soc_dapm_mixer_update_power()
        -> soc_dpcm_runtime_update()
            -> dpcm_be_disconnect()
                -> kfree(dpcm);
Thread 2:
    dpcm_fe_dai_trigger()
        -> dpcm_be_dai_trigger()
            -> snd_soc_dpcm_can_be_free_stop()
                -> if (dpcm->fe == fe)

Excpetion Scenario:
	two FE link to same BE
	FE1 -> BE
	FE2 ->

	Thread 1: switch of mixer between FE2 -> BE
	Thread 2: pcm_stop FE1

Exception:

Unable to handle kernel paging request at virtual address dead0000000000e0

pc=<> [<ffffff8960e2cd10>] dpcm_be_dai_trigger+0x29c/0x47c
	sound/soc/soc-pcm.c:3226
		if (dpcm->fe == fe)
lr=<> [<ffffff8960e2f694>] dpcm_fe_dai_do_trigger+0x94/0x26c

Backtrace:
[<ffffff89602dba80>] notify_die+0x68/0xb8
[<ffffff896028c7dc>] die+0x118/0x2a8
[<ffffff89602a2f84>] __do_kernel_fault+0x13c/0x14c
[<ffffff89602a27f4>] do_translation_fault+0x64/0xa0
[<ffffff8960280cf8>] do_mem_abort+0x4c/0xd0
[<ffffff8960282ad0>] el1_da+0x24/0x40
[<ffffff8960e2cd10>] dpcm_be_dai_trigger+0x29c/0x47c
[<ffffff8960e2f694>] dpcm_fe_dai_do_trigger+0x94/0x26c
[<ffffff8960e2edec>] dpcm_fe_dai_trigger+0x3c/0x44
[<ffffff8960de5588>] snd_pcm_do_stop+0x50/0x5c
[<ffffff8960dded24>] snd_pcm_action+0xb4/0x13c
[<ffffff8960ddfdb4>] snd_pcm_drop+0xa0/0x128
[<ffffff8960de69bc>] snd_pcm_common_ioctl+0x9d8/0x30f0
[<ffffff8960de1cac>] snd_pcm_ioctl_compat+0x29c/0x2f14
[<ffffff89604c9d60>] compat_SyS_ioctl+0x128/0x244
[<ffffff8960283740>] el0_svc_naked+0x34/0x38
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: NKaiChieh Chuang <kaichieh.chuang@mediatek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The dpcm get from fe_clients/be_clients
may be free before use

Add a spin lock at snd_soc_card level,
to protect the dpcm instance.
The lock may be used in atomic context, so use spin lock.

Use irq spin lock version,
since the lock may be used in interrupts.

possible race condition between
void dpcm_be_disconnect(
	...
	list_del(&dpcm->list_be);
	list_del(&dpcm->list_fe);
	kfree(dpcm);
	...

and
	for_each_dpcm_fe()
	for_each_dpcm_be*()

race condition example
Thread 1:
    snd_soc_dapm_mixer_update_power()
        -> soc_dpcm_runtime_update()
            -> dpcm_be_disconnect()
                -> kfree(dpcm);
Thread 2:
    dpcm_fe_dai_trigger()
        -> dpcm_be_dai_trigger()
            -> snd_soc_dpcm_can_be_free_stop()
                -> if (dpcm->fe == fe)

Excpetion Scenario:
	two FE link to same BE
	FE1 -> BE
	FE2 ->

	Thread 1: switch of mixer between FE2 -> BE
	Thread 2: pcm_stop FE1

Exception:

Unable to handle kernel paging request at virtual address dead0000000000e0

pc=<> [<ffffff8960e2cd10>] dpcm_be_dai_trigger+0x29c/0x47c
	sound/soc/soc-pcm.c:3226
		if (dpcm->fe == fe)
lr=<> [<ffffff8960e2f694>] dpcm_fe_dai_do_trigger+0x94/0x26c

Backtrace:
[<ffffff89602dba80>] notify_die+0x68/0xb8
[<ffffff896028c7dc>] die+0x118/0x2a8
[<ffffff89602a2f84>] __do_kernel_fault+0x13c/0x14c
[<ffffff89602a27f4>] do_translation_fault+0x64/0xa0
[<ffffff8960280cf8>] do_mem_abort+0x4c/0xd0
[<ffffff8960282ad0>] el1_da+0x24/0x40
[<ffffff8960e2cd10>] dpcm_be_dai_trigger+0x29c/0x47c
[<ffffff8960e2f694>] dpcm_fe_dai_do_trigger+0x94/0x26c
[<ffffff8960e2edec>] dpcm_fe_dai_trigger+0x3c/0x44
[<ffffff8960de5588>] snd_pcm_do_stop+0x50/0x5c
[<ffffff8960dded24>] snd_pcm_action+0xb4/0x13c
[<ffffff8960ddfdb4>] snd_pcm_drop+0xa0/0x128
[<ffffff8960de69bc>] snd_pcm_common_ioctl+0x9d8/0x30f0
[<ffffff8960de1cac>] snd_pcm_ioctl_compat+0x29c/0x2f14
[<ffffff89604c9d60>] compat_SyS_ioctl+0x128/0x244
[<ffffff8960283740>] el0_svc_naked+0x34/0x38
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: NKaiChieh Chuang <kaichieh.chuang@mediatek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 78a24e10 ("ASoC: soc-core: clear platform pointers on error")
re-worked the clean-up of any platform pointers that may have been
initialised by the function snd_soc_init_platform(). This commit missed
one error path where if any of the prelinks for a soundcard failed to
initialise, then these platform pointers would not be cleaned-up. This
then prevents the soundcard from being initialised following a probe
deferral when any of the soundcard prelinks cannot be found.

Fix this by ensuring that soc_cleanup_platform() is called when
initialising the soundcard prelinks fails.

Fixes: 78a24e10 ("ASoC: soc-core: clear platform pointers on error")
Signed-off-by: NJonathan Hunter <jonathanh@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The ASoC core has for the longest time increased the module reference
counts, even before the transition to the component model. This is
probably fine on most platforms, but it introduces a deadlock case on
Intel devices with the Skylake and SOF drivers which cannot be removed
due to their reference counts being modified by the core.

In these 2 cases, the PCI or ACPI driver .probe creates a platform
device to let the machine driver .probe register the audio
card. Conversely the PCI or ACPI driver .remove will unregister the
platform device which results in the card being removed by the machine
driver .remove.

With ascii art, this can be represented as

modprobe
snd_soc_skl/
soc-pci-dev/sof-acpci-dev  ----------> pci/acpi probe
       ^                                    |
       |                     ---------------|
       |                    |               |
       |                    V               V
    increase            register        register machine
    refcount            component       platform_device
       ^                                    |
       |                                    |
       |                                    V
    component <----   register card  <---- probe
    probe

The issue is that by playing with the component's module reference
counts during the card registration, it's no longer possible to remove
the module which controls the component. This can be shown, e.g. with
the following error:

root@plb-XPS-13-9350:~# lsmod | grep snd_soc_skl
snd_soc_skl           110592  1

root@plb-XPS-13-9350:~# rmmod snd_soc_skl
rmmod: ERROR: Module snd_soc_skl is in use

Increasing the reference count during the component probe is not
useful. If the PCI/ACPI module is removed, the card will be removed
anyway.

To avoid breaking existing platforms and allowing Intel platforms to
safely deal with module load/unload cases, this patch introduces a
flag which needs to be set during the component initialization. This
is a strictly opt-in capability that should only be used when the
handling of the component module does not require a reference count
increase to prevent removal during use.

Note that this solution is not directly applicable to the legacy
Atom/SST driver, which uses a different device hierarchy. There are
however additional refcount issues which prevent the ACPI driver from
being removed. This is a different issue which would need a different
patch.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Originally snd_soc_init_platform was not cleaning up its pointers, this
was fixed to always reallocate dynamic memory but created a memory leak
when snd_soc_init_platform was called multiple times during the same
probe attempt and also threw away any changes made to the struct between
calls. In order to avoid reallocating memory that is still valid, the
behaviour will be changed to clear the dynamically set pointers on a
probe error and a unregister event and snd_soc_init_platform will go
back to its original behaviour of only allocating null pointers so it will
stop throwing away valid changes.
Signed-off-by: NCurtis Malainey <cujomalainey@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

rmmod/modprobe tests expose a kernel oops when accessing the dai
driver pointer. This comes from the topology design which operates in
multiple passes. Each object removal happens at a specific iteration,
and the code checks for the iteration (order) number after the memory
containing the order was freed.

Fix this be clearing a reference to the dai driver and check its
validity to avoid dereferences.
Signed-off-by: NGuennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We can use for_each_link_codecs() without waiting
for_each_rtd_codec_dai() on soc_bind_dai_link().
Let's use for_each macro.

Fixes: 50acc7e49 ("ASoC: core: Fix multi-CODEC setups")
Fixes: 10dff9b0 ("ASoC: soc-core: use for_each_link_codecs() for dai_link codecs")
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>