This solves the issue that a headphone is not working on the docking
unit.
Signed-off-by: NTorsten Hilbrich <torsten.hilbrich@secunet.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

vortex_wtdma_bufshift() function does calculate the page index
wrongly, first masking then shift, which always results in zero.
The proper computation is to first shift, then mask.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Kabylake-H shows up as PCI ID 0xa2f0. We missed adding this
earlier with other KBL IDs.
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

'commpage_bak' is allocated with 'sizeof(struct echoaudio)' bytes.
We then copy 'sizeof(struct comm_page)' bytes in it.
On my system, smatch complains because one is 2960 and the other is 3072.

This would result in memory corruption or a oops.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

UBSAN reports the following warning from accessing path->path[-1]
in set_path_power():

[   16.078040] ================================================================================
[   16.078124] UBSAN: Undefined behaviour in sound/pci/hda/hda_generic.c:3981:17
[   16.078198] index -1 is out of range for type 'hda_nid_t [10]'
[   16.078270] CPU: 2 PID: 1738 Comm: modprobe Not tainted 4.7.0-rc1-wt+ #47
[   16.078274] Hardware name: LENOVO 3443CTO/3443CTO, BIOS G6ET23WW (1.02 ) 08/14/2012
[   16.078278]  ffff8800cb246000 ffff8800cb3638b8 ffffffff815c4fe3 0000000000000032
[   16.078286]  ffff8800cb3638e0 ffffffffffffffff ffff8800cb3638d0 ffffffff8162443d
[   16.078294]  ffffffffa0894200 ffff8800cb363920 ffffffff81624af7 0000000000000292
[   16.078302] Call Trace:
[   16.078311]  [<ffffffff815c4fe3>] dump_stack+0x86/0xd3
[   16.078317]  [<ffffffff8162443d>] ubsan_epilogue+0xd/0x40
[   16.078324]  [<ffffffff81624af7>] __ubsan_handle_out_of_bounds+0x67/0x70
[   16.078335]  [<ffffffffa087665f>] set_path_power+0x1bf/0x230 [snd_hda_codec_generic]
[   16.078344]  [<ffffffffa087880d>] add_pin_power_ctls+0x8d/0xc0 [snd_hda_codec_generic]
[   16.078352]  [<ffffffffa087f190>] ? pin_power_down_callback+0x20/0x20 [snd_hda_codec_generic]
[   16.078360]  [<ffffffffa0878947>] add_all_pin_power_ctls+0x107/0x150 [snd_hda_codec_generic]
[   16.078370]  [<ffffffffa08842b3>] snd_hda_gen_parse_auto_config+0x2d73/0x49e0 [snd_hda_codec_generic]
[   16.078376]  [<ffffffff81173360>] ? trace_hardirqs_on_caller+0x1b0/0x2c0
[   16.078390]  [<ffffffffa089df27>] alc_parse_auto_config+0x147/0x310 [snd_hda_codec_realtek]
[   16.078402]  [<ffffffffa08a332a>] patch_alc269+0x23a/0x560 [snd_hda_codec_realtek]
[   16.078417]  [<ffffffffa0838644>] hda_codec_driver_probe+0xa4/0x1a0 [snd_hda_codec]
[   16.078424]  [<ffffffff817bbac1>] driver_probe_device+0x101/0x380
[   16.078430]  [<ffffffff817bbdf9>] __driver_attach+0xb9/0x100
[   16.078438]  [<ffffffff817bbd40>] ? driver_probe_device+0x380/0x380
[   16.078444]  [<ffffffff817b8d20>] bus_for_each_dev+0x70/0xc0
[   16.078449]  [<ffffffff817bb087>] driver_attach+0x27/0x50
[   16.078454]  [<ffffffff817ba956>] bus_add_driver+0x166/0x2c0
[   16.078460]  [<ffffffffa0369000>] ? 0xffffffffa0369000
[   16.078465]  [<ffffffff817bd13d>] driver_register+0x7d/0x130
[   16.078477]  [<ffffffffa083816f>] __hda_codec_driver_register+0x6f/0x90 [snd_hda_codec]
[   16.078488]  [<ffffffffa036901e>] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek]
[   16.078493]  [<ffffffff8100215e>] do_one_initcall+0x4e/0x1d0
[   16.078499]  [<ffffffff8119f54d>] ? rcu_read_lock_sched_held+0x6d/0x80
[   16.078504]  [<ffffffff813701b1>] ? kmem_cache_alloc_trace+0x391/0x560
[   16.078510]  [<ffffffff812bb314>] ? do_init_module+0x28/0x273
[   16.078515]  [<ffffffff812bb387>] do_init_module+0x9b/0x273
[   16.078522]  [<ffffffff811e3782>] load_module+0x20b2/0x3410
[   16.078527]  [<ffffffff811df140>] ? m_show+0x210/0x210
[   16.078533]  [<ffffffff813b2b26>] ? kernel_read+0x66/0xe0
[   16.078541]  [<ffffffff811e4cfa>] SYSC_finit_module+0xba/0xc0
[   16.078547]  [<ffffffff811e4d1e>] SyS_finit_module+0xe/0x10
[   16.078552]  [<ffffffff81a860fc>] entry_SYSCALL_64_fastpath+0x1f/0xbd
[   16.078556] ================================================================================

