Both of Fireface 400/800 have the same register to switch frame fetching
mode regardless of difference of available number of PCM frames in
rx isochronous packet.

This commit moves a helper function from model-dependent implementation.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

According to my memo at hand and saved records, writing 0x00000001 to
SND_FF_REG_FETCH_PCM_FRAMES disables fetching PCM frames in corresponding
channel, however current implement uses reversed logic. This results in
muted volume in device side during playback.

This commit corrects the bug.

Cc: <stable@vger.kernel.org> # v4.12+
Fixes: 76fdb3a9 ('ALSA: fireface: add support for Fireface 400')
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

An initial commit to add tracepoints for packets without CIP headers
uses different print formats for added tracepoints. However this is not
convenient for users/developers to prepare debug tools.

This commit uses the same format for the two tracepoints.

Cc: <stable@vger.kernel.org> # v4.12+
Fixes: b164d2fd ('ALSA: firewire_lib: add tracepoints for packets without CIP headers')
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

An initial commit to add tracepoints for packets without CIP headers
introduces a wrong assignment to 'data_blocks' value of
'out_packet_without_header' tracepoint.

This commit fixes the bug.

Cc: <stable@vger.kernel.org> # v4.12+
Fixes: b164d2fd ('ALSA: firewire_lib: add tracepoints for packets without CIP headers')
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In IEC 61883-1/6 engine of ALSA firewire stack, a packet handler has a
second argument for 'the number of bytes in payload of isochronous
packet'. However, an incoming packet handler without CIP header uses the
value as 'the number of quadlets in the payload'. This brings userspace
applications to receive the number of PCM frames as four times against
real time.

This commit fixes the bug.

Cc: <stable@vger.kernel.org> # v4.12+
Fixes: 3b196c39 ('ALSA: firewire-lib: add no-header packet processing')
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Pull Huawei LEDS and hotkey support.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some of Huawei laptops come with a LED in the micmute key. This patch
enables the use of micmute LED for these devices:
1. Matebook X (19e5:3200), (19e5:3201)
2. Matebook X Pro (19e5:3204)
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAyman Bagabas <ayman.bagabas@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This driver adds support for missing hotkeys on some Huawei laptops.
Laptops such as the Matebook X have non functioning hotkeys. Whereas
newer laptops such as the Matebook X Pro come with working hotkeys out
of the box.

Old laptops, such as the Matebook X, report hotkey events through ACPI
device "\WMI0". However, new laptops, such as the Matebook X Pro, does
not have this WMI device.

All the hotkeys on the Matebook X Pro work fine without this patch
except (micmute, wlan, and huawei key). These keys and the brightness
keys report events to "\AMW0" ACPI device. One problem is that
brightness keys on the Matebook X Pro work without this patch. This
results in reporting two brightness key press events one is captured
by ACPI and another by this driver.

A solution would be to check if such event came from the "\AMW0" WMI
driver then skip reporting event. Another solution would be to leave
this to user-space to handle. Which can be achieved by using "hwdb"
tables and remap those keys to "unknown". This solution seems more
natural to me because it leaves the decision to user-space.
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAyman Bagabas <ayman.bagabas@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200501Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAyman Bagabas <ayman.bagabas@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

stream is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/core/pcm.c:140 snd_pcm_control_ioctl() warn: potential spectre issue 'pcm->streams' [r] (local cap)

Fix this by sanitizing stream before using it to index pcm->streams

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

info.mode and info.port are indirectly controlled by user-space,
hence leading to a potential exploitation of the Spectre variant 1
vulnerability.

These issues were detected with the help of Smatch:

sound/synth/emux/emux_hwdep.c:72 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs[i]->ctrls' [w] (local cap)
sound/synth/emux/emux_hwdep.c:75 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs' [w] (local cap)
sound/synth/emux/emux_hwdep.c:75 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs[info.port]->ctrls' [w] (local cap)

