Add a NULL check in snd_pci_quirk_lookup() so that NULL can be passed
as a pci_dev pointer.  This fixes the possible NULL dereferences in
HD-audio drivers.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The calculated frame size was wrong because snd_pcm_format_physical_width()
actually returns the number of bits, not bytes.

Use snd_pcm_format_size() instead, which not only returns bytes, but also
simplifies the calculation.

Fixes: 8bea869c ("ALSA: PCM midlevel: improve fifo_size handling")
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

XMOS based USB DACs with native DSD support expose this feature via a USB
alternate setting. The audio format is either 32-bit raw or a 32-bit PCM format.
To utilize this feature on linux this patch introduces a new 32-bit DSD
sampleformat DSD_U32_LE.
A follow up patch will add a quirk for XMOS based devices to utilize the new format.
Further patches will add support to alsa-lib.
Signed-off-by: NJurgen Kramer <gtmkramer@xs4all.nl>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Changing an interval boundary to a multiple of the step size makes that
boundary exact.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The min parameter was not used by any caller.  And if it were used,
underflows in the calculations could lead to incorrect results.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The previous commit for the non-atomic PCM ops added more codes to
snd_pcm_stream_lock() and its variants.  Since they are inlined
functions, it resulted in a significant code size bloat.  For reducing
the size bloat, this patch changes the inline functions to the normal
function calls.  The export of rwlock and rwsem are removed as well,
since they are referred only in pcm_native.c now.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently, many PCM operations are performed in a critical section
protected by spinlock, typically the trigger and pointer callbacks are
assumed to be atomic.  This is basically because some trigger action
(e.g. PCM stop after drain or xrun) is done in the interrupt handler.
If a driver runs in a threaded irq, however, this doesn't have to be
atomic.  And many devices want to handle trigger in a non-atomic
context due to lengthy communications.

This patch tries all PCM calls operational in non-atomic context.
What it does is very simple: replaces the substream spinlock with the
corresponding substream mutex when pcm->nonatomic flag is set.  The
driver that wants to use the non-atomic PCM ops just needs to set the
flag and keep the rest as is.  (Of course, it must not handle any PCM
ops in irq context.)

Note that the code doesn't check whether it's atomic-safe or not, but
trust in 100% that the driver sets pcm->nonatomic correctly.

One possible problem is the case where linked PCM substreams have
inconsistent nonatomic states.  For avoiding this, snd_pcm_link()
returns an error if one tries to link an inconsistent PCM substream.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Right now we set 0 as the silence data for DSD_U8 and DSD_U16 formats,
but this is actually wrong.  0 is rather the most negative value.
Alternatively, we may take the repeating 0x69 pattern like ffmpeg
deploys.

Reference: https://ffmpeg.org/pipermail/ffmpeg-cvslog/2014-April/076427.htmlSuggested-by: NAlexander E. Patrakov <patrakov@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_info_get_line() documents that its last parameter must be one
less than the buffer size, but this API design guarantees that
(literally) every caller gets it wrong.

Just change this parameter to have its obvious meaning.
Reported-by: NTommi Rantala <tt.rantala@gmail.com>
Cc: <stable@vger.kernel.org> # v2.2.26+
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

I forgot to add the new fields in sw_params to 32bit compat layer.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For controlling the new fields more strictly, add sw_params.proto
field indicating the protocol version of the user-space.  User-space
should fill the SNDRV_PCM_VERSION value it's built with, then kernel
can know whether the new fields should be evaluated or not.

And now tstamp_type field is evaluated only when the valid value is
set there.  This avoids the wrong override of tstamp_type to zero,
which is SNDRV_PCM_TSTAMP_TYPE_GETTIMEOFDAY.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

I previously added an integer overflow check here but looking at it now,
it's still buggy.

The bug happens in snd_compr_allocate_buffer().  We multiply
".fragments" and ".fragment_size" and that doesn't overflow but then we
save it in an unsigned int so it truncates the high bits away and we
allocate a smaller than expected size.

Fixes: b35cc822 ('ALSA: compress_core: integer overflow in snd_compr_allocate_buffer()')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of hard-coded magic numbers, define constants for op_flag to
tlv callbacks.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For allowing adjusting the timestamp type on the fly, add it to
sw_params.  The existing ioctl is still kept for compatibility.

Along with this, increment the PCM protocol version.

The extension was suggested by Clemens Ladisch.
Acked-by: NJaroslav Kysela <perex@perex.cz>
Reviewed-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

No functional change.
Acked-by: NJaroslav Kysela <perex@perex.cz>
Reviewed-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In case of _3LE/_3BE formats the samples are stored in 3 consecutive bytes
without padding it to 4 bytes. This means that the DMA needs to be able to
support 3 bytes word length in order to read/write the samples from memory
correctly. Originally the code treated 24 bits physical length samples as
they were 32 bits which leads to corruption when playing or recording audio.

The hw.formats field has already been prepared to exclude formats not
supported by the DMA engine in use, which means that only on platforms where
3 bytes is supported by the DMA will be able to use this format.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

params_physical_width() is available via pcm_params.h
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add a newline and, while at it, remove a space and redundant braces.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