Fix by checking path->depth before use.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

  See: https://bugzilla.redhat.com/show_bug.cgi?id=1349539
  See: https://bugzilla.kernel.org/show_bug.cgi?id=120961Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The new Dell laptop with codec 3246 can't detect headset mic when
headset was inserted on the machine. So adding pin configurations
into quirk table makes headset mic work correctly.

Codec: Realtek ALC3246
Vendor Id: 0x10ec0256
Subsystem Id: 0x10280781
Signed-off-by: NWoodrow Shen <woodrow.shen@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The readl/writel are not being passed __iomem annotated
variables, so fix the following sparse warnings by adding
__iomem in:

sound/pci/hda/hda_tegra.c:120:9: warning: incorrect type in argument 2 (different address spaces)
sound/pci/hda/hda_tegra.c:120:9:    expected void volatile [noderef] <asn:2>*addr
sound/pci/hda/hda_tegra.c:120:9:    got unsigned int [usertype] *addr
sound/pci/hda/hda_tegra.c:125:16: warning: incorrect type in argument 1 (different address spaces)
sound/pci/hda/hda_tegra.c:125:16:    expected void const volatile [noderef] <asn:2>*addr
sound/pci/hda/hda_tegra.c:125:16:    got unsigned int [usertype] *addr
sound/pci/hda/hda_tegra.c:134:13: warning: incorrect type in argument 1 (different address spaces)
sound/pci/hda/hda_tegra.c:134:13:    expected void const volatile [noderef] <asn:2>*addr
sound/pci/hda/hda_tegra.c:134:13:    got void *dword_addr
sound/pci/hda/hda_tegra.c:137:9: warning: incorrect type in argument 2 (different address spaces)
sound/pci/hda/hda_tegra.c:137:9:    expected void volatile [noderef] <asn:2>*addr
sound/pci/hda/hda_tegra.c:137:9:    got void *dword_addr
sound/pci/hda/hda_tegra.c:146:13: warning: incorrect type in argument 1 (different address spaces)
sound/pci/hda/hda_tegra.c:146:13:    expected void const volatile [noderef] <asn:2>*addr
sound/pci/hda/hda_tegra.c:146:13:    got void *dword_addr
sound/pci/hda/hda_tegra.c:156:13: warning: incorrect type in argument 1 (different address spaces)
sound/pci/hda/hda_tegra.c:156:13:    expected void const volatile [noderef] <asn:2>*addr
sound/pci/hda/hda_tegra.c:156:13:    got void *dword_addr
sound/pci/hda/hda_tegra.c:159:9: warning: incorrect type in argument 2 (different address spaces)
sound/pci/hda/hda_tegra.c:159:9:    expected void volatile [noderef] <asn:2>*addr
sound/pci/hda/hda_tegra.c:159:9:    got void *dword_addr
sound/pci/hda/hda_tegra.c:168:13: warning: incorrect type in argument 1 (different address spaces)
sound/pci/hda/hda_tegra.c:168:13:    expected void const volatile [noderef] <asn:2>*addr
sound/pci/hda/hda_tegra.c:168:13:    got void *dword_addr
sound/pci/hda/hda_tegra.c:173:23: warning: incorrect type in initializer (incompatible argument 2 (different address spaces))
sound/pci/hda/hda_tegra.c:173:23:    expected void ( *reg_writel )( ... )
sound/pci/hda/hda_tegra.c:173:23:    got void ( static [toplevel] *<noident> )( ... )
sound/pci/hda/hda_tegra.c:174:22: warning: incorrect type in initializer (incompatible argument 1 (different address spaces))
sound/pci/hda/hda_tegra.c:174:22:    expected unsigned int ( *reg_readl )( ... )
sound/pci/hda/hda_tegra.c:174:22:    got unsigned int ( static [toplevel] *<noident> )( ... )
sound/pci/hda/hda_tegra.c:175:23: warning: incorrect type in initializer (incompatible argument 2 (different address spaces))
sound/pci/hda/hda_tegra.c:175:23:    expected void ( *reg_writew )( ... )
sound/pci/hda/hda_tegra.c:175:23:    got void ( static [toplevel] *<noident> )( ... )
sound/pci/hda/hda_tegra.c:176:22: warning: incorrect type in initializer (incompatible argument 1 (different address spaces))
sound/pci/hda/hda_tegra.c:176:22:    expected unsigned short ( *reg_readw )( ... )
sound/pci/hda/hda_tegra.c:176:22:    got unsigned short ( static [toplevel] *<noident> )( ... )
sound/pci/hda/hda_tegra.c:177:23: warning: incorrect type in initializer (incompatible argument 2 (different address spaces))
sound/pci/hda/hda_tegra.c:177:23:    expected void ( *reg_writeb )( ... )
sound/pci/hda/hda_tegra.c:177:23:    got void ( static [toplevel] *<noident> )( ... )
sound/pci/hda/hda_tegra.c:178:22: warning: incorrect type in initializer (incompatible argument 1 (different address spaces))
sound/pci/hda/hda_tegra.c:178:22:    expected unsigned char ( *reg_readb )( ... )
sound/pci/hda/hda_tegra.c:178:22:    got unsigned char ( static [toplevel] *<noident> )( ... )
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Kabylake shows up as PCI ID 0xa171. And Kabylake-LP as 0x9d71.
Since these are similar to Skylake add these to SKL_PLUS macro
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Tested with Lenovo Ultradock. Fixes the non-working headphone jack on
the docking unit.
Signed-off-by: NTorsten Hilbrich <torsten.hilbrich@secunet.com>
Tested-by: NTorsten Hilbrich <torsten.hilbrich@secunet.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add the pin configuration value of this machine into the pin_quirk
table to make DELL1_MIC_NO_PRESENCE apply to this machine.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Support new codecs for ALC700/ALC701/ALC703.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

