<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/sound/pci, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.1.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2018-05-23T01:36:38Z</updated>
<entry>
<title>ALSA: hda: Hardening for potential Spectre v1</title>
<updated>2018-05-23T01:36:38Z</updated>
<author>
<name>Takashi Iwai</name>
</author>
<published>2018-04-24T05:50:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0f80b5548fa38ca8b39c87b6d63d848d6628690a'/>
<id>urn:sha1:0f80b5548fa38ca8b39c87b6d63d848d6628690a</id>
<content type='text'>
[ Upstream commit 69fa6f19b95597618ab30438a27b67ad93daa7c7 ]

As recently Smatch suggested, one place in HD-audio hwdep ioctl codes
may expand the array directly from the user-space value with
speculation:
  sound/pci/hda/hda_local.h:467 get_wcaps() warn: potential spectre issue 'codec-&gt;wcaps'

As get_wcaps() itself is a fairly frequently called inline function,
and there is only one single call with a user-space value, we replace
only the latter one to open-code locally with array_index_nospec()
hardening in this patch.

BugLink: https://marc.info/?l=linux-kernel&amp;m=152411496503418&amp;w=2
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: rme9652: Hardening for potential Spectre v1</title>
<updated>2018-05-23T01:36:38Z</updated>
<author>
<name>Takashi Iwai</name>
</author>
<published>2018-04-24T06:04:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cb16ce2d14abb5278c7058488b47c63f92fa59c2'/>
<id>urn:sha1:cb16ce2d14abb5278c7058488b47c63f92fa59c2</id>
<content type='text'>
[ Upstream commit f526afcd8f71945c23ce581d7864ace93de8a4f7 ]

As recently Smatch suggested, one place in RME9652 driver may expand
the array directly from the user-space value with speculation:
  sound/pci/rme9652/rme9652.c:2074 snd_rme9652_channel_info() warn: potential spectre issue 'rme9652-&gt;channel_map' (local cap)

This patch puts array_index_nospec() for hardening against it.

BugLink: https://marc.info/?l=linux-kernel&amp;m=152411496503418&amp;w=2
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: hdspm: Hardening for potential Spectre v1</title>
<updated>2018-05-23T01:36:38Z</updated>
<author>
<name>Takashi Iwai</name>
</author>
<published>2018-04-24T06:03:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9024c599ac2afeb7b1c3032bcb745cac92107859'/>
<id>urn:sha1:9024c599ac2afeb7b1c3032bcb745cac92107859</id>
<content type='text'>
[ Upstream commit 10513142a7114d251670361ad40cba2c61403406 ]

As recently Smatch suggested, a couple of places in HDSP MADI driver
may expand the array directly from the user-space value with
speculation:
  sound/pci/rme9652/hdspm.c:5717 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm-&gt;channel_map_out' (local cap)
  sound/pci/rme9652/hdspm.c:5734 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm-&gt;channel_map_in' (local cap)

This patch puts array_index_nospec() for hardening against them.

BugLink: https://marc.info/?l=linux-kernel&amp;m=152411496503418&amp;w=2
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: hda - New VIA controller suppor no-snoop path</title>
<updated>2018-05-23T01:36:35Z</updated>
<author>
<name>David Wang</name>
</author>
<published>2018-04-16T09:48:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9d2fbe826b3efac986d6f28084d3e84dd702f542'/>
<id>urn:sha1:9d2fbe826b3efac986d6f28084d3e84dd702f542</id>
<content type='text'>
[ Upstream commit af52f9982e410edac21ca4b49563053ffc9da1eb ]

This patch is used to tell kernel that new VIA HDAC controller also
support no-snoop path.

[ minor coding style fix by tiwai ]

Signed-off-by: David Wang &lt;davidwang@zhaoxin.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: hda/realtek - Always immediately update mute LED with pin VREF</title>
<updated>2018-05-23T01:33:52Z</updated>
<author>
<name>Takashi Iwai</name>
</author>
<published>2018-03-17T21:40:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2ab4dc39a704e0a480e7ca8057a37266b2b5be91'/>
<id>urn:sha1:2ab4dc39a704e0a480e7ca8057a37266b2b5be91</id>
<content type='text'>
[ Upstream commit e40bdb03d3cd7da66bd0bc1e40cbcfb49351265c ]

Some HP laptops have a mute mute LED controlled by a pin VREF.  The
Realtek codec driver updates the VREF via vmaster hook by calling
snd_hda_set_pin_ctl_cache().

