The previous fix for addressing the breakage in vmaster slave
initialization, commit a91d6612 ("ALSA: hda - Fix incorrect TLV
callback check introduced during set_fs() removal"), introduced a new
helper to process over each slave kctl.  However, this helper passes
only the original kctl, not the virtual slave kctl.  As a result,
HD-audio driver (which is the only user so far) couldn't initialize
the slave correctly because it's trying to update the value directly
with the original kctl, not with the mapped kctl.

This patch fixes the situation again by passing both the mapped slaved
and original slave kctls to the function.  Luckily there is a single
caller as of now, so changing the call signature is no big matter.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197959
Fixes: a91d6612 ("ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The refresh of HD-audio widget sysfs kobjects via
snd_hdac_refresh_widget_sysfs() is slightly racy.
The driver recreates the whole tree from scratch after deleting the
whole.  When CONFIG_DEBUG_KOBJECT_RELEASE option is used, kobject
release doesn't happen immediately but delayed, while the re-creation
of the same named kobject happens soon after invoking kobject_put().
This may end up with the conflicts of duplicated kobjects, as found in
the bug report below.

In this patch, we take another approach to refresh the tree: instead
of recreating the whole tree, just add the new nodes and delete the
non-existing nodes.  Since the refresh happens only once at
initialization, no longer race would happen.

Along with the code change, merge snd_hdac_refresh_widget_sysfs() with
the existing snd_hdac_refresh_widgets() with an additional bool flag
for simplifying the code.

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

The commit 99b5c5bb ("ALSA: hda - Remove the use of set_fs()")
converted the get_kctl_0dB_offset() call for killing set_fs() usage in
HD-audio codec code.  The conversion assumed that the TLV callback
used in HD-audio code is only snd_hda_mixer_amp() and applies the TLV
calculation locally.

Although this assumption is correct, and all slave kctls are actually
with that callback, the current code is still utterly buggy; it
doesn't hit this condition and falls back to the next check.  It's
because the function gets called after adding slave kctls to vmaster.
By assigning a slave kctl, the slave kctl object is faked inside
vmaster code, and the whole kctl ops are overridden.  Thus the
callback op points to a different value from what we've assumed.

More badly, as reported by the KERNEXEC and UDEREF features of PaX,
the code flow turns into the unexpected pitfall.  The next fallback
check is SNDRV_CTL_ELEM_ACCESS_TLV_READ access bit, and this always
hits for each kctl with TLV.  Then it evaluates the callback function
pointer wrongly as if it were a TLV array.  Although currently its
side-effect is fairly limited, this incorrect reference may lead to an
unpleasant result.

For addressing the regression, this patch introduces a new helper to
vmaster code, snd_ctl_apply_vmaster_slaves().  This works similarly
like the existing map_slaves() in hda_codec.c: it loops over the slave
list of the given master, and applies the given function to each
slave.  Then the initializer function receives the right kctl object
and we can compare the correct pointer instead of the faked one.

Also, for catching the similar breakage in future, give an error
message when the unexpected TLV callback is found and bail out
immediately.

Fixes: 99b5c5bb ("ALSA: hda - Remove the use of set_fs()")
Reported-by: NPaX Team <pageexec@freemail.hu>
Cc: <stable@vger.kernel.org> # v4.13
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

While converting the error messages to the standard macros in the
commit 4e76a883 ("ALSA: hda - Replace with standard printk"), a
superfluous '-' slipped in the code mistakenly.  Its influence is
almost negligible, merely shows a dB value as negative integer instead
of positive integer (or vice versa) in the rare error message.
So let's kill this embarrassing byte to show more correct value.

Fixes: 4e76a883 ("ALSA: hda - Replace with standard printk")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit fb087eaa ("ALSA: hda - hdmi eld control created based on pcm")
forget to filter out invalid pcm numbers, if there is only one invalid pcm
number, then this issue causes we create eld control for invalid pcm silently,
but when there are more than one invalid pcm numbers, then this issue bring
probe error looks like below dmesg:
"
kernel: [    1.647283] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops 0xc2967540)
kernel: [    1.651192] snd_hda_intel 0000:00:03.0: Too many HDMI devices
kernel: [    1.651195] snd_hda_intel 0000:00:03.0: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y
kernel: [    1.651197] snd_hda_intel 0000:00:03.0: Too many HDMI devices
kernel: [    1.651199] snd_hda_intel 0000:00:03.0: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y
kernel: [    1.651201] snd_hda_intel 0000:00:03.0: Too many HDMI devices
kernel: [    1.651203] snd_hda_intel 0000:00:03.0: Consider building the kernel with CONFIG_SND_DYNAMIC_MINORS=y
kernel: [    1.651676] snd_hda_intel 0000:00:03.0: control 3:0:0:ELD:0 is already present
kernel: [    1.651787] snd_hda_codec_hdmi: probe of hdaudioC0D0 failed with error -16
"

This patch add invalid pcm number filter before calling hdmi_create_eld_ctl.

Fixes: fb087eaa ("ALSA: hda - hdmi eld control created based on pcm")
Signed-off-by: NWang YanQing <udknight@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

set_fs() is used in HD-audio vmaster code to retrieve the TLV data of
each slave kctl.  Since the slave is supposed to be a standard amp
kctl, we can call directly the supposed tlv callback instead of the
indirect call, so that we can remove the set_fs() hack.
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now all the users of this workaround code is gone, and we can finally
remove the legacy codes from the core HD-audio module.
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The generic parser is the only user of the bind-mixer controls, so we
can move the code there and clean up the core helper.
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Declare snd_kcontrol_new structures as const as they are only passed as
an argument to the function snd_ctl_new1. This argument is of type
const, so snd_kcontrol_new structures having the same property can be
made const too.
Done using Coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct snd_kcontrol_new i@p = {...};

@ok1@
identifier r1.i;
position p;
expression e1;
@@
snd_ctl_new1(&i@p,e1)

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct snd_kcontrol_new i;
Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the DP MST audio support on i915 platform and
it will enable dyn_pcm_assign feature.

DP MST supports several device entry on the same port and each
device entry can map to one pcm stream. For example, on i915,
there are 3 pins, and each pin has 3 device entries. This means
there should be 3x3 pcms. However, there is only 3 pipe lines in
i915. This means 3 pcms are actived at most at the same moment.
We will create 5 pcms (pin number + dev entry num - 1) in this case.
For the details, please refer commit a76056f2
("ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug")

Each device entry is a virtual pin. It is described by pin_nid and dev_id
in struct hdmi_spec_per_pin.
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1484208294-8637-3-git-send-email-libin.yang@intel.com

Add snd_hda_get_dev_select() and snd_hda_set_dev_select() functions
for DP MST audio support.
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1484208294-8637-2-git-send-email-libin.yang@intel.com

This patch fixes some warnings from klockwork.

These warnings are not the real issues. The patch
adds the sanity check.
Signed-off-by: NLibin Yang <libin.yang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The HDA codec driver issues snd_hda_codec_reset() at the error path of
PCM build.  This was needed in the earlier code base, but the recent
rewrite to use the standard bus binding made this a deadlock:
 modprobe        D 0000000000000005     0   720    716 0x00000080
 Call Trace:
  [<ffffffff816a5dbe>] schedule+0x3e/0x90
  [<ffffffff816a61a5>] schedule_preempt_disabled+0x15/0x20
  [<ffffffff816a7ae5>] __mutex_lock_slowpath+0xb5/0x120
  [<ffffffff816a7b6b>] mutex_lock+0x1b/0x30
  [<ffffffff8148656b>] device_release_driver+0x1b/0x30
  [<ffffffff81485c15>] bus_remove_device+0x105/0x180
  [<ffffffff814822b9>] device_del+0x139/0x260
  [<ffffffffa05e0ec5>] snd_hdac_device_unregister+0x25/0x30 [snd_hda_core]
  [<ffffffffa074fa6a>] snd_hda_codec_reset+0x2a/0x70 [snd_hda_codec]
  [<ffffffffa075007b>] snd_hda_codec_build_pcms+0x18b/0x1b0 [snd_hda_codec]
  [<ffffffffa074a44e>] hda_codec_driver_probe+0xbe/0x140 [snd_hda_codec]
  [<ffffffff81486ac4>] driver_probe_device+0x1f4/0x460
  [<ffffffff81486dc0>] __driver_attach+0x90/0xa0
  [<ffffffff81484844>] bus_for_each_dev+0x64/0xa0
  [<ffffffff814862de>] driver_attach+0x1e/0x20
  [<ffffffff81485e7b>] bus_add_driver+0x1eb/0x280
  [<ffffffff81487680>] driver_register+0x60/0xe0
  [<ffffffffa074a0da>] __hda_codec_driver_register+0x5a/0x60 [snd_hda_codec]
  [<ffffffffa070a01e>] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek]
  [<ffffffff810002f3>] do_one_initcall+0xb3/0x200
  [<ffffffff816a1fc5>] do_init_module+0x60/0x1f8
  [<ffffffff810ee5c3>] load_module+0x1653/0x1bd0
  [<ffffffff810eed48>] SYSC_finit_module+0x98/0xc0
  [<ffffffff810eed8e>] SyS_finit_module+0xe/0x10
  [<ffffffff816aa032>] entry_SYSCALL_64_fastpath+0x16/0x75