That is some different register for ALC255 and ALC256.
ALC256 can't fit with some ALC255 register.
This issue is cause from LDO output voltage control.
This patch is updated the right LDO register value.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add the pin configuration value of this machine into the pin_quirk
table to make DELL1_MIC_NO_PRESENCE apply to this machine.

Cc: <stable@vger.kernel.org>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add support for ALC295/ALC3254.
They are simply compatible with ALC225 chip.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The headphone has noise when playing sound or switching microphone sources.
It uses the same codec on XPS 13 9350, but with different subsystem ID.
Applying the fixup can solve the issue.
Also, changing the model name to better differentiate models.

v2: Reorder by device ID.
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There are a few calls of memset() to stream->resources, but they all
are called in a wrong size, sizeof(unsigned char) * VORTEX_RESOURCE_LAST,
while this field is a u32 array.  This may leave the memories not
zero-cleared.

Fix it by replacing them with a simpler sizeof(stream->resources)
instead.
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The HDMI/DP audio output on ATI/AMD chips got broken due to the recent
restructuring of chmap.  Fortunately, Daniel Exner could bisect, and
pointed the culprit commit [739ffee9: ALSA: hda - Add hdmi chmap
verb programming ops to chmap object].

This commit moved some ops from hdmi_ops to chmap_ops, and reassigned
the ops in the embedded chmap object in hdmi_spec instead.
Unfortunately, the reassignment of these ops in patch_atihdmi() were
moved into an if block that is performed only for old chips.  Thus, on
newer chips, the generic ops is still used, which doesn't work for
such ATI/AMD chips.

This patch addresses the regression, simply by moving the assignment
of chmap ops to the right place.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114981
Fixes: 739ffee9 ('ALSA: hda - Add hdmi chmap verb programming ops to chmap object')
Reported-and-tested-by: NDaniel Exner <dex@dragonslave.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Subwoofer does not work out of the box on ASUS N751/N551 laptops. This
patch fixes it. Patch tested on N751 laptop. N551 part is not tested,
but according to [1] and [2] this laptop requires similar changes, so I
included them in the patch.

