We have below 2 functions, but these are very similar

(A)	snd_soc_unregister_component_by_driver()
(B)	snd_soc_unregister_component()

(A)	void snd_soc_unregister_component_by_driver(...)
	{
		...

(a)		mutex_lock(&client_mutex);
 ^ (X)		component = snd_soc_lookup_component_nolocked(dev, component_driver->name);
 |		if (!component)					   ^^^^^^^^^^^^^^^^^^^^^^
 |			goto out;
(b)
 |		snd_soc_del_component_unlocked(component);
 v
	out:
(c)		mutex_unlock(&client_mutex);
	}

(B)	void snd_soc_unregister_component_by_driver(...)
	{
(a)		mutex_lock(&client_mutex);
 ^		while (1) {
 | (X)			struct snd_soc_component *component = snd_soc_lookup_component_nolocked(dev, NULL);
 |												     ^^^^
(b)			if (!component)
 |				break;
 |
 |			snd_soc_del_component_unlocked(component);
 v		}
(c)		mutex_unlock(&client_mutex);
	}

Both are calling lock (a), find component and remove it (b), and
unlock (c). The big diff is whether use driver name for lookup() or
not (X).

Merge these into snd_soc_unregister_component_by_driver() (B), and
snd_soc_unregister_component_by_driver() (A) can be macro.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87h61qy2vn.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

We don't need these definitions. Remove it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87ldr6pqlh.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

There is no snd_soc_disconnect_sync() implementation, and no one is
using it. Let's remove it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87jz6qpql7.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:

We are using dummy component/dlc, but didn't have its check funciton.
This patch adds it.

We have snd_soc_xxx_is_dummy() functions, but not for dlc.
Let's add it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87cydc8vup.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>

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 <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20250404101622.3673850-1-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>

With the addition of the soc_mixer_ctl_to_reg() helper it is now very
clear that the only difference between snd_soc_put_volsw() and
snd_soc_put_volsw_range() is that the former supports double controls
with both values in the same register. As such we can combine both
functions.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250318171459.3203730-11-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

With the addition of the soc_mixer_reg_to_ctl() helper it is now very
clear that the only difference between snd_soc_get_volsw() and
snd_soc_get_volsw_range() is that the former supports double controls
with both values in the same register. As such we can combine both
functions.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250318171459.3203730-10-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

The only difference between snd_soc_info_volsw() and
snd_soc_info_volsw_range() is that the later will not force a 2
value control to be of type integer if the name ends in "Volume".

The kernel currently contains no users of snd_soc_info_volsw_range()
that would return a boolean control with this code, so the risk is
quite low and it seems appropriate that it should contain volume
control detection. So remove snd_soc_info_volsw_range() and point its
users at snd_soc_info_volsw().

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250318171459.3203730-9-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Merge the for-6.14 to resolve conflicts with simple-card-utils.c due to
parallel delveopment.