The issue is the same as "dd9aa335 ALSA: hda/realtek - Can't adjust
speaker's volume on a Dell AIO", the output requires to connect to a node
with Amp-out capability.

Applying the same fixup "ALC298_FIXUP_SPK_VOLUME" can fix the issue.
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It seems that newer Intel chipsets have more than 15 I/O streams (total).
This patch forces the separate stream tags, when this hardware is detected
to avoid SDxCTL.STRM field overflow and an unexpected behaviour.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Like for Sunrise Point, the total stream number of Lewisburg's
input and output stream exceeds 15 (GCAP is 0x9701), which will
cause some streams do not work because of the overflow on
SDxCTL.STRM field if using the legacy stream tag allocation method.

Fixes: 5cf92c8b ("ALSA: hda - Add Intel Lewisburg device IDs Audio")
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The AmigaOne X1000 has a Sigmatel STAC92HD700 attached to the HD Audio
on an ATI SB600. Add the required settings to enable sound.
Signed-off-by: NDarren Stevens <darren@stevens-zone.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The pcm_stream_info.running field is only set in the PCM trigger
callback but never referred, thus it can be safely removed.

Also, properly cover the spinlock in both the trigger START and STOP
to protect had_enable_audio() calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently the driver handles some reset procedure at the trigger STOP
and the underrun functions, where both are executed in the interrupt
context.  Especially the underrun function has a sync-loop to clear
the UNDERRUN status bit, and this is supposed to be one of plausible
causes of GPU hangup.

Since the job to be done in the interrupt handler should be minimum,
we move the reset function out of trigger and underrun, and push it
into the prepare (and hw_free) callbacks instead.  Here a new flag,
need_reset, is introduced to indicate the requirement of the reset
procedure.  This is for avoiding the multiple resets when PCM prepare
is called sequentially.

Also in the UNDERRUN bit-clear sync loop, take a longer pause to be in
the safer side.  Taking a longer delay is no longer a problem now
because we're running in the normal context.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now we support S16 PCM format in addition.  For this, we need to set
packet_mode=1 in AUD_CONFIG register.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The hardware has the support for the left-aligned 24bit format in
32bit packet.  This corresponds to S32 format in ALSA.  We need to set
the msbits restriction as well to inform user-space that only MSB
24bit are available.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In the current implementation, the driver may update the BDs even at
PCM pointer callback.  This allows us to skip the period interrupt
effectively.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is an implementation of PCM streaming with only 1 period.
Since the hardware requires the refresh of BDs after each BD
processing finishes, we'd need at least two BDs.  The trick is that
both BDs point to the same content: the address of the PCM buffer
head, and the whole buffer size.  Then it loops over to the whole
buffer again after it finished once.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The PCM engine on LPE audio isn't like a batch-style process any
longer, but rather it deals with the standard ring buffer.  Remove the
BATCH info flag so that PA can handle the buffer in timer-sched mode.

Similarly, the DOUBLE flag is also superfluous.  Drop both bits.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

At enabling the audio, we modify AUD_CONFIG register bit 0.  So far,
it does read-modify-write procedure with a special hack for the
channel bits due to the silicon bug.  But we can optimize it by
remembering the AUD_CONFIG register value privately.  This simplifies
the things a lot.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We have two header files and everything is mixed up chaotically.
Move the chip-specific definitions like the hardware registers to
intel_hdmi_lpe_audio.h, and the rest, the implementation specific
stuff into intel_hdmi_audio.h.

In addition, put some more comments to the register fields, and fix
the incorrect name prefix for AUD_HDMI_STATUS bits, too.

The whole changes are merely a code shuffling, and there is no
functional change.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The two functions are unused when CONFIG_PM_SLEEP is disabled:

sound/x86/intel_hdmi_audio.c:1633:12: error: 'hdmi_lpe_audio_resume' defined but not used [-Werror=unused-function]
sound/x86/intel_hdmi_audio.c:1622:12: error: 'hdmi_lpe_audio_suspend' defined but not used [-Werror=unused-function]

