ASoC: pxa: add I2C dependencies as needed

We have in the past added 'depends on I2C' for some of the PXA boards
after hitting randconfig build bugs. I have seens a couple of new
bugs in this area during the linux-next cycle for 3.16, after it
became possible to build some more PXA machines with I2C disabled.

To shut this up for good, this adds the dependency to every board
that uses I2C as the interface to the codec. I have gone through
all board files and verified that they all either use AC97 or
I2C, and this annotates the latter. Some of these already enable
I2C from mach-pxa/Kconfig, but since that can change it's better
to be explicit here.

The link error that can result otherwise happens when CONFIG_I2C
is set to 'm' and the codec driver is built-in as a result of being
selected by the platform specific glue.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: MMP audio needs sram support

From e7a94bb7fb871c73cc85712d89c1f48d0271c1be Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 5 Jun 2014 12:31:28 +0200
Subject: [PATCH] ASoC: MMP audio needs sram support

Building the pxa/mmp audio driver without support for the mmp
sram driver enabled results in this link error:

sound/built-in.o: In function `mmp_pcm_free_dma_buffers':
:(.text+0x3e734): undefined reference to `sram_get_gpool'
sound/built-in.o: In function `mmp_pcm_new':
:(.text+0x3e7c0): undefined reference to `sram_get_gpool'

The sram driver is cannot be manually enabled and needs to
be turned on by selecting MMP_SRAM from each module that
needs it, which is what this patch does.

Ideally, MMP should move over to the generic SRAM support, but
for the moment, we can avoid the build error.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: sigmadsp: Split regmap and I2C support into separate modules

When the SigmaDSP module is built-in, but the I2C core is build as a module
we'll get a undefined reference:

	sound/built-in.o: In function `sigma_action_write_i2c':
		:(.text+0x5d8d4): undefined reference to `i2c_master_send'

This can happen if a audio driver that is using the regmap SigmaDSP interface is
built into the kernel, but core I2C support is build as a module. To fix this
split the SigmaDSP module into three modules, one module providing the core
infrastructure and two small modules implementing the regmap and I2C interfaces.
This allows e.g. the core infrastructure and regmap support to be built into the
kernel while I2C support can still be build as a module.

Fixes: dab464b60 ("ASoC: Add ADAU1361/ADAU1761 audio CODEC support")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: dapm: Make sure register value is in sync with DAPM kcontrol state