1. https://github.com/honsiorovskyi/asus-n551-hda-fix
2. https://bugs.launchpad.net/ubuntu/+source/alsa-tools/+bug/1405691

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117781Signed-off-by: NYura Pakhuchiy <pakhuchiy@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The HD-audio reconfig function got broken in the recent kernels,
typically resulting in a failure like:
  snd_hda_intel 0000:00:1b.0: control 3:0:0:Playback Channel Map:0 is already present

This is because of the code restructuring to move the PCM and control
instantiation into the codec drive probe, by the commit [bcd96557:
ALSA: hda - Build PCMs and controls at codec driver probe].  Although
the commit above removed the calls of snd_hda_codec_build_pcms() and
*_build_controls() at the controller driver probe, the similar calls
in the reconfig were still left forgotten.  This caused the
conflicting and duplicated PCMs and controls.

The fix is trivial: just remove these superfluous calls from
reconfig_codec().

Fixes: bcd96557 ('ALSA: hda - Build PCMs and controls at codec driver probe')
Reported-by: NJochen Henneberg <jh@henneberg-systemdesign.com>
Cc: <stable@vger.kernel.org> # v4.1+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Since the recent rewrite of HD-audio infrastructure,
CONFIG_SND_HDA_RECONFIG has a slightly different meaning.  In the
earlier versions, it implicitly assumed only the usage via hwdep sysfs
entries.  Meanwhile, in the recent version, this option is meant to
enable the reconfig code in HD-audio driver, which may be used by the
patch loader without hwdep interface.

This patch tries to clarify the usage pattern a bit better, hopefully
avoid the further confusion.
Reported-by: NJochen Henneberg <jh@henneberg-systemdesign.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For reducing the noise from the headset output on ASUS UX501VW,
call the existing fixup, alc_fixup_headset_mode_alc668(), additionally.

Thread: https://bbs.archlinux.org/viewtopic.php?id=209554Signed-off-by: NKaho Ng <ngkaho1234@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Support new codecs for ALC234/ALC274/ALC294.
This three codecs was the same IC.
But bonding is not the same.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent bug report suggests that BCLK setup for i915 HSW/BDW needs
to be updated at each HDMI hotplug, not only at initialization and
resume.  That is, we need to update HSW_EM4 and HSW_EM5 registers at
ELD notification, too.  Otherwise the HDMI audio may be out of sync
and played in a wrong pitch.

However, the HDA codec driver has no access to the controller
registers, and currently the code managing these registers is in
hda_intel.c, i.e. local to the controller driver.  For allowing the
explicit BCLK update from the codec driver, as in this patch, the
former haswell_set_bclk() in hda_intel.c is moved to hdac_i915.c and
exposed as snd_hdac_i915_set_bclk().  This is called from both the HDA
controller driver and intel_pin_eld_notify() in HDMI codec driver.

Along with this change, snd_hdac_get_display_clk() gets dropped as
it's no longer used.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91410
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013
docking station series (basic, pro, ultra).
Signed-off-by: NConrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

au88x0 hardware seems returning the current pointer at the buffer
boundary instead of going back to zero.  This results in spewing
warnings from PCM core.

This patch corrects the return value from the pointer callback within
the proper value range, just returning zero if the position is equal
or above the buffer size.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit [9bef72bd: ALSA: pcxhr: Use nonatomic PCM ops]
converted to non-atomic PCM ops, but shamelessly with an unbalanced
mutex locking, which leads to the hangup easily.  Fix it.

Fixes: 9bef72bd ('ALSA: pcxhr: Use nonatomic PCM ops')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116441
Cc: <stable@vger.kernel.org> # 3.18+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add HD Audio Device PCI ID for the Intel Broxton-T platform.
It is an HDA Intel PCH controller.
Signed-off-by: NLu, Han <han.lu@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Although one weird behavior about the input path (inconsistent D0/D3
switch) on Cirrus CS420x codecs was fixed in the previous commit,
there is still an issue on some Mac machines: the capture stream
stalls when switching the ADCs on the fly.  More badly, this keeps
stuck until the next reboot.

The dynamic ADC switching is already a bit fragile and assuming
optimistically that the chip accepts the frequent power changes.  On
Cirrus codecs, this doesn't seem applicable.