Fix this by sanitizing both info.mode and info.port before using them
to index emu->portptrs[i]->ctrls, emu->portptrs[info.port]->ctrls and
emu->portptrs.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Pull refactoring / fixes of HD-audio PM and display power management
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fireface 800 is a flagship model of RME GmbH for audio and music units
on IEEE 1394 bus, shipped 2004. This model consists of four chips:
 - TI TSB81BA3D for physical layer on cable environment of EEE 1394 bus
 - TI TSB82AA2 for link layer for 1394 OHCI bus bridge to PCI bus
 - Xilinx Spartan-3 FPGA XC3S400
 - Xilinx High-Performance CPLD XC9572XL

This commit adds support Fireface 800. In this time, the support is
restricted to its MIDI functionality, thus this commit adds some
condition statements to avoid touching streaming functionality.

Unlike Fireface 400, Fireface 800 has no functionality to suppress
asynchronous transactions for MIDI messages except for unregister of
listen address in controller side, thus the feature is available as is.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Content of asynchronous transaction for MIDI messages differs between
Fireface 400 and 800.

This commit adds a model-specific handler for the transaction and adds
arrangement.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fireface 400 and 800 have the same mechanism to decide address to which
asynchronous transactions are sent for MIDI messages, however they use
different registers for controllers to notify higher 4 byte of the
address.

This commit adds a model-specific parameter to represent the address.
Additionally, it corrects some comments. I note that these two models have
a difference to enable/disable the transaction.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As long as investigating packet dumps from Fireface 400/800, a register
to receive asynchronous transactions for MIDI messages is the same. For
Fireface 800, minor register is used.

This commit declares macros for the transactions and obsoletes
model-specific parameters.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Unlike Fireface 400, Fireface 800 have two pair of optical interface
for ADAT signal and S/PDIF signal. ADAT signals for the interface
are handled for sampling clock source separately.

This commit modifies a parser for clock configuration to distinguish
these two ADAT signals.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As long as investigating packet dumps from Fireface 400/800, bits on
status registers for clock synchronization are the same.

This commit moves a parser for a register of clock configuration to
obsolete model-specific operations.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As long as investigating packet dumps from Fireface 400/800, bits on
status registers for clock synchronization are the same.

This commit moves a parser for the registers to obsolete model-specific
operations.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As long as investigating packet dumps from Fireface 400/800, status
registers for clock synchronization is common.

This commit moves some macros for them to header file.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When building without CONFIG_PCI, we can (depending on the architecture)
get a link failure:

ERROR: "pci_iounmap" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!

Adding a compile-time check for PCI gets it to work correctly on
32-bit ARM.