Commit c9e065c27fe9 ("ASoC: dapm: Make sure to always update the DAPM graph
in _put_volsw()") stopped updating register values in those cases where
initial after boot state of kcontrol appears to not change but where
register value still needs update because it is not in sync with the
kcontrol state.

Fix this by doing snd_soc_test_bits() unconditionally as it was before but
by using separate flags for kcontrol and register state changes. This allow
both DAPM graph to be updated when disabling auto-muted control and update
register if it is out-of-sync in respect of kcontrol state.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: fsl_spdif: Fix incorrect usage of regmap_read()

We should not copy the return value into this val since it's supposed to
get the value of the register not the success result of regmap_read().
Thus fix it.

Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: fsl_spdif: Fix integer overflow when calculating divisors

The calculation code does
u64 = (u32 - u32) * 100000;

The 64 bits are of no help here as the type is casted only after the
multiplication, and therefore the result may overflow, possibly causing
inoptimal or wrong clock setup in an unfortunate case (the maximum
result value of the first substraction is currently 47999).

Fix the code to cast before multiplication.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Acked-by: Nicolin Chen <Guangyu.Chen@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: rsnd: fixup index of src/dst mod when capture

Index of dma name should use -1, not +1 when capture case.
Thank you Dan.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
ASoC: fsl: Fix build problem

Commit 432481220 (ASoC: fsl-ssi: Use regmap) removed struct ccsr_ssi.
Unfortunately, the structure is still used. This causes
mpc85xx_smp_defconfig and mpc85xx_defconfig builds to fail with

sound/soc/fsl/fsl_dma.c:926:50:
  error: invalid use of undefined type 'struct ccsr_ssi'
  dma->ssi_stx_phys = res.start + offsetof(struct ccsr_ssi, stx0);
ound/soc/fsl/fsl_dma.c:927:50:
  error: invalid use of undefined type 'struct ccsr_ssi'
  dma->ssi_srx_phys = res.start + offsetof(struct ccsr_ssi, srx0);

Fix by using constants, similar to original commit.

Cc: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@linaro.org>
Merge remote-tracking branch 'asoc/fix/core' into asoc-linus
Merge remote-tracking branches 'asoc/fix/fsl-dma', 'asoc/fix/fsl-spdif', 'asoc/fix/pxa', 'asoc/fix/rcar' and 'asoc/fix/sigmadsp' into asoc-linus
ALSA: control: Protect user controls against concurrent access

The user-control put and get handlers as well as the tlv do not protect against
concurrent access from multiple threads. Since the state of the control is not
updated atomically it is possible that either two write operations or a write
and a read operation race against each other. Both can lead to arbitrary memory
disclosure. This patch introduces a new lock that protects user-controls from
concurrent access. Since applications typically access controls sequentially
than in parallel a single lock per card should be fine.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: control: Fix replacing user controls

There are two issues with the current implementation for replacing user
controls. The first is that the code does not check if the control is actually a
user control and neither does it check if the control is owned by the process
that tries to remove it. That allows userspace applications to remove arbitrary
controls, which can cause a user after free if a for example a driver does not
expect a control to be removed from under its feed.

The second issue is that on one hand when a control is replaced the
user_ctl_count limit is not checked and on the other hand the user_ctl_count is
increased (even though the number of user controls does not change). This allows
userspace, once the user_ctl_count limit as been reached, to repeatedly replace
a control until user_ctl_count overflows. Once that happens new controls can be
added effectively bypassing the user_ctl_count limit.

Both issues can be fixed by instead of open-coding the removal of the control
that is to be replaced to use snd_ctl_remove_user_ctl(). This function does
proper permission checks as well as decrements user_ctl_count after the control
has been removed.

Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at
beginning of the function if the control already exists is removed. This is not
a problem though since the check is quite useless, because the lock that is
protecting the control list is released between the check and before adding the
new control to the list, which means that it is possible that a different
control with the same settings is added to the list after the check. Luckily
there is another check that is done while holding the lock in snd_ctl_add(), so
we'll rely on that to make sure that the same control is not added twice.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: control: Don't access controls outside of protected regions

A control that is visible on the card->controls list can be freed at any time.
This means we must not access any of its memory while not holding the
controls_rw_lock. Otherwise we risk a use after free access.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: control: Handle numid overflow

Each control gets automatically assigned its numids when the control is created.
The allocation is done by incrementing the numid by the amount of allocated
numids per allocation. This means that excessive creation and destruction of
controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to
eventually overflow. Currently when this happens for the control that caused the
overflow kctl->id.numid + kctl->count will also over flow causing it to be
smaller than kctl->id.numid. Most of the code assumes that this is something
that can not happen, so we need to make sure that it won't happen

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: control: Make sure that id->index does not overflow

The ALSA control code expects that the range of assigned indices to a control is
continuous and does not overflow. Currently there are no checks to enforce this.
If a control with a overflowing index range is created that control becomes
effectively inaccessible and unremovable since snd_ctl_find_id() will not be
able to find it. This patch adds a check that makes sure that controls with a
overflowing index range can not be created.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge tag 'asoc-v3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v3.16

Quite a few build coverage fixes in here among the usual small driver
fixes includling the sigmadsp change from Lars - moving the driver to
separate modules per bus (which is basically just code motion) avoids
issues with some combinations of buses being enabled.
Merge branch 'topic/core-vuln-fixes' into for-linus