Marking them as __maybe_unused avoids the warning without introducing an
ugly #ifdef.

Fixes: 182cdf23 ("ALSA: x86: Implement runtime PM")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The driver sets card->driver name string over its size (16 bytes).
Shorten the name string to fit with it.

Also, set more verbose string to card->shortname and ->longname.
This doesn't have to be identical with card->driver at all.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

had_enable_audio_int() came from the LPE audio shell set_caps
callback with ENABLE_INT and DISABLE_INT caps.  I interpreted as these
correspond to enabling / disabling the audio interface, but the actual
implementation is only to clear (send ACK) to both BUFFER_DONE and
BUFFER_UNDERRUN interrupts unconditionally.  And, there is no
counterpart, DISABLE_INT, code at all.

For avoiding the further misunderstanding, rename the function to the
more fitting one, had_ack_irqs(), and drop the calls with enable=false
in allover places.  There is no functional changes at all.

After this patch, there is only one caller at the PCM trigger start.
Then it's doubtful whether this call is still really needed or not; I
bet it not, but let's stay in the safer side for now and keep it as
was.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

U24 format is declared to be supported by the driver, but this looks
really doubtful, as there is no corresponding code.  Better to drop
it.  This format is very uncommon, so there should be practically no
impact by this change.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

While not all line6 devices currently support PCM, it causes no
harm to 'have it prepared'.

This also fixes toneport, which only has PCM - in which case
we previously skipped the USB transfer properties detection completely.
Signed-off-by: NAndrej Krutak <dev@andree.sk>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This reverts commit f6a0dd10.

The commit caused a regression on LINE6 Transport that has no control
caps.  Although reverting the commit may result back in a spurious
error message for some device again, it's the simplest regression fix,
hence it's taken as is at first.  The further code fix will follow
later.

Fixes: f6a0dd10 ("ALSA: line6: Only determine control port properties if needed")
Reported-by: NIgor Zinovev <zinigor@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_seq_pool_done() syncs with closing of all opened threads, but it
aborts the wait loop with a timeout, and proceeds to the release
resource even if not all threads have been closed.  The timeout was 5
seconds, and if you run a crazy stuff, it can exceed easily, and may
result in the access of the invalid memory address -- this is what
syzkaller detected in a bug report.

As a fix, let the code graduate from naiveness, simply remove the loop
timeout.

BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.comReported-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is again a big rewrite of the driver; now it touches the code to
process PCM stream transfers.

The most fundamental change is that the driver may support more than
four periods.  Instead of keeping the same index between both the ring
buffer (with the fixed four buffer descriptors) and the PCM buffer
periods, we keep difference indices for both (bd_head and pcm_head
fields).  In addition, when the periods are more than four, we need to
track both head and next indices.  That is, we now have three indices:
bd_head, pcm_head and pcm_filled.

Also, the driver works better for periods < 4, too: the remaining BDs
out of four are marked as invalid, so that the hardware skips those
BDs in its loop.

By this flexibility, we can use even ALSA-lib dmix plugin, which
requires 16 periods as default.

The buffer size could be up to 20bit, so the max buffer size was
increased accordingly.  However, the buffer pre-allocation is kept as
the old value (600kB) as default.  The reason is the limited number of
BDs: since it doesn't suffice for the useful SG page management that
can fit with the usual page allocator like some other drivers, we have
to still allocate continuous pages, hence we shouldn't take too big
memories there.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... so that the driver can avoid ifdef's for the dead PM callbacks.
The compiler should optimize them out in anyway.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use had_ prefix consistently to all local helper functions, as well as
had_pcm_ for PCM ops.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The procedure to reset buffer pointers is performed in two places and
still open-coded.  Simplify the helper function and use it
consistently.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The lowlevel register read/write don't have to be careful about the
connection state.  It should be checked in the caller side instead.
By dropping the check, we can simplify the code, and readability.