Fixes: d99501b8 ("ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We've excluded the display_power_control flag for Intel HSW and BDW
codecs as the HD-audio controllers of the corresponding platforms take
care of the display power as well.  But the recent refactoring
separates the controller and the codec power accounting, so it's fine
to call the display PM even for HSW/BDW codecs.  This is less
confusing since we can avoid this well-hidden condition.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The display power is in unbalance at removing the driver since it
misses the snd_hdac_display_power(OFF) call.
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

After the recent refactoring, snd_hdac_display_power() doesn't return
any error, hence it can be defined to return void.
This makes many error checks redundant and allows us to reduce them
gracefully.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When an error occurs in azx_probe_continue(), we should release the
display power.  However, the current code ignores it and releases the
display power only for HSW/BDW cases.  Fix it.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_hdac_display_power() can be called even for a HDA controller
without DRM binding.  The same is true for other helpers,
snd_hdac_i915_set_bclk() and snd_hdac_set_codec_wakeup().
So all superfluous AZX_DCAPS_I915_POWERWELL  checks in hda_intel.c can
be dropped, and the definition of AZX_DCAPS_I915_POWERWELL itself can
be removed as well.  This simplifies the code a lot.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current HD-audio code manages the DRM audio power via too complex
redirections, and this seems even still unbalanced in a corner case as
Intel DRM CI has been intermittently reporting.  This patch is a big
surgery for addressing the complexity and the possible unbalance.

Basically the patch changes the display PM in the following ways:

- Both HD-audio controller and codec drivers call a single helper,
  snd_hdac_display_power().  (Formerly, the display power control from
  a codec was done indirectly via link_power bus ops.)

- snd_hdac_display_power() receives the codec address index.  For
  turning on/off from the controller, pass HDA_CODEC_IDX_CONTROLLER.

- snd_hdac_display_power() doesn't manage refcounts any longer, but
  keeps the power status in bitmap.  If any of controller or codecs is
  turned on, the function updates the DRM power state via get_power()
  or put_power().

Also this refactor allows us more cleanup:

- The link_power bus ops is dropped, so there is no longer indirect
  management, as mentioned in the above.

- hdac_device link_power_control flag is moved to hda_codec
  display_power_control flag, as it's only for HDA legacy.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106525Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Back-merge for resolving the conflict of fixup entries added in both
branches.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The ASUS UX433FN and UX333FA with ALC294 cannot detect the headset MIC
and output through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK and ALC294_FIXUP_ASUS_HEADSET_MIC quirk applied.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NJian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The ASUS UX533FD with ALC294 cannot detect the headset MIC and outputs
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK and ALC294_FIXUP_ASUS_HEADSET_MIC quirk applied.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NJian-Hong Pan <jian-hong@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The known ALC256_FIXUP_ASUS_MIC fixup can fix the headphone jack
sensing and enable use of the internal microphone on this laptop
X542UN. However, it's ALC294 so create a new fixup named
ALC294_FIXUP_ASUS_MIC to avoid confusion.
Signed-off-by: NJian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NChris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Make unified suspend / resume helpers and call them from both the
runtime- and the system-PM callbacks for simplifying code.

There are slight changes of call orders, but there shouldn't be any
functional difference after refactoring.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In an initial commit, 'SYNC_STATUS' register is referred to get
clock configuration, however this is wrong, according to my local
note at hand for reverse-engineering about packet dump. It should
be 'CLOCK_CONFIG' register. Actually, ff400_dump_clock_config()
is correctly programmed.

This commit fixes the bug.

Cc: <stable@vger.kernel.org> # v4.12+
Fixes: 76fdb3a9 ('ALSA: fireface: add support for Fireface 400')
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Users reported a mute LED regression on Lenovo X1 Carbon, the root
cause is we applied the fixup of ALC285_FIXUP_LENOVO_HEADPHONE_NOISE
to this machine, then the machine can't apply the fixup of
ALC269_FIXUP_THINKPAD_ACPI anymore. To fix it, we chain two fixup
together.

Fixes: c4cfcf6f ("ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops")
Cc: <stable@vger.kernel.org>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch will enable headset button for new Chrome platform.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Extend some structs to add the support for jack button changes.
Now snd_hda_jack_add_kctl() receives two more arguments: the jack type
and the jack keymaps.  Both are optional, and when zero are passed,
the function behaves just like before.

For reporting button state changes, you'd need to update
jack->button_state bits accordingly, typically in the jack callback.
Then the value OR'ed with button_state and the jack plug state is
passed to snd_jack_report().

Note that currently the code assumes only the one-shot button events,
i.e. it tries to send the button release soon after sending the button
event.  If a driver really supports the button release handling by
itself, we may need to introduce some flag to control this behavior in
future.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For allowing the callee to evaluate the associated jack information
and the unsolicited event data, add the new fields to
hda_jack_callback.  They can be used, for example, to retrieve the
headset button state in the callback.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Back-merge for applying the more HD-audio quirks on top of the latest
code.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

If it plugged headphone or headset into the jack, then
do the reboot, it will have a chance to cause headphone no sound.
It just need to run the headphone mode procedure after boot time.
The issue will be fixed.
It also suitable for ALC234 ALC274 and ALC294.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.

A couple of open coded iterating thru the child node names are converted
to use for_each_child_of_node() instead.
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>