The simple fix is just to remove this call, since we don't need to
think about unbinding at there any longer.

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

The recent commit [7fbe824a: ALSA: hda - Update mixer name for the
lower codec address] tried to improve the mixer chip name assignment
in the order of codec address.  However, this fix was utterly bogus;
it checks the field set in each codec, thus this value is reset at
each codec creation, of course.  For really handling this priority,
the assignment has to be remembered in the common place, namely in
hda_bus, instead of hda_codec.

Fixes: 7fbe824a ('ALSA: hda - Update mixer name for the lower codec address')
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In most cases, we prefer the onboard codec as the primary device, thus
it's better to set it as the mixer name.  Currently, however, the
mixer name is updated per the device instantiation order, and user
gets often HDMI/DP or other seen as a mixer chip name.  Also, if a
codec name is renamed by the driver, the old chip name might be left
still as the mixer name.

This patch addresses these issues by remembering the chip address that
was referred as the mixer name.  When a codec with the same or lower
address gives its name, renew the mixer name accordingly, as it's
either the update of the codec name or we get likely the more
appropriate chip as the reference.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now that we have introduced the core fns we should make hda use these
helpers
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The variable pcm can be never NULL since it was rewritten with
list_for_each_entry().
Suggested-by: NMarkus Osterhoff <linux-kernel@k-raum.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In the commit [fa4f18b4: ALSA: hda - Refresh widgets sysfs at
probing Haswell+ HDMI codecs], snd_hdac_refresh_widget_sysfs() is
explicitly called in the codec driver.  But this results in refreshing
twice, as snd_hdac_refresh_widget_sysfs() itself calls
snd_hdac_refresh_widgets() function.

