20 Jun, 2017
1 commit
-
Broxton-T was a forgotten child and we didn't apply the quirks for
Skylake+ properly. Meanwhile, a quirk for reducing the DMA latency
seems specific to the early Broxton model, so we leave as is.Cc:
Signed-off-by: Takashi Iwai
19 Jun, 2017
1 commit
-
At Linux v3.5, packet processing can be done in process context of ALSA
PCM application as well as software IRQ context for OHCI 1394. Below is
an example of the callgraph (some calls are omitted).ioctl(2) with e.g. HWSYNC
(sound/core/pcm_native.c)
->snd_pcm_common_ioctl1()
->snd_pcm_hwsync()
->snd_pcm_stream_lock_irq
(sound/core/pcm_lib.c)
->snd_pcm_update_hw_ptr()
->snd_pcm_udpate_hw_ptr0()
->struct snd_pcm_ops.pointer()
(sound/firewire/*)
= Each handler on drivers in ALSA firewire stack
(sound/firewire/amdtp-stream.c)
->amdtp_stream_pcm_pointer()
(drivers/firewire/core-iso.c)
->fw_iso_context_flush_completions()
->struct fw_card_driver.flush_iso_completion()
(drivers/firewire/ohci.c)
= flush_iso_completions()
->struct fw_iso_context.callback.sc
(sound/firewire/amdtp-stream.c)
= in_stream_callback() or out_stream_callback()
->...
->snd_pcm_stream_unlock_irqWhen packet queueing error occurs or detecting invalid packets in
'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
is called on local CPU with disabled IRQ.(sound/firewire/amdtp-stream.c)
in_stream_callback() or out_stream_callback()
->amdtp_stream_pcm_abort()
->snd_pcm_stop_xrun()
->snd_pcm_stream_lock_irqsave()
->snd_pcm_stop()
->snd_pcm_stream_unlock_irqrestore()The process is stalled on the CPU due to attempt to acquire recursive lock.
[ 562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
[ 562.630861] 2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
[ 562.630862] (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
[ 562.630866] Task dump for CPU 2:
[ 562.630867] alsa-source-OXF R running task 0 6619 1 0x00000008
[ 562.630870] Call Trace:
[ 562.630876] ? vt_console_print+0x79/0x3e0
[ 562.630880] ? msg_print_text+0x9d/0x100
[ 562.630883] ? up+0x32/0x50
[ 562.630885] ? irq_work_queue+0x8d/0xa0
[ 562.630886] ? console_unlock+0x2b6/0x4b0
[ 562.630888] ? vprintk_emit+0x312/0x4a0
[ 562.630892] ? dev_vprintk_emit+0xbf/0x230
[ 562.630895] ? do_sys_poll+0x37a/0x550
[ 562.630897] ? dev_printk_emit+0x4e/0x70
[ 562.630900] ? __dev_printk+0x3c/0x80
[ 562.630903] ? _raw_spin_lock+0x20/0x30
[ 562.630909] ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
[ 562.630914] ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
[ 562.630918] ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
[ 562.630922] ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
[ 562.630925] ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
[ 562.630928] ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
[ 562.630932] ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
[ 562.630935] ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
[ 562.630938] ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
[ 562.630943] ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
[ 562.630945] ? poll_select_copy_remaining+0x150/0x150
[ 562.630947] ? poll_select_copy_remaining+0x150/0x150
[ 562.630952] ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
[ 562.630956] ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
[ 562.630960] ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
[ 562.630962] ? futex_wake+0x90/0x170
[ 562.630966] ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
[ 562.630970] ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
[ 562.630972] ? do_vfs_ioctl+0xa3/0x610
[ 562.630974] ? vfs_read+0x11b/0x130
[ 562.630976] ? SyS_ioctl+0x79/0x90
[ 562.630978] ? entry_SYSCALL_64_fastpath+0x1e/0xadThis commit fixes the above bug. This assumes two cases:
1. Any error is detected in software IRQ context of OHCI 1394 context.
In this case, PCM substream should be aborted in packet handler. On the
other hand, it should not be done in any process context. TO distinguish
these two context, use 'in_interrupt()' macro.
2. Any error is detect in process context of ALSA PCM application.
In this case, PCM substream should not be aborted in packet handler
because PCM substream lock is acquired. The task to abort PCM substream
should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
returned at 'struct snd_pcm_ops.pointer()'.Suggested-by: Clemens Ladisch
Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position")
Cc: # 4.9+
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
14 Jun, 2017
2 commits
-
The standard PCM chmap helper callbacks treat the NULL info->chmap as
a fatal error and spews the kernel warning with stack trace when
CONFIG_SND_DEBUG is on. This was OK, originally it was supposed to be
always static and non-NULL. But, as the recent addition of Intel LPE
audio driver shows, the chmap content may vary dynamically, and it can
be even NULL when disconnected. The user still sees the kernel
warning unnecessarily.For clearing such a confusion, this patch simply removes the
snd_BUG_ON() in each place, just returns an error without warning.Cc: # v4.11+
Signed-off-by: Takashi Iwai -
Coffelake is another Intel part, so need to add PCI ID for it.
Signed-off-by: Megha Dey
Signed-off-by: Subhransu S. Prusty
Acked-by: Vinod Koul
Cc:
Signed-off-by: Takashi Iwai
07 Jun, 2017
3 commits
-
snd_timer_user_tselect() reallocates the queue buffer dynamically, but
it forgot to reset its indices. Since the read may happen
concurrently with ioctl and snd_timer_user_tselect() allocates the
buffer via kmalloc(), this may lead to the leak of uninitialized
kernel-space data, as spotted via KMSAN:BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x143/0x1b0 lib/dump_stack.c:52
kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
copy_to_user ./arch/x86/include/asm/uaccess.h:725
snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
do_loop_readv_writev fs/read_write.c:716
__do_readv_writev+0x94c/0x1380 fs/read_write.c:864
do_readv_writev fs/read_write.c:894
vfs_readv fs/read_write.c:908
do_readv+0x52a/0x5d0 fs/read_write.c:934
SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
SyS_readv+0x87/0xb0 fs/read_write.c:1018This patch adds the missing reset of queue indices. Together with the
previous fix for the ioctl/read race, we cover the whole problem.Reported-by: Alexander Potapenko
Tested-by: Alexander Potapenko
Cc:
Signed-off-by: Takashi Iwai -
The read from ALSA timer device, the function snd_timer_user_tread(),
may access to an uninitialized struct snd_timer_user fields when the
read is concurrently performed while the ioctl like
snd_timer_user_tselect() is invoked. We have already fixed the races
among ioctls via a mutex, but we seem to have forgotten the race
between read vs ioctl.This patch simply applies (more exactly extends the already applied
range of) tu->ioctl_lock in snd_timer_user_tread() for closing the
race window.Reported-by: Alexander Potapenko
Tested-by: Alexander Potapenko
Cc:
Signed-off-by: Takashi Iwai -
…broonie/sound into for-linus
ASoC: Fixes for v4.12
This is the usual collection of device specific fixes, all accumilated
since the merge window, plus one fix from Takashi for a nasty use after
free bug that bit some things with deferred probe and an update to the
maintainer address for the former Wolfson parts.
06 Jun, 2017
2 commits
-
A disorder is found in some ALC269 quirk entries for ASUS (1043:xxxx),
which should have been sorted in PCI SSID order. Rearrange them, so
that I won't overlook the already existing entry like I did a couple
of times in the past...Signed-off-by: Takashi Iwai
-
The ASUS X705UD laptop requires the known fixup ALC256_FIXUP_ASUS_MIC
in order to fix headphone jack sensing and to enable use of the internal
microphone.Unfortunately jack sensing for the headset mic is still not working.
[rearranged the position to keep the PCI SSID order -- tiwai]
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
Signed-off-by: Takashi Iwai
01 Jun, 2017
1 commit
-
The previous commit [63691587f7b0: ALSA: hda - Apply dual-codec quirk
for MSI Z270-Gaming mobo] attempted to apply the existing dual-codec
quirk for a MSI mobo. But it turned out that this isn't applied
properly due to the MSI-vendor quirk before this entry. I overlooked
such two MSI entries just because they were put in the wrong position,
although we have a list ordered by PCI SSID numbers.This patch fixes it by rearranging the unordered entries.
Fixes: 63691587f7b0 ("ALSA: hda - Apply dual-codec quirk for MSI Z270-Gaming mobo")
Reported-by: Rudolf Schmidt
Signed-off-by: Takashi Iwai
31 May, 2017
3 commits
-
This is another attempt to work around the VLA used in
mixer_us16x08.c. Basically the temporary array is used individually
for two cases, and we can declare locally in each block, instead of
hackish max() usage.Signed-off-by: Takashi Iwai
-
A mixer element created in a quirk for Tascam US-16x08 contains a
typo: it should be "EQ MidLow Q" instead of "EQ MidQLow Q".Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195875
Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk")
Cc: # v4.11+
Signed-off-by: Takashi Iwai -
This reverts commit 89b593c30e83 ("ALSA: usb-audio: purge needless
variable length array"). The patch turned out to cause a severe
regression, triggering an Oops at snd_usb_ctl_msg(). It was overseen
that snd_usb_ctl_msg() writes back the response to the given buffer,
while the patch changed it to a read-only const buffer. (One should
always double-check when an extra pointer cast is present...)As a simple fix, just revert the affected commit. It was merely a
cleanup. Although it brings VLA again, it's clearer as a fix. We'll
address the VLA later in another patch.Fixes: 89b593c30e83 ("ALSA: usb-audio: purge needless variable length array")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195875
Cc: # v4.11+
Signed-off-by: Takashi Iwai
26 May, 2017
5 commits
-
…7213', 'asoc/fix/free' and 'asoc/fix/jack' into asoc-linus
-
commit 25165f79adc7 ("ASoC: rsnd: enable clock-frequency for both
44.1kHz/48kHz") supported both 44.1kHz/48kHz for AUDIO_CLKOUTx,
but it didn't care its parent clock name.
This patch fixes it.Signed-off-by: Kuninori Morimoto
Signed-off-by: Mark Brown
25 May, 2017
4 commits
-
Element size in the manifest should be updated for each token, so that the
loop can parse all the string elements in the manifest. This was not
happening when more than two string elements appear consecutively, as it is
not updated with correct string element size. Fixed with this patch.Signed-off-by: Shreyas NC
Signed-off-by: Subhransu S. Prusty
Acked-by: Vinod Koul
Signed-off-by: Mark Brown -
In SKL+ platforms, all IPC commands are serialised, i.e. the driver sends
a new IPC to DSP, only after receiving a reply from the firmware for the
current IPC.Hence it seems apparent that there is only a single modifier of the IPC RX
List. However, during an IPC timeout case in a multithreaded environment,
there is a possibility of the list element being deleted two times if not
properly protected.So, use spin lock save/restore to prevent rx_list corruption.
Signed-off-by: Pardha Saradhi K
Signed-off-by: Subhransu S. Prusty
Acked-by: Vinod Koul
Signed-off-by: Mark Brown -
commit 90431eb49bff ("ASoC: rsnd: don't use PDTA bit for 24bit on SSI")
fixups 24bit mode data alignment, but PIO was not cared.
This patch fixes PIO mode 24bit data alignmentSigned-off-by: Kuninori Morimoto
Signed-off-by: Mark Brown -
soc_cleanup_card_resources() call snd_card_free() at the last of its
procedure. This turned out to lead to a use-after-free.
PCM runtimes have been already removed via soc_remove_pcm_runtimes(),
while it's dereferenced later in soc_pcm_free() called via
snd_card_free().The fix is simple: just move the snd_card_free() call to the beginning
of the whole procedure. This also gives another benefit: it
guarantees that all operations have been shut down before actually
releasing the resources, which was racy until now.Reported-and-tested-by: Robert Jarzmik
Signed-off-by: Takashi Iwai
Signed-off-by: Mark Brown
Cc:
23 May, 2017
1 commit
-
This model is actually called 92XXM2-8 in Windows driver. But since pin
configs for M22 and M28 are identical, just reuse M22 quirk.Fixes external microphone (tested) and probably docking station ports
(not tested).Signed-off-by: Alexander Tsoy
Cc:
Signed-off-by: Takashi Iwai
22 May, 2017
2 commits
-
Recently some laptops and mobos are equipped with the dual Realtek
codecs that require special quirks. For making the debugging easier,
add the model "dual-codecs" to be passed via module option.Signed-off-by: Takashi Iwai
-
MSI Z270-Gamin mobo has also two ALC1220 codecs like Gigabyte AZ370-
Gaming mobo. Apply the same quirk to this one.Signed-off-by: Takashi Iwai
20 May, 2017
2 commits
-
Initialize asoc_simple_card_init_mic with the correct struct
asoc_simple_jack.Fixes: 9eac361877b3 ("ASoC: simple-card: add new asoc_simple_jack and use it")
Signed-off-by: Stefan Agner
Acked-by: Kuninori Morimoto
Signed-off-by: Mark Brown -
If SSI uses shared pin, some SSI will be used as parent SSI.
Then, normal SSI's remove and Parent SSI's remove
(these are same SSI) will be called when unbind or remove timing.
In this case, free_irq() will be called twice.
This patch solve this issue.Signed-off-by: Kuninori Morimoto
Tested-by: Hiroyuki Yokoyama
Reported-by: Hiroyuki Yokoyama
Signed-off-by: Mark Brown
17 May, 2017
2 commits
-
The PM functions used in this driver are the ones defined in
sounc/soc/soc-core.c.When suspending (using snd_soc_suspend), the regcache is marked dirty
but is never synced on resume.Sync regcache on resume of Atmel ClassD device.
Signed-off-by: Quentin Schulz
Acked-by: Alexandre Belloni
Acked-by: Nicolas Ferre
Signed-off-by: Mark Brown -
Current SSI uses PDTA bit which indicates data that Input/Output
data are Right-Aligned. But, 24bit sound should be Left-Aligned
in this HW. Because Linux is using Right-Aligned data, and HW uses
Left-Aligned data, current 24bit data is missing lower 8bit.
To fix this issue, this patch removes PDTA bit, and shift 8bit
in necessary moduleReported-by: Hiroyuki Yokoyama
Signed-off-by: Kuninori Morimoto
Tested-by: Hiroyuki Yokoyama
Signed-off-by: Mark Brown
16 May, 2017
1 commit
-
ALC299 has no loopback mixer, but the driver still tries to add a beep
control over the mixer NID which leads to the error at accessing it.
This patch fixes it by properly declaring mixer_nid=0 for this codec.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195775
Fixes: 28f1f9b26cee ("ALSA: hda/realtek - Add new codec ID ALC299")
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai
15 May, 2017
2 commits
-
Not calling pm_runtime_enable() means that runtime PM can't be
enabled at all via sysfs. So we definitely need to call it
from somewhere.Calling it from the driver seems like a bad idea because it
would have to be paired with a pm_runtime_disable() at driver
unload time, otherwise the core gets upset. Also if there's
no LPE audio driver loaded then we couldn't runtime suspend
i915 either.So it looks like a better plan is to call it from i915 when
we register the platform device. That seems to match how
pci generally does things. I cargo culted the
pm_runtime_forbid() and pm_runtime_set_active() calls from
pci as well.The exposed runtime PM API is massive an thorougly misleading, so
I don't actually know if this is how you're supposed to use the API
or not. But it seems to work. I can now runtime suspend i915 again
with or without the LPE audio driver loaded, and reloading the
LPE audio driver also seems to work.Note that powertop won't auto-tune runtime PM for platform devices,
which is a little annoying. So I'm not sure that leaving runtime
PM in "on" mode by default is the best choice here. But I've left
it like that for now at least.Also remove the comment about there not being much benefit from
LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
PM, which will also block s0ix, and that could have a measurable
impact on power consumption.Cc: stable@vger.kernel.org
Cc: Takashi Iwai
Cc: Pierre-Louis Bossart
Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default")
Signed-off-by: Ville Syrjälä
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-2-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai
(cherry picked from commit 183c00350ccda86781f6695840e6c5f5b22efbd1)
Signed-off-by: Jani Nikula -
Add missing endianness conversion when using the USB device-descriptor
bcdDevice field when applying the Amanero Combo384 (endianness!) quirk.Fixes: 3eff682d765b ("ALSA: usb-audio: Support both DSD LE/BE Amanero firmware versions")
Cc: Jussi Laako
Signed-off-by: Johan Hovold
Signed-off-by: Takashi Iwai
14 May, 2017
3 commits
-
In the SRM lock check section of code the '&' bitwise operator is
used as part of checking lock status. Functionally the code works
as intended, but the conditional statement is a boolean comparison
so should really use '&&' logical operator instead. This commit
rectifies this discrepancy.Signed-off-by: Adam Thomson
Signed-off-by: Mark Brown -
Thinkpad Helix 2 is a tablet PC, the audio is powered by Core M
broadwell-audio and rt286 codec. For all versions of Linux kernel,
the stereo output doesn't work properly when earphones are plugged
in, the sound was coming out from both channels even if the audio
contains only the left or right channel. Furthermore, if a music
recorded in stereo is played, the two channels cancle out each other
out, as a result, no voice but only distorted background music can be
heard, like a sound card with builtin a Karaoke sount effect.Apparently this tablet uses a combo jack with polarity incorrectly
set by rt286 driver. This patch adds DMI information of Thinkpad Helix 2
to force_combo_jack_table[] and the issue is resolved. The microphone
input doesn't work regardless to the presence of this patch and still
needs help from other developers to investigate.This is my first patch to LKML directly, sorry for CC-ing too many
people here.Link: https://bugzilla.kernel.org/show_bug.cgi?id=93841
Signed-off-by: Yifeng Li
Signed-off-by: Mark Brown -
The i915 component framework expects the caller to be invoking
snd_hdac_i915_init() from a thread context. Otherwise it results in
lockups on drm side.So move the registering of component interface and probing of codecs on
this bus to a worker thread.init_failed in skl structure is not used currently, so renamed to
init_done and used to track the initialization done in worker thread.Reported-by: Imre Deak
Signed-off-by: Vinod Koul
Signed-off-by: Sodhi, VunnyX
Signed-off-by: Subhransu S. Prusty
Signed-off-by: Mark Brown
13 May, 2017
1 commit
-
Pull sound fixes from Takashi Iwai:
"This contains a one-liner change that has a significant impact:
disabling the build of OSS. It's been unmaintained for long time, and
we'd like to drop the stuff. Finally, as the first step, stop the
build. Let's see whether it works without much complaints.Other than that, there are two small fixes for HD-audio"
* tag 'sound-fix-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
sound: Disable the build of OSS drivers
ALSA: hda: Fix cpu lockup when stopping the cmd dmas
ALSA: hda - Add mute led support for HP EliteBook 840 G3
12 May, 2017
1 commit
-
OSS drivers are left as badly unmaintained, and now we're facing a
problem to clean up the hackish set_fs() usage in their codes. Since
most of drivers have been covered by ALSA, and the others are dead old
and inactive, let's leave them RIP.This patch is the first step: disable the build of OSS drivers.
We'll eventually drop the whole codes and clean up later.Note that sound/oss/dmasound is still kept, since it's a completely
different implementation of OSS, and it doesn't suffer from set_fs()
hack. Moreover, the build of ALSA is disabled on M68K by some reason,
thus disabling it shall result in a regression. This one will be
disabled / removed once when we add the support in ALSA side.Tested-by: Randy Dunlap
Signed-off-by: Takashi Iwai
11 May, 2017
1 commit
-
Pull hw lockdown support from David Howells:
"Annotation of module parameters that configure hardware resources
including ioports, iomem addresses, irq lines and dma channels.This allows a future patch to prohibit the use of such module
parameters to prevent that hardware from being abused to gain access
to the running kernel image as part of locking the kernel down under
UEFI secure boot conditions.Annotations are made by changing:
module_param(n, t, p)
module_param_named(n, v, t, p)
module_param_array(n, t, m, p)to:
module_param_hw(n, t, hwtype, p)
module_param_hw_named(n, v, t, hwtype, p)
module_param_hw_array(n, t, hwtype, m, p)where the module parameter refers to a hardware setting
hwtype specifies the type of the resource being configured. This can
be one of:ioport Module parameter configures an I/O port
iomem Module parameter configures an I/O mem address
ioport_or_iomem Module parameter could be either (runtime set)
irq Module parameter configures an I/O port
dma Module parameter configures a DMA channel
dma_addr Module parameter configures a DMA buffer address
other Module parameter configures some other valueNote that the hwtype is compile checked, but not currently stored (the
lockdown code probably won't require it). It is, however, there for
future use.A bonus is that the hwtype can also be used for grepping.
The intention is for the kernel to ignore or reject attempts to set
annotated module parameters if lockdown is enabled. This applies to
options passed on the boot command line, passed to insmod/modprobe or
direct twiddling in /sys/module/ parameter files.The module initialisation then needs to handle the parameter not being
set, by (1) giving an error, (2) probing for a value or (3) using a
reasonable default.What I can't do is just reject a module out of hand because it may
take a hardware setting in the module parameters. Some important
modules, some ipmi stuff for instance, both probe for hardware and
allow hardware to be manually specified; if the driver is aborts with
any error, you don't get any ipmi hardware.Further, trying to do this entirely in the module initialisation code
doesn't protect against sysfs twiddling.[!] Note that in and of itself, this series of patches should have no
effect on the the size of the kernel or code execution - that is
left to a patch in the next series to effect. It does mark
annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in
an already existing field"* tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits)
Annotate hardware config module parameters in sound/pci/
Annotate hardware config module parameters in sound/oss/
Annotate hardware config module parameters in sound/isa/
Annotate hardware config module parameters in sound/drivers/
Annotate hardware config module parameters in fs/pstore/
Annotate hardware config module parameters in drivers/watchdog/
Annotate hardware config module parameters in drivers/video/
Annotate hardware config module parameters in drivers/tty/
Annotate hardware config module parameters in drivers/staging/vme/
Annotate hardware config module parameters in drivers/staging/speakup/
Annotate hardware config module parameters in drivers/staging/media/
Annotate hardware config module parameters in drivers/scsi/
Annotate hardware config module parameters in drivers/pcmcia/
Annotate hardware config module parameters in drivers/pci/hotplug/
Annotate hardware config module parameters in drivers/parport/
Annotate hardware config module parameters in drivers/net/wireless/
Annotate hardware config module parameters in drivers/net/wan/
Annotate hardware config module parameters in drivers/net/irda/
Annotate hardware config module parameters in drivers/net/hamradio/
Annotate hardware config module parameters in drivers/net/ethernet/
...
10 May, 2017
1 commit
-
Using jiffies in hdac_wait_for_cmd_dmas() to determine when to time out
when interrupts are off (snd_hdac_bus_stop_cmd_io()/spin_lock_irq())
causes hard lockup so unlock while waiting using jiffies.------
[ 1211.603046] NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
[ 1211.603047] Modules linked in: snd_hda_intel i915 vgem
[ 1211.603053] irq event stamp: 13366
[ 1211.603053] hardirqs last enabled at (13365):
...
[ 1211.603059] Call Trace:
[ 1211.603059] ? delay_tsc+0x3d/0xc0
[ 1211.603059] __delay+0xa/0x10
[ 1211.603060] __const_udelay+0x31/0x40
[ 1211.603060] snd_hdac_bus_stop_cmd_io+0x96/0xe0 [snd_hda_core]
[ 1211.603060] ? azx_dev_disconnect+0x20/0x20 [snd_hda_intel]
[ 1211.603061] snd_hdac_bus_stop_chip+0xb1/0x100 [snd_hda_core]
[ 1211.603061] azx_stop_chip+0x9/0x10 [snd_hda_codec]
[ 1211.603061] azx_suspend+0x72/0x220 [snd_hda_intel]
[ 1211.603061] pci_pm_suspend+0x71/0x140
[ 1211.603062] dpm_run_callback+0x6f/0x330
[ 1211.603062] ? pci_pm_freeze+0xe0/0xe0
[ 1211.603062] __device_suspend+0xf9/0x370
[ 1211.603062] ? dpm_watchdog_set+0x60/0x60
[ 1211.603063] async_suspend+0x1a/0x90
[ 1211.603063] async_run_entry_fn+0x34/0x160
[ 1211.603063] process_one_work+0x1f4/0x6d0
[ 1211.603063] ? process_one_work+0x16e/0x6d0
[ 1211.603064] worker_thread+0x49/0x4a0
[ 1211.603064] kthread+0x107/0x140
[ 1211.603064] ? process_one_work+0x6d0/0x6d0
[ 1211.603065] ? kthread_create_on_node+0x40/0x40
[ 1211.603065] ret_from_fork+0x2e/0x40Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100419
Fixes: 38b19ed7f81ec ("ALSA: hda: fix to wait for RIRB & CORB DMA to set")
Reported-by: Marta Lofstedt
Suggested-by: Takashi Iwai
Signed-off-by: Jeeja KP
Acked-by: Vinod Koul
CC: stable # 4.7
Signed-off-by: Takashi Iwai
09 May, 2017
1 commit
-
set_memory_* functions have moved to set_memory.h. Switch to this
explicitly.Link: http://lkml.kernel.org/r/1488920133-27229-14-git-send-email-labbott@redhat.com
Signed-off-by: Laura Abbott
Acked-by: Takashi Iwai
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
