When the ASoC card registration fails and the codec component driver
never probes, the codec device is not initialized and therefore
memory for codec->wcaps is not allocated. This results in a NULL pointer
dereference when the codec driver suspend callback is invoked during
system suspend. Fix this by returning without performing any actions
during codec suspend/resume if the card was not registered successfully.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200728231011.1454066-1-ranjani.sridharan@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It's been reported that, when neither nouveau nor Nvidia graphics
driver is used, the screen starts flickering. And, after comparing
between the working case (stable 4.4.x) and the broken case, it turned
out that the problem comes from the audio component binding. The
Nvidia and AMD audio binding code clears the bus->keep_power flag
whenever snd_hdac_acomp_init() succeeds. But this doesn't mean that
the component is actually bound, but it merely indicates that it's
ready for binding. So, when both nouveau and Nvidia are blacklisted
or not ready, the driver keeps running without the audio component but
also with bus->keep_power = false. This made the driver runtime PM
kicked in and powering down when unused, which results in flickering
in the graphics side, as it seems.
For fixing the bug, this patch moves the bus->keep_power flag change
into generic_acomp_notifier_set() that is the function called from the
master_bind callback of component ops; i.e. it's guaranteed that the
binding succeeded.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208609
Fixes: 5a858e79c9 ("ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200728082033.23933-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We've received a regression report on Intel HD-audio controller that
wakes up immediately after S3 suspend. The bisection leads to the
commit c4c8dd6ef8 ("ALSA: hda: Skip controller resume if not
needed"). This commit replaces the system-suspend to use
pm_runtime_force_suspend() instead of the direct call of
__azx_runtime_suspend(). However, by some really mysterious reason,
pm_runtime_force_suspend() causes a spurious wakeup (although it calls
the same __azx_runtime_suspend() internally).
As an ugly workaround for now, revert the behavior to call
__azx_runtime_suspend() and __azx_runtime_resume() for those old Intel
platforms that may exhibit such a problem, while keeping the new
standard pm_runtime_force_suspend() and pm_runtime_force_resume()
pair for the remaining chips.
Fixes: c4c8dd6ef8 ("ALSA: hda: Skip controller resume if not needed")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208649
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200727164443.4233-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Follow the recent inclusive terminology guidelines and replace the
word "slave" in vmaster API. I chose the word "follower" at this time
since it seems fitting for the purpose.
Note that the word "master" is kept in API, since it refers rather to
audio master volume control.
Also, while we're at it, a typo in comments is corrected, too.
Link: https://lore.kernel.org/r/20200717154517.27599-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Link: https://lore.kernel.org/r/20200719151705.59624-1-grandmaster@al2klimov.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ASoC: Fixes for v5.8
An awful lot of mostly small fixes here, mainly for x86 based platforms
and the CODEC drivers mainly used on them. For the most part this is
either minor device specific stuff which seems to come from detailed
testing or robustness against errors which comes from people having done
some fuzzing runs aginst the topology code.
snd_info_get_line() has a sanity check of NULL buffer -- both buffer
itself being NULL and buffer->buffer being NULL. Basically both
checks are valid and necessary, but the problem is that it's with
snd_BUG_ON() macro that triggers WARN_ON(). The latter condition
(NULL buffer->buffer) can be met arbitrarily by user since the buffer
is allocated at the first write, so it means that user can trigger
WARN_ON() at will.
This patch addresses it by simply moving buffer->buffer NULL check out
of snd_BUG_ON() so that spurious WARNING is no longer triggered.
Reported-by: syzbot+e42d0746c3c3699b6061@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200717084023.5928-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 3ad796cbc3 ("ALSA: pcm: Use SG-buffer only when
direct DMA is available") also the modification commit 467fd0e82b
("ALSA: pcm: Fix build error on m68k and others").
Poking the DMA internal helper is a layer violation, so we should
avoid that. Meanwhile the actual bug has been addressed by the
Kconfig fix in commit dbed452a07 ("dma-pool: decouple DMA_REMAP from
DMA_COHERENT_POOL"), so we can live without this hack.
Link: https://lore.kernel.org/r/20200717064130.22957-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Follow the recent inclusive terminology guidelines and replace the
words "whitelist" and "blacklist" appropriately.
Correcting only comments, or error/module messages, no functional
changes.
Link: https://lore.kernel.org/r/20200714172631.25371-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Follow the recent inclusive terminology guidelines and replace the
words "whitelist" and "blacklist" appropriately.
Only comment or variable renames, no functional changes.
Note that pm_blacklist module option is still kept as was, so that
users can still keep the old option.
Link: https://lore.kernel.org/r/20200714172631.25371-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit f34a4c9dd4 ("ALSA: hda: Enable sync-write operation as default
for all controllers") enabled sync-write for all controllers and this is
causing audio playback on the Tegra186 HDA device to fail. For now,
disable sync-write support for Tegra to fix this.
Fixes: f34a4c9dd4 ("ALSA: hda: Enable sync-write operation as default for all controllers")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20200714160841.2293-1-jonathanh@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
USB MIDI driver has an error recovery mechanism to resubmit the URB in
the delayed timer handler, and this may race with the standard start /
stop operations. Although both start and stop operations themselves
don't race with each other due to the umidi->mutex protection, but
this isn't applied to the timer handler.
For fixing this potential race, the following changes are applied:
- Since the timer handler can't use the mutex, we apply the
umidi->disc_lock protection at each input stream URB submission;
this also needs to change the GFP flag to GFP_ATOMIC
- Add a check of the URB refcount and skip if already submitted
- Move the timer cancel call at disconnection to the beginning of the
procedure; this assures the in-flight timer handler is gone properly
before killing all pending URBs
Reported-by: syzbot+0f4ecfe6a2c322c81728@syzkaller.appspotmail.com
Reported-by: syzbot+5f1d24c49c1d2c427497@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200710160656.16819-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
