HD-audio driver uses regmap cache bypass feature for reading a raw
value without the cache.  But this is racy since both the cached and
the uncached reads may occur concurrently.  The former is done via the
normal control API access while the latter comes from the proc file
read.

Even though the regmap itself has the protection against the
concurrent accesses, the flag set/reset is done without the
protection, so it may lead to inconsistent state of bypass flag that
doesn't match with the current read and occasionally result in a
kernel WARNING like:
  WARNING: CPU: 3 PID: 2731 at drivers/base/regmap/regcache.c:499 regcache_cache_only+0x78/0x93

One way to work around such a problem is to wrap with a mutex.  But in
this case, the solution is simpler: for the uncached read, we just
skip the regmap and directly calls its accessor.  The verb execution
there is protected by itself, so basically it's safe to call
individually.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171Signed-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 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>

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>

This is Dell usb dock audio workaround.
It was fixed the master volume keep lower.

[Some background: the patch essentially skips the controls of a couple
 of FU volumes.  Although the firmware exposes the dB and the value
 information via the usb descriptor, changing the values (we set the
 min volume as default) screws up the device.  Although this has been
 fixed in the newer firmware, the devices are shipped with the old
 firmware, thus we need the workaround in the driver side.  -- tiwai]
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
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 'size' member of a struct firmware is passed to snd_printk with a
respective format string using the %d identifier. The 'size' member is
of type size_t, but format identifier %d indicates a signed int data
type. This patch replaces the %d format identifier with the correct %zu
format identifier for size_t data types.
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Plantronics BT300 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1". This patch adds the USB
ID of the BT300 to quirks.c and avoids those error messages.
Signed-off-by: NDennis Kadioglu <denk@post.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Phoenix Audio TMX320 gives the similar error when the sample rate is
asked:
  usb 2-1.3: 2:1: cannot get freq at ep 0x85
  usb 2-1.3: 1:1: cannot get freq at ep 0x2
  ....

Add the corresponding USB-device ID (1de7:0014) to
snd_usb_get_sample_rate_quirk() list.

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

On Skylake and onwards, the HD-audio controller driver needs to bind
with i915 for having the control of power well audio domain before
actually probing the codec.  This leads to the load of i915 driver
from the audio driver side.  But, there are systems that have no Intel
graphics but Nvidia or AMD GPU, although they still use HD-audio bus
for the onboard audio codecs.  On these, loading the i915 driver is
nothing but a useless memory and CPU consumption.