Instead, we can replace the call in snd_hda_codec_update_widgets()
with snd_hdac_refresh_widget_sysfs().  This also fixes the missing
sysfs update for ca0132, too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

After a for-loop was replaced by list_for_each_entry, see
Commit bbbc7e85 ("ALSA: hda - Allocate hda_pcm objects dynamically"),
Commit 751e2216 ("ALSA: hda: fix possible null dereference"),
a possible NULL pointer dereference has been introduced; this patch adds
the NULL check on pcm->pcm, while leaving a potentially superfluous
check on pcm itself untouched.
Signed-off-by: NMarkus Osterhoff <linux-kernel@k-raum.org>
Cc: <stable@vger.kernel.org> #v4.1+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A few helper functions to convert the pin information to strings have
been exported with assumption that they were used by other drivers.
But they are referred only in the proc interface in the end.

Let's make them local so that we can get rid of a few exports.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In kstrdup we should return -ENOMEM when it reports an
memory allocation failure, while the -ENODEV is referred
to a failure in finding the cpu node in the device tree.
Signed-off-by: NHeloise NH <kernelpatch_update@163.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_hdac_link_power() has to be called after unregistering the codec
device.  Otherwise the device might be already runtime-suspended, thus
the refcount goes under zero, triggering a warning like:

  WARNING: CPU: 7 PID: 2014 at sound/hda/hdac_i915.c:63 snd_hdac_display_power+0x106/0x120 [snd_hda_core]()
  CPU: 7 PID: 2014 Comm: modprobe Not tainted 4.1.0-rc7-test+ #1
  Call Trace:
   [<ffffffff81697fe3>] dump_stack+0x4c/0x6e
   [<ffffffff810696da>] warn_slowpath_common+0x8a/0xc0
   [<ffffffff810697ca>] warn_slowpath_null+0x1a/0x20
   [<ffffffffa02dd526>] snd_hdac_display_power+0x106/0x120 [snd_hda_core]
   [<ffffffffa030b422>] azx_intel_link_power+0x12/0x20 [snd_hda_intel]
   [<ffffffffa037139f>] azx_link_power+0x1f/0x30 [snd_hda_codec]
   [<ffffffffa02d89fe>] snd_hdac_link_power+0x2e/0x40 [snd_hda_core]
   [<ffffffffa0368524>] snd_hda_codec_dev_free+0x34/0x50 [snd_hda_codec]
   [<ffffffffa0252061>] __snd_device_free+0x51/0xa0 [snd]
   .....
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Yet another regression by the transition to regmap cache; for better
usability, we had the fake mute control using the zero amp value for
Conexant codecs, and this was forgotten in the new hda core code.

