Merge tag 'asoc-v5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next

ASoC: Updates for v5.5

Some big changes in the core but more about cleanps and refactorings
than new features, plus a collection of new drivers and lots of small
fixes and improvements to existing ones.

 - Lots more cleanups from Morimoto-san.  Now that everything is a
   component this is mostly about refactorings to clarify and simplify
   the core, a combination of things that are no longer required due to
   refactorings and spotting similarities.
 - Many fixes to the Sound Open Firmware code.
 - Wake on voice support for Chromebooks.
 - SPI support for RT5677.
 - New drivers for Analog Devices ADAU7118, Intel Cannonlake systems
   with RT1011 and RT5682, Texas Instruments TAS2562 and TAS2770.

When using the example SOF amp widget topology, KASAN dumps this
when the AMP bytes kcontrol gets loaded:

[ 9.579548] BUG: KASAN: slab-out-of-bounds in
sof_control_load+0x8cc/0xac0 [snd_sof]
[ 9.588194] Write of size 40 at addr ffff8882314559dc by task
systemd-udevd/2411

Fix that by rejecting the topology if the bytes data size > max_size

Fixes: 311ce4fe ("ASoC: SOF: Add support for loading topologies")
Reviewed-by: Jaska Uimonen <jaska.uimonen@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191106145816.9367-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The fuzzer tries to open the timer instances as much as possible, and
this may cause a system hiccup easily.  We've already introduced the
cap for the max number of available instances for the h/w timers, and
we should put such a limit also to the slave timers, too.

This patch introduces the limit to the multiple opened slave timers.
The upper limit is hard-coded to 1000 for now, which should suffice
for any practical usages up to now.

Link: https://lore.kernel.org/r/20191106154257.5853-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Merge branch 'for-5.4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-5.5

snd_soc_unregister_component() is calling snd_soc_lookup_component()
under mutex_lock(). But, snd_soc_lookup_component() itself is using
mutex_lock(), thus it will be dead-lock.
This patch adds _nolocked version of it, and avoid dead-lock issue.

Fixes: ac6a4dd3("ASoC: soc-core: use snd_soc_lookup_component() at snd_soc_unregister_component()")
Reported-by: "kernelci.org bot" <bot@kernelci.org>"
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87bltph4da.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

SOF module load/unload tests show nasty recurring warnings:

WARNING: CPU: 5 PID: 1339 at sound/core/control.c:466
snd_ctl_remove+0xf0/0x100 [snd]
RIP: 0010:snd_ctl_remove+0xf0/0x100 [snd]

This regression was introduced by the removal of the call to
soc_remove_link_components() before soc_card_free() is invoked.

Go back to the initial order but only call
soc_remove_link_components() once.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Fixes: 5a4c9f05 ("ASoC: soc-core: snd_soc_unbind_card() cleanup")
GitHub issue: https://github.com/thesofproject/linux/issues/1424Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191106145801.9316-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

When using the example SOF amp widget topology, KASAN dumps this
when the AMP bytes kcontrol gets loaded:

[ 9.579548] BUG: KASAN: slab-out-of-bounds in
sof_control_load+0x8cc/0xac0 [snd_sof]
[ 9.588194] Write of size 40 at addr ffff8882314559dc by task
systemd-udevd/2411

Fix that by rejecting the topology if the bytes data size > max_size

Fixes: 311ce4fe ("ASoC: SOF: Add support for loading topologies")
Reviewed-by: Jaska Uimonen <jaska.uimonen@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191106145816.9367-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The macro will be removed soon later, so update the documentation to
reflect that as well.

Link: https://lore.kernel.org/r/20191105151856.10785-25-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro.  The macro didn't give any better readability.

Link: https://lore.kernel.org/r/20191105151856.10785-24-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro.  The macro didn't give any better readability.

Along with it, drop the unnecessary assignment before the
snd_dma_alloc_pages() call and simplify by returning the error code
directly.

Link: https://lore.kernel.org/r/20191105151856.10785-23-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro.  The macro didn't give any better readability.

Along with it, the unneeded assignment before snd_dma_alloc_pages*()
call is dropped.

Link: https://lore.kernel.org/r/20191105151856.10785-22-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro.  The macro didn't give any better readability.

Also slightly refactor the code (drop the return value check from the
preallocation) as it never returns an error.

Link: https://lore.kernel.org/r/20191105151856.10785-21-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro.  The macro didn't give any better readability.

Link: https://lore.kernel.org/r/20191105151856.10785-20-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

snd_pcm_sgbuf_ops_page is no longer needed to be set explicitly to PCM
page ops since the recent change in the PCM core (*).  Leaving it NULL
should work as long as the preallocation has been done properly.

This patch drops the redundant lines.

(*) 7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Link: https://lore.kernel.org/r/20191105151856.10785-19-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Link: https://lore.kernel.org/r/20191105151856.10785-18-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Since the driver requires the DMA32 allocation, it passes the
specially encoded device to snd_pcm_lib_preallocate_pages().