A simple way to avoid it is just to look for the Intel graphics PCI
entry beforehand, and try to bind with i915 only when such an entry is
found.  Currently, it assumes the PCI display class.  If another class
appears, this needs to be extended (although it's very unlikely).
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA system timer backend stops the timer via del_timer() without sync
and leaves del_timer_sync() at the close instead.  This is because of
the restriction by the design of ALSA timer: namely, the stop callback
may be called from the timer handler, and calling the sync shall lead
to a hangup.  However, this also triggers a kernel BUG() when the
timer is rearmed immediately after stopping without sync:
 kernel BUG at kernel/time/timer.c:966!
 Call Trace:
  <IRQ>
  [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
  [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
  [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
  [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
  [<ffffffff81296b72>] call_timer_fn+0x162/0x520
  [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
  [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
  ....

It's the place where add_timer() checks the pending timer.  It's clear
that this may happen after the immediate restart without sync in our
cases.

So, the workaround here is just to use mod_timer() instead of
add_timer().  This looks like a band-aid fix, but it's a right move,
as snd_timer_interrupt() takes care of the continuous rearm of timer.
Reported-by: NJiri Slaby <jslaby@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The front mic jack (pink color) can't detect any plug or unplug. After
applying this fix, both detecting function and recording function
work well.

BugLink: https://bugs.launchpad.net/bugs/1564712
Cc: stable@vger.kernel.org
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Unfortunately, this patch caused several regressions at au0828 and
snd-usb-audio, like this one:
	https://bugzilla.kernel.org/show_bug.cgi?id=115561

It also showed several troubles at the MC core that handles pretty
poorly the memory protections and data lifetime management.

So, better to revert it and fix the core before reapplying this
change.

This reverts commit aebb2b89 ("[media] sound/usb: Use Media
Controller API to share media resources")'
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
create_uaxx_quirk() functions allocate the audioformat object by themselves
and free it upon error before returning. However, once the object is linked
to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
double-freed, eventually resulting in a memory corruption.

This patch fixes these failures in the error paths by unlinking the audioformat
object before freeing it.

Based on a patch by Takashi Iwai <tiwai@suse.de>

[Note for stable backports:
 this patch requires the commit 902eb7fd ('ALSA: usb-audio: Minor
 code cleanup in create_fixed_stream_quirk()')]

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358Reported-by: NRalf Spenneberg <ralf@spenneberg.net>
Cc: <stable@vger.kernel.org> # see the note above
Signed-off-by: NVladis Dronov <vdronov@redhat.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit fixes garbled audio on Polaris-10/11 variants
Signed-off-by: NMaruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When sound card is going to be released, dice private data is
also released. Then all of data should be released. However,
stream data is not released. This causes memory leak when
unplugging dice unit.

This commit fixes the bug.

Fixes: 4bdc495c('ALSA: dice: handle several PCM substreams when any isochronous streams are available')
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Apply the new fixup that is used for ASUS N750JV to another similar
model, N500JV, too, for reducing the headphone noise.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: NBobi Mihalca <bobbymihalca@touchtech.ro>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For reducing the noise from the headphone output on ASUS N750JV,
call the existing fixup, alc_fixup_auto_mute_via_amp(), additionally.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: NBobi Mihalca <bobbymihalca@touchtech.ro>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ASUS N750JV needs the same fixup as N550 for enabling its subwoofer.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181Signed-off-by: NBobi Mihalca <bobbymihalca@touchtech.ro>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

'struct snd_timer_gparams' includes some members with 'unsigned long',
therefore its size differs depending on data models of architecture. As
a result, x86/x32 applications fail to execute ioctl(2) with
SNDRV_TIMER_GPARAMS command on x86_64 machine.

This commit fixes this bug by adding a pair of structure and ioctl
command for the compatibility.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

i915 get_eld ops may return an error when no encoder is connected, and
currently we regard the error as fatal and skip the whole ELD
handling.  This ended up with the missing ELD update at unplugging.

This patch fixes the issue by treating the error as the unplugged
state, instead of skipping the rest.
Reported-by: NLibin Yang <libin.yang@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The Microsoft HD-5001 webcam microphone does not support sample rate
reading as the HD-5000 one.
This results in dmesg errors and sound hanging with pulseaudio.
Signed-off-by: NVictor Clément <victor.clement@openmailbox.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent addition of on-demand i915 audio component binding in the
codec driver seems leading to the unbalanced i915 power refcount,
according to Intel CI tests.  Typically, it gets a kernel WARNING
like:
  WARNING: CPU: 3 PID: 173 at sound/hda/hdac_i915.c:91 snd_hdac_display_power+0xf1/0x110 [snd_hda_core]()
  Call Trace:
   [<ffffffff813fef15>] dump_stack+0x67/0x92
   [<ffffffff81078a21>] warn_slowpath_common+0x81/0xc0
   [<ffffffff81078b15>] warn_slowpath_null+0x15/0x20
   [<ffffffffa00f77e1>] snd_hdac_display_power+0xf1/0x110 [snd_hda_core]
   [<ffffffffa015039d>] azx_intel_link_power+0xd/0x10 [snd_hda_intel]
   [<ffffffffa011e32a>] azx_link_power+0x1a/0x30 [snd_hda_codec]
   [<ffffffffa00f21f9>] snd_hdac_link_power+0x29/0x40 [snd_hda_core]
   [<ffffffffa01192a6>] hda_codec_runtime_suspend+0x76/0xa0 [snd_hda_codec]
   .....

The scenario is like below:
- HD-audio driver and i915 driver are probed concurrently at the
  (almost) same time; HDA bus tries to bind with i915, but it fails
  because i915 initialization is still being processed.
- Later on, HD-audio probes the HDMI codec, where it again tries to
  bind with i915.  At this time, it succeeds.
- At finishing the probe of HDA, it decreases the refcount as if it
  were already bound at the bus probe, since the component is bound
  now.  This triggers a kernel WARNING due to the unbalance.

As a workaround, in this patch, we just disable the on-demand i915
component binding in the codec driver.  This essentially reverts back
to the state of 4.4 kernel.

We know that this is no real solution, but it's a minimalistic simple
change that can be applied to 4.5.x kernel as stable.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94566Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_hdac_sync_audio_rate() call is mandatory only for HSW and later
models, but we call the function unconditionally blindly assuming that
the function doesn't do anything harmful.  But since recently, the
function checks the validity of the passed pin NID, and eventually
spews the warning if an unexpected pin is passed.  This is seen on old
chips like Baytrail.

The fix is to limit the call of this function again only for the chips
with the proper binding.  This can be identified by the same flag as
the eld notifier.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We forgot to copy monitor_present value when updating the ELD
information.  This won't change the ELD retrieval and the jack
notification behavior, but appears only in the proc output.   In that
sense, it's no fatal error, but a bug is a bug is a bug.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit [b62232d4: ALSA: hda - Limit i915 HDMI binding only for
HSW and later] tried to limit the usage of i915 audio notifier to the
recent Intel models and switch to the old method on pre-Haswell
models.  However, it assumed that the i915 component binding hasn't
been done on such models, and the assumption was wrong: namely,
Baytrail had already the i915 component binding due to powerwell
control.  Thus, the workaround wasn't applied to Baytrail.

For fixing this properly, this patch introduces a new flag indicating
the usage of audio notifier and codec_has_acomp() refers to this flag
instead of checking the existence of audio component.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The dummy component is reused for all cards so we special case and don't
bind it to any of them.  This means that code like that displaying the
component widgets that tries to look at the card will crash.  In the
future we will fix this by ensuring that the dummy component looks like
other components but that is invasive and so not suitable for a fix.
Instead add a special case check here.
Reported-by: NHarry Pan <harry.pan@intel.com>
Suggested-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

We can disable debug_pagealloc processing even if the code is compiled
with CONFIG_DEBUG_PAGEALLOC.  This patch changes the code to query
whether it is enabled or not in runtime.

[akpm@linux-foundation.org: export _debug_pagealloc_enabled to modules]
Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The recent change in HD-audio HDMI/DP codec driver for allowing the
dynamic PCM binding introduced a new spec->pcm_mutex.  One of the
protected area by this mutex is hdmi_present_sense().  As reported by
Intel CI tests, unfortunately, the new mutex causes a deadlock when
the hotplug/unplug is triggered during the codec is in runtime
suspend.  The buggy code path is like the following:

  hdmi_unsol_event() -> ...
    -> hdmi_present_sense()
==>     ** here taking pcm_mutex
      -> hdmi_present_sense_via_verbs()
        -> snd_hda_power_up_pm() -> ... (runtime resume calls)
          -> generic_hdmi_resume()
            -> hdmi_present_sense()
==>           ** here taking pcm_mutex again!

As we can see here, the problem is that the mutex is taken before
snd_hda_power_up_pm() call that triggers the runtime resume.  That is,
the obvious solution is to move the power up/down call outside the
mutex; it is exactly what this patch provides.

The patch also clarifies why this bug wasn't caught beforehand.  We
used to have the i915 audio component for hotplug for all Intel chips,
and in that code path, there is no power up required but the
information is taken directly from the graphics side.  However, we
recently switched back to the old method for some old Intel chips due
to regressions, and now the deadlock issue is surfaced.

Fixes: a76056f2 ('ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug')
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA: ctl: change return value in compatibility layer so that it's the same value in core implementation

In control compatibility layer, when no elements are found by
ELEM_READ/ELEM_WRITE ioctl commands, ENXIO is returned. On the other hand,
in core implementation, ENOENT is returned. This is not good for
ALSA ctl applications.

This commit changes the return value from the compatibility layer so
that the same value is returned.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We could print the uninitialized value of "stat" in the error message.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add some sanity check codes before actually accessing the endpoint via
get_endpoint() in order to avoid the invalid access through a
malformed USB descriptor.  Mostly just checking bNumEndpoints, but in
one place (snd_microii_spdif_default_get()), the validity of iface and
altsetting index is checked as well.

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

Just a minor code cleanup: unify the error paths.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

create_fixed_stream_quirk() may cause a NULL-pointer dereference by
accessing the non-existing endpoint when a USB device with a malformed
USB descriptor is used.

This patch avoids it simply by adding a sanity check of bNumEndpoints
before the accesses.

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

It turned out that the pre-HSW Intel chips are incompatible with the
naive assumption we had -- the fixed mapping between the port and the
HD-audio widget.  This may result in the bad access, as captured by
the recent patch to add a WARN_ON() for the port mapping check.

As a quick workaround, disable the i915 audio component binding for
all pre-Haswell models.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.5
Signed-off-by: NTakashi Iwai <tiwai@suse.de>