linux.git/sound, branch v4.9

dbri: move dereference after check for NULL

2016-12-06T17:18:22+00:00

We accidentally introduced a dereference before the NULL check in
xmit_descs() as part of silencing a GCC warning.

Fixes: 16f46050e709 ("dbri: Fix compiler warning")
Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc

2016-11-28T21:53:19+00:00

Pull sparc fixes from David Miller:
 "Two ugly build warning fixes"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  dbri: Fix compiler warning
  qlogicpti: Fix compiler warnings

dbri: Fix compiler warning

2016-11-28T20:51:31+00:00

dbri uses 'u32' for dma handle while invoking kernel DMA APIs,
instead of using dma_addr_t. This hasn't caused any 'incompatible
pointer type' warning on SPARC because until now dma_addr_t is of
type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit
DMA and therefore dma_addr_t became of type u64. This makes
'incompatible pointer type' warnings inevitable.

e.g.
sound/sparc/dbri.c: In function ‘snd_dbri_create’:
sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type
./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’

For the record, dbri(sbus) driver never executes on sun4v. Therefore
even though 64bit DMA is enabled on SPARC, dbri continues to use
legacy iommu that guarantees DMA address is always in 32bit range.

This patch resolves above compiler warning.

Signed-off-by: Tushar Dave 
Reviewed-by: thomas tai 
Signed-off-by: David S. Miller

Merge tag 'sound-4.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

2016-11-18T16:56:47+00:00

Pull sound fixes from Takashi Iwai:
 "Three trivial fixes:

  A regression fix for ASRock mobo, a use-after-free fix at hot-unplug
  of USB-audio, and a quirk for new Thinkpad models"

* tag 'sound-4.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: usb-audio: Fix use-after-free of usb_device at disconnect
  ALSA: hda - Fix mic regression by ASRock mobo fixup
  ALSA: hda - add a new condition to check if it is thinkpad

ALSA: usb-audio: Fix use-after-free of usb_device at disconnect

2016-11-14T21:05:04+00:00

The usb-audio driver implements the deferred device disconnection for
the device in use.  In this mode, the disconnection callback returns
immediately while the actual ALSA card object removal happens later
when all files get closed.  As Shuah reported, this code flow,
however, leads to a use-after-free, detected by KASAN:

 BUG: KASAN: use-after-free in snd_usb_audio_free+0x134/0x160 [snd_usb_audio] at addr ffff8801c863ce10
 Write of size 8 by task pulseaudio/2244
 Call Trace:
  [] dump_stack+0x67/0x94
  [] kasan_object_err+0x21/0x70
  [] kasan_report_error+0x1fa/0x4e0
  [] ? kasan_slab_free+0x87/0xb0
  [] __asan_report_store8_noabort+0x43/0x50
  [] ? snd_usb_audio_free+0x134/0x160 [snd_usb_audio]
  [] snd_usb_audio_free+0x134/0x160 [snd_usb_audio]
  [] snd_usb_audio_dev_free+0x31/0x40 [snd_usb_audio]
  [] __snd_device_free+0x12a/0x210
  [] snd_device_free_all+0x85/0xd0
  [] release_card_device+0x34/0x130
  [] device_release+0x76/0x1e0
  [] kobject_release+0x107/0x370
  .....
 Object at ffff8801c863cc80, in cache kmalloc-2048 size: 2048
 Allocated:
  [] save_stack_trace+0x2b/0x50
  [] save_stack+0x46/0xd0
  [] kasan_kmalloc+0xad/0xe0
  [] kmem_cache_alloc_trace+0xfa/0x240
  [] usb_alloc_dev+0x57/0xc90
  [] hub_event+0xf1d/0x35f0
  ....
 Freed:
  [] save_stack_trace+0x2b/0x50
  [] save_stack+0x46/0xd0
  [] kasan_slab_free+0x71/0xb0
  [] kfree+0xd9/0x280
  [] usb_release_dev+0xde/0x110
  [] device_release+0x76/0x1e0
  ....

It's the code trying to clear drvdata of the assigned usb_device where
the usb_device itself was already released in usb_release_dev() after
the disconnect callback.

This patch fixes it by checking whether the code path is via the
disconnect callback, i.e. chip->shutdown flag is set.

Fixes: 79289e24194a ('ALSA: usb-audio: Refer to chip->usb_id for quirks...')
Reported-and-tested-by: Shuah Khan 
Cc:  # v4.6+
Signed-off-by: Takashi Iwai

ASoC: lpass-platform: fix uninitialized variable

2016-11-14T17:46:08+00:00

In commit 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data
usage") the stream specific information initialization was broken, with
the dma channel information not being initialized if there was no
alloc_dma_channel() helper function.

Before that, the DMA channel number was implicitly initialized to zero
because the backing store was allocated with devm_kzalloc().  When the
init code was rewritten, that implicit initialization was lost, and gcc
rightfully complains about an uninitialized variable being used.

Cc: Srinivas Kandagatla 
Cc: Mark Brown 
Signed-off-by: Linus Torvalds

ALSA: hda - Fix mic regression by ASRock mobo fixup

2016-11-11T11:33:20+00:00

The commit [1a3f099101b8: ALSA: hda - Fix surround output pins for
ASRock B150M mobo] introduced a fixup of pin configs for ASRock
mobos to fix the surround outputs.  However, this overrides the pin
configs of the mic pins as if they are outputs-only, effectively
disabling the mic inputs.  Of course, it's a regression wrt mic
functionality.

Actually the pins 0x18 and 0x1a don't need to be changed; we just need
to disable the bogus pins 0x14 and 0x15.  Then the auto-parser will
pick up mic pins as switchable and assign the surround outputs there.

This patch removes the incorrect pin overrides of NID 0x18 and 0x1a
from the ASRock fixup.

Fixes: 1a3f099101b8 ('ALSA: hda - Fix surround output pins for ASRock...')
Reported-and-tested-by: Vitor Antunes 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=187431
Cc: 
Signed-off-by: Takashi Iwai

ALSA: hda - add a new condition to check if it is thinkpad

2016-11-10T08:32:55+00:00

Latest Thinkpad laptops use the HKEY_HID LEN0268 instead of the
LEN0068, as a result neither audio mute led nor mic mute led can work
any more.

After adding the new HKEY_HID into the is_thinkpad(), both of them
works well as before.

Cc: 
Signed-off-by: Hui Wang 
Signed-off-by: Takashi Iwai

ALSA: info: Return error for invalid read/write

2016-11-08T13:37:26+00:00

Currently the ALSA proc handler allows read or write even if the proc
file were write-only or read-only.  It's mostly harmless, does thing
but allocating memory and ignores the input/output.  But it doesn't
tell user about the invalid use, and it's confusing and inconsistent
in comparison with other proc files.

This patch adds some sanity checks and let the proc handler returning
an -EIO error when the invalid read/write is performed.

Cc:  # v4.2+
Signed-off-by: Takashi Iwai

ALSA: info: Limit the proc text input size

2016-11-08T12:16:40+00:00

The ALSA proc handler allows currently the write in the unlimited size
until kmalloc() fails.  But basically the write is supposed to be only
for small inputs, mostly for one line inputs, and we don't have to
handle too large sizes at all.  Since the kmalloc error results in the
kernel warning, it's better to limit the size beforehand.

This patch adds the limit of 16kB, which must be large enough for the
currently existing code.

Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Takashi Iwai