summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/memfd
diff options
context:
space:
mode:
authorTakashi Iwai <tiwai@suse.de>2016-03-04 10:34:18 (GMT)
committerTakashi Iwai <tiwai@suse.de>2016-03-08 09:49:02 (GMT)
commitfc4f000bf8c0cbf38f44de6bd5e225574e572ed4 (patch)
tree6480aa634336dc49772122bd2bc1a2555da6a0bb /tools/testing/selftests/memfd
parentad09ef2cce91e3a98a32e3bb0a5982a6e8920aa1 (diff)
downloadlinux-fc4f000bf8c0cbf38f44de6bd5e225574e572ed4.tar.xz
ALSA: hda - Fix unexpected resume through regmap code path
HD-audio driver has a mechanism to trigger the runtime resume automatically at accessing the verbs. This auto-resume, however, causes the mutex deadlock when invoked from the regmap handler since the regmap keeps the mutex while auto-resuming. For avoiding that, there is some tricky check in the HDA regmap handler to return -EAGAIN error to back-off when the codec is powered down. Then the caller of regmap r/w will retry after properly turning on the codec power. This works in most cases, but there seems a slight race between the codec power check and the actual on-demand auto-resume trigger. This resulted in the lockdep splat, eventually leading to a real deadlock. This patch tries to address the race window by getting the runtime PM refcount at the check time using pm_runtime_get_if_in_use(). With this call, we can keep the power on only when the codec has been already turned on, and back off if not. For keeping the code consistency, the code touching the runtime PM is stored in hdac_device.c although it's used only locally in hdac_regmap.c. Reported-by: Jiri Slaby <jslaby@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'tools/testing/selftests/memfd')
0 files changed, 0 insertions, 0 deletions