The device reports Synch: Synchronous on the playback interface.
This causes regular audible napping on sample rates that are not multiples
of 1 kHz. Fix to Synch: Asynchronous.

Specifically observed on Focusrite Scarlett Solo 2nd generation. I assume
the first generation model has a different device ID. A first generation
Scarlett 2i2 I was able to test advertised Synch: Asynchronous by default.

For example, with a sample rate of 44100 Hz, a silent sample is played
every 40.96 seconds (likely 44.0 samples instead of 44.1 transmitted per
USB frame on average, 4096 being the size of some internal buffer).
There may be some other bug at play here since this doesn't happen
on other platforms. However, a feedback endpoint is listed and using it
fixes the issue. That is the only change in the quirk,
but I didn't find a way to declare only it.

Tested on two units and on two different computers.
Signed-off-by: Roope Salmi <rpsalmi@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Some fields in snd_hdac_bus are ext-bus specific, but they still
should be initialized in snd_hdac_bus_init() for consistency, at
least, for the ones that do need the explicit initialization like the
list head.

Also move the lock field to the more appropriate place and correct the
comment to reflect the recent change where it serves for both the
display power and the link management.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Back-merge the 5.1 devel branch for the further HD-audio development.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The recent commit 98081ca6 ("ALSA: hda - Record the current power
state before suspend/resume calls") made the HD-audio driver to store
the PM state in power_state field.  This forgot, however, the
initialization at power up.  Although the codec drivers usually don't
need to refer to this field in the normal operation, let's initialize
it properly for consistency.

Fixes: 98081ca6 ("ALSA: hda - Record the current power state before suspend/resume calls")
Signed-off-by: Takashi Iwai <tiwai@suse.de>

OSS sequencer emulation still allows to queue and issue the events
that manipulate the client pool concurrently in a racy way.  This
patch serializes the access like the normal sequencer write / ioctl
via taking the client ioctl_mutex.  Since the access to the sequencer
client is done indirectly via a client id number, a new helper to
take/release the mutex is introduced.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

We have two helpers for queuing a sequencer event from the kernel
client, and both are used only from OSS sequencer layer without any
hop and atomic set.  Let's simplify and unify two helpers into one.

No functional change, just a call pattern change.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The call of unsubscribe_port() which manages the group count and
module refcount from delete_and_unsubscribe_port() looks racy; it's
not covered by the group list lock, and it's likely a cause of the
reported unbalance at port deletion.  Let's move the call inside the
group list_mutex to plug the hole.

Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This reverts commit feb68902.

The fix attempt was incorrect, leading to the mutex deadlock through
the close of OSS sequencer client.  The proper fix needs more
consideration, so let's revert it now.

Fixes: feb68902 ("ALSA: seq: Protect in-kernel ioctl calls with mutex")
Reported-by: syzbot+47ded6c0f23016cde310@syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge tag 'asoc-fix-v5.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v5.1

A few core fixes along with the driver specific ones, mainly fixing
small issues that only affect x86 platforms for various reasons (their
unusual machine enumeration mechanisms mainly, plus a fix for error
handling in topology).

There's some of the driver fixes that look larger than they are, like
the hdmi-codec changes which resulted in an indentation change, and most
of the other large changes are for new drivers like the STM32 changes.

wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip'
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>

snd_hdac_display_power() doesn't handle the concurrent calls carefully
enough, and it may lead to the doubly get_power or put_power calls,
when a runtime PM and an async work get called in racy way.

This patch addresses it by reusing the bus->lock mutex that has been
used for protecting the link state change in ext bus code, so that it
can protect against racy display state changes.  The initialization of
bus->lock was moved from snd_hdac_ext_bus_init() to
snd_hdac_bus_init() as well accordingly.

Testcase: igt/i915_pm_rpm/module-reload #glk-dsi
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Handle error before returning when try_module_get() fails
to prevent inconsistent mutex lock/unlock.

Fixes: 52034add (ASoC: pcm: update module refcount if
		  module_get_upon_open is set)
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

When master clock is used, master clock rate is set exclusively.
Parent clocks of master clock cannot be changed after a call to
clk_set_rate_exclusive(). So the parent clock of SAI kernel clock
must be set before.
Ensure also that exclusive rate operations are balanced
in STM32 SAI driver.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Fix wrong setting on number of channels.  The context wants to set
constraint to 2 channels instead of 4.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Avoid old school C style but do plain and clear way.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Just a minor refactoring to use the standard goto for error paths in
snd_timer_open() instead of open code.  The first mutex_lock() is
moved to the beginning of the function to make the code clearer.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The snd_seq_ioctl_get_subscription() retrieves the port subscriber
information as a pointer, while the object isn't protected, hence it
may be deleted before the actual reference.  This race was spotted by
syzkaller and may lead to a UAF.

The fix is simply copying the data in the lookup function that
performs in the rwsem to protect against the deletion.

Reported-by: syzbot+9437020c82413d00222d@syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA OSS sequencer calls the ioctl function indirectly via
snd_seq_kernel_client_ctl().  While we already applied the protection
against races between the normal ioctls and writes via the client's
ioctl_mutex, this code path was left untouched.  And this seems to be
the cause of still remaining some rare UAF as spontaneously triggered
by syzkaller.

For the sake of robustness, wrap the ioctl_mutex also for the call via
snd_seq_kernel_client_ctl(), too.

Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

spin_lock_irqsave() is used unnecessarily in various places in
sequencer core code although it's pretty obvious that the context is
sleepable.  Remove irqsave and use the plain spin_lock_irq() in such
places for simplicity.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

In a few places in sequencer core, we temporarily unlock / re-lock the
pool spin lock while waiting for the allocation in the blocking mode.
There spin_unlock_irq() / spin_lock_irq() pairs are called while
initially spin_lock_irqsave() is used (and spin_lock_irqrestore() at
the end of the function again).  This is likely OK for now, but it's a
bit confusing and error-prone.

This patch replaces these temporary relocking lines with the irqsave
variant to make the lock/unlock sequence more consistently.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Use kvmalloc() for allocating cell pools since the pool size can be
relatively small that may be covered better by slab.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This is essentially a revert of the commit a7588c89 ("ALSA: timer:
Check ack_list emptiness instead of bit flag").  The intended change
by the commit turns out to be insufficient, as snd_timer_close*()
always calls snd_timer_stop() that deletes the ack_list beforehand.

In theory, we can change the behavior of snd_timer_stop() to sync the
pending ack_list, but this will become a deadlock for the callback
like sequencer that calls again snd_timer_stop() from itself.  So,
reverting the change is a more straightforward solution.

Fixes: a7588c89 ("ALSA: timer: Check ack_list emptiness instead of bit flag")
Reported-by: syzbot+58813d77154713f4de15@syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Recently we set CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 1 when
configuring the kernel, then two machines were reported to have noise
after installing the new kernel. Put them in the blacklist, the
noise disappears.

https://bugs.launchpad.net/bugs/1821663
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Setting the module_get_upon_open field for component driver
prevents the module refcount from being incremented during
component probe(). This could lead to the module being
allowed to be unloaded when a pcm stream is open. So,
if this field is set, the module's refcount should be
incremented during pcm open to prevent module removal
when the component is in use. And, the refcount should
be decremented upon pcm close.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Recently, for Intel platforms the "ignore_module_refcount" field
was introduced for the component driver. In order to avoid a
deadlock preventing the PCI modules from being removed
even when the card was idle, the refcounts were not incremented
for the device driver module during component probe.

However, this change introduced a nasty side effect:
the device driver module can be unloaded while a pcm stream is open.

This patch proposes to change the field to be renamed as
"module_get_upon_open". When this field is set, the module
refcount should be incremented on pcm open amd decremented
upon pcm close. This will enable modules to be removed
when no PCM playback/capture happens and prevent removal
when the component is actually in use.

Also, align with the skylake component driver with the new name.

Fixes: b450b878('ASoC: core: don't increase component module refcount
                 unconditionally'
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

This patch fixes the sai driver structure overwriting which results in
a cpu dai name equal NULL.

Fixes: 3e086edf ("ASoC: stm32: add SAI driver")
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

The control values and texts of the enum kcontrol associated
with a widget need to be freed when the widget is removed.
However, both struct snd_soc_dapm_widget and struct soc_enum
contain a dobj member, which resulted in a confusion.
The existing code generates a null pointer dereference by
attempting to free the values and texts from the dobj which
belongs to the widget instead of the dobj belonging to the
enum kcontrol.

The suggested fix is to use the correct dobj member (se->dobj)
of the enum kcontrol.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

When ioctl calls are made with non-null-terminated userspace strings,
strlcpy causes an OOB-read from within strlen. Fix by changing to use
strscpy instead.
Signed-off-by: Zubin Mithra <zsm@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Topology is not unloaded in the core during unregister_component()
anymore. So, add the remove() callback that will unload the
topology.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

The chips main power supplies VA and VP are enabled during probe but
then never disabled, this will cause warnings from the regulator
framework on driver removal. Fix this by adding a remove callback and
disabling the supplies, whilst doing so follow best practice and put the
chip back into reset as well.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

This fixes the regression introduced while moving to Xen shared
buffer implementation.

Fixes: 58f9d806 ("ALSA: xen-front: Use Xen common shared buffer implementation")
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch decreases the transfer bursts to avoid the fifo overrun.
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

This is because set_fmt ops maybe called when PD is off,
and in such case, regmap_ops will lead system hang.
enale PD before doing regmap_ops.
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

commit da215354 ("ASoC: simple-card: merge simple-scu-card")
merged simple-scu-audio-card which can handle DPCM into
simple-audio-card.

By this patch, the judgement to select "normal sound card" or
"DPCM sound card" is based on its CPU/Codec DAI count.
But, because of it, existing "simple-audio-card" user who is
assuming "normal sound card" might select DPCM unintentionally.

To solve this issue, this patch allows "simple-audio-card" user
can select "normal sound card", and "simple-scu-audio-card" user
can select both "normal sound card" and "DPCM sound card".
This keeps compatibility collectry.

Fixes: da215354 ("ASoC: simple-card: merge simple-scu-card")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

commit ae3cb579 ("ASoC: audio-graph-card: merge
audio-graph-scu-card") merged audio-graph-scu-card which can
handle DPCM into audio-graph-card.

By this patch, the judgement to select "normal sound card" or
"DPCM sound card" is based on its OF-graph endpoint connection.
But, because of it, existing "audio-graph-card" user who is
assuming "normal sound card" might select DPCM unintentionally.

To solve this issue, this patch allows "audio-graph-card" user
can select "normal sound card", and "audio-graph-scu-card" user
can select both "normal sound card" and "DPCM sound card".
This keeps compatibility collectry.

Fixes: ae3cb579 ("ASoC: audio-graph-card: merge audio-graph-scu-card")
Reported-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

The author of these files has changed her name.  Update
instances in the code of her dead name to current legal
name.
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net>
Signed-off-by: Mark Brown <broonie@kernel.org>

chip->ioport is dereferenced in two places, but the struct is
defined as follows:

struct mychip {
	struct snd_card *card;
	struct pci_dev *pci;

	unsigned long port;
	int irq;
};
Signed-off-by: Christina Quast <cquast@hanoverdisplays.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This adds a SND_PCI_QUIRK(...) line for the Tuxedo XC 1509.

The Tuxedo XC 1509 and the System76 oryp5 are the same barebone
notebooks manufactured by Clevo. To name the fixups both use after the
actual underlying hardware, this patch also changes System76_orpy5
to clevo_pb51ed in 2 enum symbols and one function name,
matching the other pci_quirk entries which are also named after the
device ODM.

Fixes: 7f665b1c ("ALSA: hda/realtek - Headset microphone and internal speaker support for System76 oryp5")
Signed-off-by: Richard Sailer <rs@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

It will be lose Mic JD state when Chrome OS boot and headset was plugged.
Just Implement of reset combo jack JD verb for ACT_PRE_PROBE state.
Intel test result was also failed.
It test passed until changed the initial state to ACT_INIT.
Mic JD will show every time.
This patch also changed the model name as 'alc-chrome-book' for
application of Chrome OS.

Fixes: 10f5b1b8 ("ALSA: hda/realtek - Fixed Headset Mic JD not stable")
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Users have been seeing sound stability issues with max98090 codecs since:
commit 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")

At first that commit broke sound for Chromebook Swanky and Clapper models,
the problem was that the machine-driver has been controlling the wrong
clock on those models since support for them was added. This was hidden by
clk-pmc-atom.c keeping the actual clk on unconditionally.

With the machine-driver controlling the proper clock, sound works again
but we are seeing bug reports describing it as: low volume,
"sounds like played at 10x speed" and instable.

When these issues are hit the following message is seen in dmesg:
"max98090 i2c-193C9890:00: PLL unlocked".

Attempts have been made to fix this by inserting a delay between enabling
the clk and enabling and checking the pll, but this has not helped.

It seems that at least on boards which use pmc_plt_clk_0 as clock,
if we ever disable the clk, the pll looses its lock and after that we get
various issues.

This commit fixes this by enabling the clock once at probe time on
these boards. In essence this restores the old behavior of clk-pmc-atom.c
always keeping the clk on on these boards.

Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Reported-by: Mogens Jensen <mogens-jensen@protonmail.com>
Reported-by: Dean Wallace <duffydack73@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>