linux-toradex.git/sound, branch v4.18-rc4

ALSA: seq: Fix UBSAN warning at SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT ioctl

2018-06-25T09:18:04+00:00

The kernel may spew a WARNING with UBSAN undefined behavior at
handling ALSA sequencer ioctl SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT:

UBSAN: Undefined behaviour in sound/core/seq/seq_clientmgr.c:2007:14
signed integer overflow:
2147483647 + 1 cannot be represented in type 'int'
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x122/0x1c8 lib/dump_stack.c:113
 ubsan_epilogue+0x12/0x86 lib/ubsan.c:159
 handle_overflow+0x1c2/0x21f lib/ubsan.c:190
  __ubsan_handle_add_overflow+0x2a/0x31 lib/ubsan.c:198
 snd_seq_ioctl_query_next_client+0x1ac/0x1d0 sound/core/seq/seq_clientmgr.c:2007
 snd_seq_ioctl+0x264/0x3d0 sound/core/seq/seq_clientmgr.c:2144
 ....

It happens only when INT_MAX is passed there, as we're incrementing it
unconditionally.  So the fix is trivial, check the value with
INT_MAX.  Although the bug itself is fairly harmless, it's better to
fix it so that fuzzers won't hit this again later.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200211
Signed-off-by: Takashi Iwai

ALSA: timer: Fix UBSAN warning at SNDRV_TIMER_IOCTL_NEXT_DEVICE ioctl

2018-06-25T09:17:01+00:00

The kernel may spew a WARNING about UBSAN undefined behavior at
handling ALSA timer ioctl SNDRV_TIMER_IOCTL_NEXT_DEVICE:

UBSAN: Undefined behaviour in sound/core/timer.c:1524:19
signed integer overflow:
2147483647 + 1 cannot be represented in type 'int'
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x122/0x1c8 lib/dump_stack.c:113
 ubsan_epilogue+0x12/0x86 lib/ubsan.c:159
 handle_overflow+0x1c2/0x21f lib/ubsan.c:190
 __ubsan_handle_add_overflow+0x2a/0x31 lib/ubsan.c:198
 snd_timer_user_next_device sound/core/timer.c:1524 [inline]
 __snd_timer_user_ioctl+0x204d/0x2520 sound/core/timer.c:1939
 snd_timer_user_ioctl+0x67/0x95 sound/core/timer.c:1994
 ....

It happens only when a value with INT_MAX is passed, as we're
incrementing it unconditionally.  So the fix is trivial, check the
value with INT_MAX.  Although the bug itself is fairly harmless, it's
better to fix it so that fuzzers won't hit this again later.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200213
Reported-and-tested-by: Team OWL337 
Cc: 
Signed-off-by: Takashi Iwai

ALSA: hda/realtek - Fix the problem of two front mics on more machines

2018-06-25T08:01:29+00:00

We have 3 more Lenovo machines, they all have 2 front mics on them,
so they need the fixup to change the location for one of two mics.

Among these 3 Lenovo machines, one of them has the same pin cfg as the
machine with subid 0x17aa3138, so use the pin cfg table to apply fixup
for them. The rest machines don't share the same pin cfg, so far use
the subid to apply fixup for them.

Fixes: a3dafb2200bf ("ALSA: hda/realtek - adjust the location of one mic")
Cc: 
Signed-off-by: Hui Wang 
Signed-off-by: Takashi Iwai

ALSA: hda/realtek - Add a quirk for FSC ESPRIMO U9210

2018-06-22T10:20:56+00:00

Fujitsu Seimens ESPRIMO Mobile U9210 requires the same fixup as H270
for the correct pin configs.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200107
Cc: 
Signed-off-by: Takashi Iwai

ALSA: hda/ca0132: make array ca0132_alt_chmaps static

2018-06-21T19:42:37+00:00

The array ca0132_alt_chmaps is local to the source and does not
need to be in global scope, so make it static.

Cleans up sparse warning:
warning: symbol 'ca0132_alt_chmaps' was not declared. Should it be
static?

Signed-off-by: Colin Ian King 
Signed-off-by: Takashi Iwai

ALSA: hda - Force to link down at runtime suspend on ATI/AMD HDMI

2018-06-21T11:46:56+00:00

Henning Kühn reported that the discrete AMD GPU on his hybrid graphics
laptop no longer runtime-suspends due to the recent commit
07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller").

The root cause is that the HDMI codec on AMD GPU doesn't support
CLKSTOP and EPSS, which are currently mandatory for powering down the
HD-audio link at runtime suspend.  Because the HD-audio link is still
up, HD-audio controller driver blocks the transition to D3.

For addressing the regression, this patch adds a new flag to indicate
the forced link-down, and sets it for AMD HDMI codecs appropriately
in the codec driver.

Fixes: 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106957
Reported-by: Lukas Wunner 
Reported-and-tested-by: Henning Kühn 
Cc:  # v4.17+
Signed-off-by: Takashi Iwai

ALSA: lx6464es: Missing error code in snd_lx6464es_create()

2018-06-21T09:04:42+00:00

We forgot to set the error code on this error path.

Fixes: 4a23fc8cc068 ("ALSA: lx6464es: add error handling for pci_ioremap_bar")
Signed-off-by: Dan Carpenter 
Signed-off-by: Takashi Iwai

ALSA: hda/ca0132: Fix DMic data rate for Alienware M17x R4

2018-06-17T06:45:46+00:00

The commentary says to use various parameters, and lays out what
the mapping is...  The code used a 32KHz rate when the comment
says that it needs to use a 48KHz rate.  And this has been the
case since day one.

On the Alienware M17x R4, the DMic used to have exceptionally quiet
pickup and a lot of noise.  Changing the data rate fixes both of
these issues.

Searching the kernel bug tracker for ca0132-related issues shows no
mention of this being an issue for other hardware, and I have no
other hardware to test with, so a quirk is used to limit the effect
to just the M17x R4.

Signed-off-by: Alastair Bridgewater 
Signed-off-by: Takashi Iwai

ALSA: hda/ca0132: Restore PCM Analog Mic-In2

2018-06-17T06:45:09+00:00

Commit 009b8f979bf8cb5f7ec6d3dd7683585122ed10f8 conditionalized
adding the "CA0132 Analog Mic-In2" PCM with a comment to the
effect that, "desktops don't use this ADC", but the test was set
up such that the ADC was only created for desktops.  Invert the
test.

Fixes: 009b8f979bf8 ("ALSA: hda/ca0132: update core functions for sbz + r3di")
Signed-off-by: Alastair Bridgewater 
Signed-off-by: Takashi Iwai

ALSA: hda/ca0132: Don't test for QUIRK_NONE

2018-06-17T06:44:55+00:00

QUIRK_NONE is, quite explicitly, the default case.  The entire
point of a quirks system is to allow "programming by difference"
from a given base case, which requires that merely defining a new
quirk for some piece of hardware should not change the behavior of
the driver for that hardware.  In turn, this means that testing
for QUIRK_NONE explicitly is a violation of that implicit contract.

Change a test for QUIRK_NONE and QUIRK_ALIENWARE to default, and
add a test for QUIRK_SBZ to disable the default behavior in that
instance.

Signed-off-by: Alastair Bridgewater 
Signed-off-by: Takashi Iwai