This patch also refacors the functions slightly: namely,
- drop the useless always-zero return values
- fold the inline functions to the main accessor functions themselves
- move the DP audio hack for AUD_CONFIG to the caller side
- simplify snd_intelhad_eanble_audio() and drop the unused
  had_read_modify()
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

LPE audio is capable only up to 32bit address, as it seems.
Then we should limit the DMA addresses accordingly via dma-mapping
API.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Pull irq fixes from Thomas Gleixner:

 - Prevent double activation of interrupt lines, which causes problems
   on certain interrupt controllers

 - Handle the fallout of the above because x86 (ab)uses the activation
   function to reconfigure interrupts under the hood.

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/irq: Make irq activate operations symmetric
  irqdomain: Avoid activating interrupts more than once

Pull KVM fix from Radim Krčmář:
 "Fix a regression that prevented migration between hosts with different
  XSAVE features even if the missing features were not used by the guest
  (for stable)"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: do not save guest-unsupported XSAVE state

Pull char/misc driver fixes from Greg KH:
 "Here are two bugfixes that resolve some reported issues. One in the
  firmware loader, that should fix the much-reported problem of crashes
  with it. The other is a hyperv fix for a reported regression.

  Both have been in linux-next for a week or so with no reported issues"

* tag 'char-misc-4.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()
  firmware: fix NULL pointer dereference in __fw_load_abort()

Pull staging/IIO fixes from Greg KH:
 "Here are a few small IIO and one staging driver fix for 4.10-rc7. They
  fix some reported issues with the drivers.

  All of them have been in linux-next for a week or so with no reported
  issues"

* tag 'staging-4.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: greybus: timesync: validate platform state callback
  iio: dht11: Use usleep_range instead of msleep for start signal
  iio: adc: palmas_gpadc: retrieve a valid iio_dev in suspend/resume
  iio: health: max30100: fixed parenthesis around FIFO count check
  iio: health: afe4404: retrieve a valid iio_dev in suspend/resume
  iio: health: afe4403: retrieve a valid iio_dev in suspend/resume

Pull USB fixes from Greg KH:
 "Here are some small USB fixes for some reported issues, and the usual
  number of new device ids for 4.10-rc7.

  All of these, except the last new device id, have been in linux-next
  for a while with no reported issues"

* tag 'usb-4.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  USB: serial: pl2303: add ATEN device ID
  usb: gadget: f_fs: Assorted buffer overflow checks.
  USB: Add quirk for WORLDE easykey.25 MIDI keyboard
  usb: musb: Fix external abort on non-linefetch for musb_irq_work()
  usb: musb: Fix host mode error -71 regression
  USB: serial: option: add device ID for HP lt2523 (Novatel E371)
  USB: serial: qcserial: add Dell DW5570 QDL

Pull SCSI fix from James Bottomley:
 "A single fix this time: a fix for a virtqueue removal bug which only
  appears to affect S390, but which results in the queue hanging forever
  thus causing the machine to fail shutdown"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: virtio_scsi: Reject commands when virtqueue is broken

Pull virtio/vhost fixes from Michael S. Tsirkin:
 "Last minute fixes:

   - ARM DMA fix revert

   - vhost endian-ness fix

   - MAINTAINERS: email address change for Amit"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  MAINTAINERS: update email address for Amit Shah
  vhost: fix initialization for vq->is_le
  Revert "vring: Force use of DMA API for ARM-based systems with legacy devices"

Pull VFIO fix from Alex Williamson:
 "Fix an error path in SPAPR IOMMU backend (Alexey Kardashevskiy)"

* tag 'vfio-v4.10-rc7' of git://github.com/awilliam/linux-vfio:
  vfio/spapr: Fix missing mutex unlock when creating a window

Merge fixes from Andrew Morton:
 "8 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  mm, fs: check for fatal signals in do_generic_file_read()
  fs: break out of iomap_file_buffered_write on fatal signals
  base/memory, hotplug: fix a kernel oops in show_valid_zones()
  mm/memory_hotplug.c: check start_pfn in test_pages_in_a_zone()
  jump label: pass kbuild_cflags when checking for asm goto support
  shmem: fix sleeping from atomic context
  kasan: respect /proc/sys/kernel/traceoff_on_warning
  zswap: disable changing params if init fails