do_posix_clock_monotonic_gettime() is a leftover from the initial
posix timer implementation which maps to ktime_get_ts().
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Sometimes PORT_EXIT messages are lost when a process is exiting.
This happens if you subscribe to the announce port with client A,
then subscribe to the announce port with client B, then kill client A.
Client B will not see the PORT_EXIT message because client A's port is
closing and is earlier in the announce port subscription list. The
for each loop will try to send the announcement to client A and fail,
then will stop trying to broadcast to other ports. Killing B works fine
since the announcement will already have gone to A. The CLIENT_EXIT
message does not get lost.

How to reproduce problem:

*** termA
$ aseqdump -p 0:1
  0:1   Port subscribed            0:1 -> 128:0

*** termB
$ aseqdump -p 0:1

*** termA
  0:1   Client start               client 129
  0:1   Port start                 129:0
  0:1   Port subscribed            0:1 -> 129:0

*** termB
  0:1   Port subscribed            0:1 -> 129:0

*** termA
^C

*** termB
  0:1   Client exit                client 128
   <--- expected Port exit as well (before client exit)
Signed-off-by: NAdam Goode <agoode@google.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_seq_event_dup returns -ENOMEM in some buffer-full conditions,
but usually returns -EAGAIN. Make -EAGAIN trigger the overflow
condition in snd_seq_fifo_event_in so that the fifo is cleared
and -ENOSPC is returned to userspace as stated in the alsa-lib docs.
Signed-off-by: NAdam Goode <agoode@google.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently snd_dmaengine_pcm_trigger() calls dmaengine_pause()
unconditinally during device suspend. In case where DMA controller
doesn't support PAUSE/RESUME functionality, this call is not able
to stop the DMA controller. In this scenario, audio playback doesn't
resume after device resume.

Calling dmaengine_pause/dmaengine_terminate_all conditionally fixes
the issue.

It has been tested with audio playback on Samsung platform having
PL330 DMA controller which doesn't support PAUSE/RESUME.
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fix format string mismatch in snd_seq_midisynth_register_port().
Argument type of p is unsigned int.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

BugLink: http://bugs.launchpad.net/bugs/1305480

The kerneloops-daemon scans dmesg for common crash signatures, among
which is 'BUG:'. The message emitted by the PCM library is really a
warning, so the most expedient thing to do seems to be to change the
string.
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The snd_compr_open function would always return 0 even if the compressed
ops open function failed, obviously this is incorrect. Looks like this
was introduced by a small typo in:

commit a0830dbd
ALSA: Add a reference counter to card instance

This patch returns the value from the compressed op as it should.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just a cleanup to follow the standard coding style.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A few code cleanups and optimizations.  In addition, drop
snd_device_disconnect() that isn't used at all, and drop the return
values from snd_device_free*().

Another slight difference by this change is that now the device state
will become always SNDRV_DEV_REGISTERED no matter whether dev_register
ops is present or not.  It's for better consistency.  There should be
no impact for the current tree, as the state isn't checked.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Basically, the device type specifies the priority of the device to be
registered / freed, too.  However, the priority value isn't well
utilized but only it's checked as a group.  This results in
inconsistent register and free order (where each of them should be in
reversed direction).

This patch simplifies the device list management code by simply
inserting a list entry at creation time in an incremental order for
the priority value.  Since we can just follow the link for register,
disconnect and free calls, we don't have to specify the group; so the
whole enum definitions are also simplified as well.

The visible change to outside is that the priorities of some object
types are revisited.  For example, now the SNDRV_DEV_LOWLEVEL object
is registered before others (control, PCM, etc) and, in return,
released after others.  Similarly, SNDRV_DEV_CODEC is in a lower
priority than SNDRV_DEV_BUS for ensuring the dependency.

Also, the unused SNDRV_DEV_TOPLEVEL, SNDRV_DEV_LOWLEVEL_PRE and
SNDRV_DEV_LOWLEVEL_NORMAL are removed as a cleanup.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just like PCM, allow hwdep to be assigned to a different parent device
than the card.  It'll be used for the HD-audio codec device in the
later patches.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For referring to a different object from sysfs ops, take hwdep
private_data as stored via dev_set_drvdata() at creating the device
object.  In that way, the same sysfs ops can be used by different
device types.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of calling each time device_create_file(), create the groups
of sysfs attribute files at once in a normal way.  Add a new helper
function, snd_get_device(), to return the associated device object,
so that we can handle the sysfs addition locally.

Since the sysfs file addition is done differently now,
snd_add_device_sysfs_file() helper function is removed.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Allow modules to use it, fixing a build failure when the newly added
ADAU1977 driver is built as a module.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NTakashi Iwai <tiwai@suse.de>

While moving the card device into struct snd_card, the reference to
the assigned card in sysfs show/store callbacks were forgotten to be
refreshed, still accessing to the no longer used drvdata.  Fix these
places to refer correctly via container_of().

Also, remove the superfluous NULL checks since it's guaranteed to be
non-NULL now.

Fixes: 8bfb181c ('ALSA: Embed card device into struct snd_card')
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Using __bitwise and typedefs for the attributes of snd_device struct
isn't so useful, and rather it worsens the readability.  Let's drop
them and use the straightforward enum.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use the standard pr_xxx() helpers instead of home-baked snd_print*().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>