This works fine as long as the driver is running in a normal mode.
However, when the VREF change happens during the codec being in
runtime PM suspend, the regmap access will skip and postpone the
actual register change.  This ends up with the unchanged LED status
until the next runtime PM resume even if you change the Master mute
switch.  (Interestingly, the machine keeps the LED status even after
the codec goes into D3 -- but it's another story.)

For improving this usability, let the driver temporarily powering up /
down only during the pin VREF change.  This can be achieved easily by
wrapping the call with snd_hda_power_up_pm() / *_down_pm().

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: hda - Fix headset microphone detection for ASUS N551 and N751</title>
<updated>2018-05-23T01:33:49Z</updated>
<author>
<name>Mikhail Paulyshka</name>
</author>
<published>2017-04-21T06:52:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5e1847c45151412c27e57c9bcf5d5d974056cb8a'/>
<id>urn:sha1:5e1847c45151412c27e57c9bcf5d5d974056cb8a</id>
<content type='text'>
[ Upstream commit fc7438b1eb12b6c93d7b7a62423779eb5dfc673c ]

Headset microphone does not work out of the box on ASUS Nx51
laptops. This patch fixes it.

Patch tested on Asus N551 laptop. Asus N751 part is not tested, but
according to [1] this laptop uses the same audiosystem.

1. https://bugzilla.kernel.org/show_bug.cgi?id=117781

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195437
Signed-off-by: Mikhail Paulyshka &lt;me@mixaill.tk&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: hda/realtek - Fix dock line-out volume on Dell Precision 7520</title>
<updated>2018-03-21T03:49:50Z</updated>
<author>
<name>Takashi Iwai</name>
</author>
<published>2018-03-06T11:14:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=408a75c61488c890b036edee412665aefad21367'/>
<id>urn:sha1:408a75c61488c890b036edee412665aefad21367</id>
<content type='text'>
[ Upstream commit e312a869cd726c698a75caca0d9e5c22fd3f1534 ]

The dock line-out pin (NID 0x17 of ALC3254 codec) on Dell Precision
7520 may route to three different DACs, 0x02, 0x03 and 0x06.  The
first two DACS have the volume amp controls while the last one
doesn't.  And unfortunately, the auto-parser assigns this pin to DAC3,
resulting in the non-working volume control for the line out.

Fix it by disabling the routing to DAC3 on the corresponding pin.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199029
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: hda/ca0132 - fix possible NULL pointer use</title>
<updated>2018-03-04T15:28:29Z</updated>
<author>
<name>Arnd Bergmann</name>
</author>
<published>2017-01-11T13:39:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4974179d68b6d8ce0cb44f87de3506d2d102d724'/>
<id>urn:sha1:4974179d68b6d8ce0cb44f87de3506d2d102d724</id>
<content type='text'>
[ Upstream commit 46a049dae771b95e77ac6c823330f4a60f600236 ]

gcc-7 caught what it considers a NULL pointer dereference:

sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop':
sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null expected [-Werror=nonnull]

This is plausible from looking at the function, as we compare 'reply'
to NULL earlier in it. I have not tried to analyze if there are constraints
that make it impossible to hit the bug, but adding another NULL check in
the end kills the warning and makes the function more robust.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: hda/realtek: PCI quirk for Fujitsu U7x7</title>
<updated>2018-03-04T15:28:23Z</updated>
<author>
<name>Jan-Marek Glogowski</name>
</author>
<published>2018-02-14T10:29:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a2828af8bbb6b2ccb37003cc76e880943bf87bd1'/>
<id>urn:sha1:a2828af8bbb6b2ccb37003cc76e880943bf87bd1</id>
<content type='text'>
[ Upstream commit fdcc968a3b290407bcba9d4c90e2fba6d8d928f1 ]

These laptops have a combined jack to attach headsets, the U727 on
the left, the U757 on the right, but a headsets microphone doesn't
work. Using hdajacksensetest I found that pin 0x19 changed the
present state when plugging the headset, in addition to 0x21, but
didn't have the correct configuration (shown as "Not connected").

So this sets the configuration to the same values as the headphone
pin 0x21 except for the device type microphone, which makes it
work correctly. With the patch the configured pins for U727 are

Pin 0x12 (Internal Mic, Mobile-In): present = No
Pin 0x14 (Internal Speaker): present = No
Pin 0x19 (Black Mic, Left side): present = No
Pin 0x1d (Internal Aux): present = No
Pin 0x21 (Black Headphone, Left side): present = No

Signed-off-by: Jan-Marek Glogowski &lt;glogow@fbihome.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>ALSA: hda - Apply the existing quirk to iMac 14,1</title>
<updated>2018-03-01T03:09:38Z</updated>
<author>
<name>Takashi Iwai</name>
</author>
<published>2018-01-10T09:53:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b04b590eab4a13cbfa0b5e43bc91c496ce997ef9'/>
<id>urn:sha1:b04b590eab4a13cbfa0b5e43bc91c496ce997ef9</id>
<content type='text'>
[ Upstream commit 031f335cda879450095873003abb03ae8ed3b74a ]

iMac 14,1 requires the same quirk as iMac 12,2, using GPIO 2 and 3 for
headphone and speaker output amps.  Add the codec SSID quirk entry
(106b:0600) accordingly.

BugLink: http://lkml.kernel.org/r/CAEw6Zyteav09VGHRfD5QwsfuWv5a43r0tFBNbfcHXoNrxVz7ew@mail.gmail.com
Reported-by: Freaky &lt;freaky2000@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
</feed>