do_generic_file_read() can be told to perform a large request from
userspace.  If the system is under OOM and the reading task is the OOM
victim then it has an access to memory reserves and finishing the full
request can lead to the full memory depletion which is dangerous.  Make
sure we rather go with a short read and allow the killed task to
terminate.

Link: http://lkml.kernel.org/r/20170201092706.9966-3-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Tetsuo has noticed that an OOM stress test which performs large write
requests can cause the full memory reserves depletion.  He has tracked
this down to the following path

	__alloc_pages_nodemask+0x436/0x4d0
	alloc_pages_current+0x97/0x1b0
	__page_cache_alloc+0x15d/0x1a0          mm/filemap.c:728
	pagecache_get_page+0x5a/0x2b0           mm/filemap.c:1331
	grab_cache_page_write_begin+0x23/0x40   mm/filemap.c:2773
	iomap_write_begin+0x50/0xd0             fs/iomap.c:118
	iomap_write_actor+0xb5/0x1a0            fs/iomap.c:190
	? iomap_write_end+0x80/0x80             fs/iomap.c:150
	iomap_apply+0xb3/0x130                  fs/iomap.c:79
	iomap_file_buffered_write+0x68/0xa0     fs/iomap.c:243
	? iomap_write_end+0x80/0x80
	xfs_file_buffered_aio_write+0x132/0x390 [xfs]
	? remove_wait_queue+0x59/0x60
	xfs_file_write_iter+0x90/0x130 [xfs]
	__vfs_write+0xe5/0x140
	vfs_write+0xc7/0x1f0
	? syscall_trace_enter+0x1d0/0x380
	SyS_write+0x58/0xc0
	do_syscall_64+0x6c/0x200
	entry_SYSCALL64_slow_path+0x25/0x25

the oom victim has access to all memory reserves to make a forward
progress to exit easier.  But iomap_file_buffered_write and other
callers of iomap_apply loop to complete the full request.  We need to
check for fatal signals and back off with a short write instead.

As the iomap_apply delegates all the work down to the actor we have to
hook into those.  All callers that work with the page cache are calling
iomap_write_begin so we will check for signals there.  dax_iomap_actor
has to handle the situation explicitly because it copies data to the
userspace directly.  Other callers like iomap_page_mkwrite work on a
single page or iomap_fiemap_actor do not allocate memory based on the
given len.

Fixes: 68a9f5e7 ("xfs: implement iomap based buffered write path")
Link: http://lkml.kernel.org/r/20170201092706.9966-2-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: <stable@vger.kernel.org>	[4.8+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Reading a sysfs "memoryN/valid_zones" file leads to the following oops
when the first page of a range is not backed by struct page.
show_valid_zones() assumes that 'start_pfn' is always valid for
page_zone().

 BUG: unable to handle kernel paging request at ffffea017a000000
 IP: show_valid_zones+0x6f/0x160

This issue may happen on x86-64 systems with 64GiB or more memory since
their memory block size is bumped up to 2GiB.  [1] An example of such
systems is desribed below.  0x3240000000 is only aligned by 1GiB and
this memory block starts from 0x3200000000, which is not backed by
struct page.

 BIOS-e820: [mem 0x0000003240000000-0x000000603fffffff] usable

Since test_pages_in_a_zone() already checks holes, fix this issue by
extending this function to return 'valid_start' and 'valid_end' for a
given range.  show_valid_zones() then proceeds with the valid range.

[1] 'Commit bdee237c ("x86: mm: Use 2GB memory block size on
    large-memory x86-64 systems")'

Link: http://lkml.kernel.org/r/20170127222149.30893-3-toshi.kani@hpe.comSigned-off-by: NToshi Kani <toshi.kani@hpe.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Zhang Zhen <zhenzhang.zhang@huawei.com>
Cc: Reza Arbab <arbab@linux.vnet.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>	[4.4+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>