Link: https://lore.kernel.org/r/20191105151856.10785-17-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Since the driver requires the DMA32 allocation, it passes the
specially encoded device to snd_pcm_lib_preallocate_pages().

Link: https://lore.kernel.org/r/20191105151856.10785-16-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Link: https://lore.kernel.org/r/20191105151856.10785-15-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Link: https://lore.kernel.org/r/20191105151856.10785-14-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Link: https://lore.kernel.org/r/20191105151856.10785-13-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Link: https://lore.kernel.org/r/20191105151856.10785-12-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Link: https://lore.kernel.org/r/20191105151856.10785-11-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page
                  mapping in the default mmap handler

Link: https://lore.kernel.org/r/20191105151856.10785-10-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling.  This patch
coverts to the common code.
(*) 1fe7f397: ALSA: memalloc: Add vmalloc buffer allocation
                  support
    7e8edae3: ALSA: pcm: Handle special page mapping in the
                  default mmap handler

Also, since the SG-buffer-specific PCM ops becomes identical with the
normal PCM ops, unify them again to the single ops, too.

Link: https://lore.kernel.org/r/20191105151856.10785-9-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

A few error handling code was forgotten where it never reaches.
Drop it.

Link: https://lore.kernel.org/r/20191105151856.10785-8-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.

Link: https://lore.kernel.org/r/20191105151856.10785-7-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.

Link: https://lore.kernel.org/r/20191105151856.10785-6-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.

Link: https://lore.kernel.org/r/20191105151856.10785-5-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.

Link: https://lore.kernel.org/r/20191105151856.10785-4-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.

Link: https://lore.kernel.org/r/20191105151856.10785-3-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent change (commit 08422d2c: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.

Link: https://lore.kernel.org/r/20191105151856.10785-2-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

It makes little sense to create prealloc proc files for streams that
have the zero max size, which is a typical case for vmalloc buffers.
Skip the proc file creations to save resources in such a case.

Link: https://lore.kernel.org/r/20191105191007.18150-3-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Warn if snd_pcm_lib_preallocate_pages*() is applied to the stream that
has already the preallocated buffers and skip the allocation.  It's a
clearly a driver bug.

Link: https://lore.kernel.org/r/20191105191007.18150-2-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

The recent changes simplified the required setup for SG- and vmalloc-
buffers.  Update the documentation accordingly.

Link: https://lore.kernel.org/r/20191105080138.1260-5-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

When a driver needs to deal with a special buffer like a SG or a
vmalloc buffer, it has to set up the PCM page ops explicitly for the
corresponding helper function.  This is rather error-prone and many
people forgot or incorrectly used it.

For simplifying the call patterns and avoiding such a potential bug,
this patch enhances the PCM default mmap handler to check the
(pre-)allocated buffer type and handles the page gracefully depending
on the buffer type.  If the PCM page ops is given, the ops is still
used in a higher priority.  The new code path is only for the default
(NULL page ops) case.

Link: https://lore.kernel.org/r/20191105080138.1260-4-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

This patch adds the vmalloc buffer support to ALSA memalloc core.  A
new type, SNDRV_DMA_TYPE_VMALLOC was added.

The vmalloc buffer has been already supported in the PCM via a few own
helper functions, but the user sometimes get confused and misuse
them.  With this patch, the whole buffer management is integrated into
the memalloc core, so they can be used in a sole common way.

Link: https://lore.kernel.org/r/20191105080138.1260-3-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Currently we pass the artificial device pointer to the allocation
helper in the case of SNDRV_DMA_TYPE_CONTINUOUS for passing the GFP
flags.  But all common cases are the allocations with GFP_KERNEL, and
it's messy to put this in each place.

In this patch, the memalloc core helper is changed to accept the NULL
device pointer and it treats as the default mode, GFP_KERNEL, so that
all callers can omit the complex argument but just leave NULL.

Link: https://lore.kernel.org/r/20191105080138.1260-2-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

snd_soc_dobj is used only when SND_SOC_TOPOLOGY was selected.
Let's enable it under SND_SOC_TOPOLOGY.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87o8xq251d.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

soc-core has some API which is used from topology, but it is doing
topology specific operation at soc-core.
soc-core should care about core things, and topology should care
about topology things, otherwise, it is very confusable.

For example topology type is not related to soc-core,
it is topology side issue.

This patch removes meaningless check from soc-core.

This patch keeps extra initialization/destruction at
snd_soc_add_dai_link() / snd_soc_remove_dai_link()
which were for topology.
From this patch, non-topology card can use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87pni6251h.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

ALSA SoC has 2 functions.
snd_soc_register_dai()  is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()

In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.

This patch calls snd_soc_register_dai() from snd_soc_register_dais()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87r22m251l.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>