Since the bits 4-7 are unused for the amp registers (as we follow the
syntax of AMP_GET verb), the bit 4 is now used to indicate the fake
mute.  For setting this flag, snd_hda_codec_amp_update() becomes a
function from a simple macro.  The bonus is that it gained a proper
function description.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Enable runtime PM of the HDMI audio codec on the latest Intel platforms.
So the HD-A controller or HDMI codec can suspend when idle timeout by
default and release the GFX power well.
The patch influences HSW/BDW/BYT/BSW/SKL. Eariler platforms and third
party analog codecs will not be influenced.
Signed-off-by: NLu, Han <han.lu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The new regmap code seems to cache this, which isn't helpful
for the hotplug dock situation where this gets updated.

Use the uncached query for this.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A flag "link_power_control" is added to indicate whether a codec needs to
control the link power.  And a new bus ops link_power() is defined for the
codec to request to enable/disable the link power.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reported by coverity CID 1296024.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The mute-LED mode control has the fixed on/off states that are
supposed to remain on/off regardless of the master switch.  However,
this doesn't work actually because the vmaster hook is called in the
vmaster code itself.

This patch fixes it by calling the hook indirectly after checking the
mute LED mode.
Reported-and-tested-by: NPali Rohár <pali.rohar@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Originally hda_bus takes its own ops (hda_bus_ops) to allow different
controller drivers giving individual implementations of PCM
attachment, etc.  But this never happened and we finally merged both
codec and controller helper codes.  Thus there is no merit to keep the
indirect accesses to functions via hda_bus_ops.

This patch replaces these calls with the direct local function calls
for simplification.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit [a551d914: ALSA: hda - Use regmap for command verb
caches, too] introduced a regression due to a typo in the conversion;
the IEC958 status bits of slave digital devices aren't updated
correctly.  This patch corrects it.

Fixes: a551d914 ('ALSA: hda - Use regmap for command verb caches, too')
Reported-and-tested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... and replace with the existing hda-core helper codes.
This reduces lots of lines, finally.

Since struct hda_bus is now embedded into struct azx,
snd_hda_bus_new() is moved and expanded from hda_codec.c to
hda_controller.c, accordingly.  Also private_free bus ops and
private_data field are removed because we no longer need to point azx
object from bus (we can use container_of())

The spin locks are consolidated into the single one, bus->reg_lock.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

One less redirection again.  This also requires the change of the call
order in the toplevel divers.  Namely, the bus has to be created at
first before other initializations since the memory allocation ops are
called through bus object now.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

One less redirection.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the controller helper codes to hda-core library.
The I/O access ops are added to the bus ops.  The CORB/RIRB, the basic
attributes like irq# and iomap address, some locks and the list of
streams are added to the bus object, together with the stream object
and its helpers.

Currently the codes are just copied from the legacy driver, so you can
find duplicated codes in both directories.  Only constants are removed
from the original hda_controller.h.  More integration work will follow
in the later patches.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... and drop bus->rirb_error flag.  This makes the code simpler.

We treat -EAGAIN from get_response ops as a special meaning: it allows
the caller to retry after bus reset.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently, snd_hdac_power_up()/down() helpers checks whether the codec
is being in pm (suspend/resume), and skips the call of runtime get/put
during it.  This is needed as there are lots of power up/down
sequences called in the paths that are also used in the PM itself.  An
example is found in hda_codec.c::codec_exec_verb(), where this can
power up the codec while it may be called again in its power up
sequence, too.

The above works in most cases, but sometimes we really want to wait
for the real power up.  For example, the control element get/put may
want explicit power up so that the value change is assured to reach to
the hardware.   Using the current snd_hdac_power_up(), however,
results in a race, e.g. when it's called during the runtime suspend is
being performed.  In the worst case, as found in patch_ca0132.c, it
can even lead to the deadlock because the code assumes the power up
while it was skipped due to the check above.

For dealing with such cases, this patch makes snd_hdac_power_up() and
_down() to two variants: with and without in_pm flag check.  The
version with pm flag check is named as snd_hdac_power_up_pm() while
the version without pm flag check is still kept as
snd_hdac_power_up().  (Just because the usage of the former is fewer.)

Then finally, the patch replaces each call potentially done in PM with
the new _pm() variant.

In theory, we can implement a unified version -- if we can distinguish
the current context whether it's in the pm path.  But such an
implementation is cumbersome, so leave the code like this a bit messy
way for now...

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

we are dereferencing pcm first then checking pcm. instead now lets put
them in same if condition so that pcm is checked first.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>