As a quick workaround, we pin down the ADCs to keep up in D0 when
spec->dyn_adc_switch is set.  In this way, the ADCs are kept up only
for the system that were confirmed to be broken.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The "Line In->Rear Out Switch" control on ens1371 driver returns a
bogus value, always true, as its check is totally broken.  Fix it to
check the proper GPIO bit mask.
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The Optiplex 9020m with Haswell-DT processor needs a quirk for the
headset jack at the front of the machine to be able to use microphones.

A quirk for this model was originally added in 31278997, but c77900e6
removed it in favour of a more generic version.

Unfortunately, pin configurations can changed based on firmware/BIOS
versions, and the generic version doesn't have any effect on newer
versions of the machine/firmware anymore.

With help from David Henningsson <diwic@ubuntu.com>
Signed-off-by: NBastien Nocera <hadess@hadess.net>
Tested-by: NBastien Nocera <hadess@hadess.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Make sure per_pin is not NULL before using it.

Fixes: 9b3dc8aa ('ALSA: hda - Register chmap obj as priv data instead of codec')
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We've got a regression report that the recording on Mac with a cirrus
codec doesn't work any longer.  This turned out to be the missing
power up to D0 by power_save_node enablement.

After analyzing the traces, we found out that the culprit is that the
codec advertises the "actual" power state of a few nodes to be D0
while the "target" power state is D3.  This inconsistency is usually
OK, as it implies the power transition.  But in the case of cirrus
codec, this seems to be stuck to D3 while it's not actually D0.

This patch addresses the issue by checking the power state difference
more strictly.  It sends the power-state change verb unless both the
target and the actual power states show the given value.

We may introduce yet another flag indicating the possible broken
hardware power state, but it's anyway safer to set the proper power
state even in a transition (at least it's harmless as long as the
target state is same).  So this simpler change was applied now.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

lx_pipe_state() checks the return value from lx_message_send_atomic()
and breaks the loop only when it's a negative value.  However,
lx_message_send_atomic() may return a positive error code (as the
return code from the hardware), and then lx_pipe_state() tries to
compare the uninitialized current_state variable.

Fix this behavior by checking the positive non-zero error code as
well.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

While the previous commit fixed the missing monitor_present flag
update, it may be still in an inconsistent state while the driver
repolls: the flag itself is updated, but the eld_valid flag and the
contents don't follow until the repoll finishes (and may be repeated
for a few times).

The basic problem is that pin_eld->monitor_present is updated in the
caller side.  This should have been updated only in update_eld().  So,
the proper fix is to avoid accessing pin_eld but only spec->temp_eld.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit [bd481285: ALSA: hda - Fix forgotten HDMI
monitor_present update] covered the missing update of monitor_present
flag, but this caused a regression for devices without the i915 eld
notifier.  Since the old code supposed that pin_eld->monitor_present
was updated by the caller side, the hdmi_present_sense_via_verbs()
doesn't update the temporary eld->monitor_present but only
pin_eld->monitor_present, which is now overridden in update_eld().

The fix is to update pin_eld->monitor_present as well before calling
update_eld().

Note that this may still leave monitor_present flag in an inconsistent
state when the driver repolls, but this is at least the old behavior.
More proper fix will follow in the later patch.

Fixes: bd481285 ('ALSA: hda - Fix forgotten HDMI monitor_present update')
Signed-off-by: NHyungwon Hwang <hyungwon.hwang7@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The calls for capture_hook were missing in dyn_adc_capture_pcm_prepare
and cleanup callbacks.  Luckily there are no users of the capture
hooks with dyn-adc PCM, so far, thus this doesn't change the behavior
of existing devices, but it's a fix for a future usage.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The Lenovo Thinkpad T460s requires the alc_fixup_tpt440_dock as well in
order to get working sound output on the docking stations headphone jack.

Patch tested on a Thinkpad T460s (20F9CT01WW) using a ThinkPad Ultradock
on kernel 4.4.6.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The ct_timer_ops structures are never modified, so declare them as const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

acpi_dev_present() was originally named after pci_dev_present()
to signify the similarity of the two functions.

However Rafael J. Wysocki pointed out that the exported function
acpi_dev_present() is easily confused with the non-exported
acpi_device_is_present(). Additionally in ACPI parlance the term
"present" usually refers to the "device is present" bit returned
by the _STA control method, yet acpi_dev_present() merely checks
presence in the namespace. It does not invoke _STA at all, let
alone check the "device is present" bit.

As suggested by Rafael, rename the function to acpi_dev_found()
and adjust all existing call sites.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>