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 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>

Cirrus HD-audio driver may adjust GPIO pins for EAPD dynamically
depending on the jack plug state.  This works fine for the auto-mute
mode where the speaker gets muted upon the HP jack plug.   OTOH, when
the auto-mute mode is off, this turns off the EAPD unexpectedly
depending on the jack state, which results in the silent speaker
output.

This patch fixes the silent speaker output issue by setting GPIO bits
constantly when the auto-mute mode is off.

Reported-and-tested-by: moosotc@gmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We print can print the uninitialized memory on error.  Which is an info
leak, I suppose but it's basically harmless.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ASoC: Updates for v4.6

The main thing in terms of the core this time around has been some
additional framework work for dynamic topologies (though we *still*
don't appear to have a stable ABI for the topology code, it's probably
worth considering if this will ever happen...).  Otherwise the work has
almost all been in the drivers:

 - HDMI support for Sky Lake, along with other fixes and enhancements
   for the Intel drivers.
 - Lots of improvements to the Renesas drivers.
 - Capture support for Qualcomm drivers.
 - Support for TI DaVinci DRA7xxx devices.
 - New machine drivers for Freescale systems with Cirrus CODECs,
   Mediatek systems with RT5650 CODECs.
 - New CPU drivers for Allwinner S/PDIF controllers
 - New CODEC drivers for Maxim MAX9867 and MAX98926 and Realtek RT5514.

nvhdmi_chmap_cea_alloc_validate_get_type calls itself recursively
using chmap ops causing the double fault.

Fixed by adding the default validate_get_type handling inside nvdia
validate_get_type handler.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=114311
Fixes: 67b90cb8 ("ALSA: hda - Create common chmap object")
Reported-by: NAndreas Reis <andreas.reis@gmail.com>
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Tested-by: NAndreas Reis <andreas.reis@gmail.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41
will often fail, so add a quirk entry to fix it.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087
Cc: <stable@vger.kernel.org>
Signed-off-by: NVittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Vendor ID 0x10de0082 is used by a yet-to-be-named GPU chip.

This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: NAaron Plattner <aplattner@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Merge remote-tracking branches 'asoc/topic/sunxi', 'asoc/topic/topology' and 'asoc/topic/wm8974' into asoc-next

Merge remote-tracking branches 'asoc/topic/rt5640', 'asoc/topic/rt5659', 'asoc/topic/samsung' and 'asoc/topic/ssm4567' into asoc-next

Merge remote-tracking branches 'asoc/topic/rcar', 'asoc/topic/rockchip', 'asoc/topic/rt298', 'asoc/topic/rt5514' and 'asoc/topic/rt5616' into asoc-next

Merge remote-tracking branches 'asoc/topic/max98926', 'asoc/topic/mtk', 'asoc/topic/mxs-saif', 'asoc/topic/nau8825' and 'asoc/topic/omap' into asoc-next

Merge remote-tracking branches 'asoc/topic/fsl-sai', 'asoc/topic/fsl-ssl', 'asoc/topic/hdac' and 'asoc/topic/max9867' into asoc-next

Merge remote-tracking branches 'asoc/topic/davinci', 'asoc/topic/fsl-card' and 'asoc/topic/fsl-mpc5200' into asoc-next

Merge remote-tracking branches 'asoc/topic/atmel', 'asoc/topic/bcm2835' and 'asoc/topic/cs42xx8' into asoc-next

Merge remote-tracking branches 'asoc/topic/ab8500', 'asoc/topic/adau17x1', 'asoc/topic/ads117x', 'asoc/topic/adsp' and 'asoc/topic/arizona' into asoc-next

ASoC: Fixes for v4.5

This is far too big a set of fixes for this late in the release cycle
but the overwhelming bulk is essentially the same simple fix from
Takashi for a cut'n'pasted 64 bit cleanliness issue in the userspace
interface where drivers were accessing things using the wrong element in
a union which worked OK on 32 bit platforms as the correct element
happened to be aligned the same way but with 64 bit platforms ABIs are
different and the two members of the union are laid out in different
places.  They aren't all tagged to stable since some of these chips have
vanishingly little chance of being used in 64 bit systems.

The other changes are:
 - A fix for Qualcomm devices to work on big endian systems.  The
   original change is actually correct but triggered a bug in regmap
   which is too invasive to fix for this cycle and can be worked around
   by just letting regmap pick the default.
 - A fix for the Samsung I2S driver locking which wasn't using IRQ safe
   spinlocks when it needed to.
 - A fix for the new Intel Sky Lake driver forgetting that C pointer
   arithmetic takes the type of the pointer into consideration.
 - A revert of a change to the FSL SSI driver that broke some systems.
 - A fix for the cleanup path of the wm9713 driver.
 - A fix for some incorrect register definitions in the ADAU17x1 driver
   that caused misclocking in some configurations.
 - A fix for the tracepoints for jack detection to avoid using an
   internal field of the core jack structure which is no longer present
   in all configurations.
 - A fix for another of the new Intel drivers which tried to write to a
   string literal.

# gpg: Signature made Mon 07 Mar 2016 09:41:48 ICT using RSA key ID 5D5487D0
# gpg: key CD7BEEBC: no public key for trusted key - skipped
# gpg: key CD7BEEBC marked as ultimately trusted
# gpg: key AF88CD16: no public key for trusted key - skipped
# gpg: key AF88CD16 marked as ultimately trusted
# gpg: key 16005C11: no public key for trusted key - skipped
# gpg: key 16005C11 marked as ultimately trusted
# gpg: key 5621E907: no public key for trusted key - skipped
# gpg: key 5621E907 marked as ultimately trusted
# gpg: key 5C6153AD: no public key for trusted key - skipped
# gpg: key 5C6153AD marked as ultimately trusted
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg:                 aka "Mark Brown <broonie@debian.org>"
# gpg:                 aka "Mark Brown <broonie@kernel.org>"
# gpg:                 aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg:                 aka "Mark Brown <broonie@linaro.org>"
# gpg:                 aka "Mark Brown <Mark.Brown@linaro.org>"