Merge branch 'for-next' into for-linus

Merge 5.16-devel branch for upstreaming

Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: remove TODO for interaction with userspace about control message

Now UAPI of ALSA firewire stack got enough functions to interact with
userspace for protocol of MOTU FireWire series. Let's remove the relevant
TODO.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211029012847.11839-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: oxfw: fix functional regression for Mackie Onyx 1640i in v5.14 or later

A user reports functional regression for Mackie Onyx 1640i that the device
generates slow sound with ALSA oxfw driver which supports media clock
recovery. Although the device is based on OXFW971 ASIC, it does not
transfer isochronous packet with own event frequency as expected. The
device seems to adjust event frequency according to events in received
isochronous packets in the beginning of packet streaming. This is
unknown quirk.

This commit fixes the regression to turn the recovery off in driver
side. As a result, nominal frequency is used in duplex packet streaming
between device and driver. For stability of sampling rate in events of
transferred isochronous packet, 4,000 isochronous packets are skipped
in the beginning of packet streaming.

Reference: https://github.com/takaswie/snd-firewire-improve/issues/38
Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211028130325.45772-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: export meter information to userspace as float value

In command DSP models, one meter information consists of 4 bytes for
IEEE 764 floating point (binary32). In previous patch, it is exported
to userspace as 32 bit storage since the storage is also handled in
ALSA firewire-motu driver as well in kernel space in which floating point
arithmetic is not preferable. On the other hand, ALSA firewire-motu driver
doesn't perform floating point calculation. The driver just gather meter
information from isochronous packets and fill structure fields for
userspace.

In 'header' target of Kbuild, UAPI headers are processed before installed.
In this timing, #ifdef macro with __KERNEL__ is removed. This mechanism
is useful in the case so that the 32 bit storage can be accessible as u32
type in kernel space and float type in user space. We can see the same
usage in ''struct acct_v3' in 'include/uapi/linux/acct.h'.

This commit is for the above idea. Additionally, due to message
protocol, meter information is filled with 0xffffffff in the end of
period but 0xffffffff is invalid as binary32. To avoid confusion in
userspace application, the last two elements are left without any
assignment.

Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211027125529.54295-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: refine parser for meter information in register DSP models

After further investigation, I realize that the total number of elements
in array is not enough to store all of related messages from device.
This commit refines meter array and message parser.

In terms of channel identifier, register DSP models are classified to
two categories:

1. the target of output is selectable

828mk2, 896hd, and Traveler are in the category. They transfer messages
with channel identifier between 0x00 and 0x13 for input meters,
therefore 20 elements are needed to store.

On the other hand, they transfer messages with channel identifier for one
pair of output meters. The selection is done by asynchronous write
transaction to offset 0x'ffff'f000'0b2c. The table for relationship
between written value and available identifiers is below:

=============  ===============
written value  identifier pair
=============  ===============
0x00000b00     0x80/0x81
0x00000b01     0x82/0x83
...            ...
0x00000b0b     0x96/0x97
...            ...
0x00000b10     0xa0/0xa1
...            ...
0x00000b3f     0xfe/0xff
...            ...
greater        0xfe/0xff
=============  ===============

Actually in the above three models, 0x96/0x97 pair is the maximum. Thus
the number of available output meter is 24.

2. all of output is available

8 pre, Ultralite, Audio Express, and 4 pre are in the category. They
transfer messages for output meters without any selection. The table for
available identifier for each direction is below:

==============  =========  ==========
model           input      output
==============  =========  ==========
8 pre           0x00-0x0f  0x82-0x8d
Ultralite       0x00-0x09  0x82-0x8f
Audio Express   0x00-0x09  0x80-0x8d
4 pre           0x00-0x09  0x80-0x8d
==============  =========  ==========

Some of available identifiers might not be used for actual output meters.

Anyway, 24 plus 24 elements accommodate the input/output meters.

I note that isochronous packet from V3HD/V4HD deliver no message.
Notification by asynchronous transaction to registered address seems to be
used for the purpose as well as for change of mixer parameter.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211027125529.54295-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: fix null pointer dereference when polling hwdep character device

ALSA firewire-motu driver recently got support for event notification via
ALSA HwDep interface for register DSP models. However, when polling ALSA
HwDep cdev, the driver can cause null pointer dereference for the other
models due to accessing to unallocated memory or uninitialized memory.

This commit fixes the bug by check the type of model before accessing to
the memory.

Reported-by: kernel test robot <lkp@intel.com>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211027125529.54295-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Add a quirk for HP OMEN 15 mute LED

HP OMEN 15 laptop requires the quirk to fiddle with COEF 0x0b bit 2
for toggling the mute LED.  It's already implemented for other HP
laptops, and we just need to add a proper fixup entry.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214735
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211028070911.18891-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: ua101: fix division by zero at probe

Add the missing endpoint max-packet sanity check to probe() to avoid
division by zero in alloc_stream_buffers() in case a malicious device
has broken descriptors (or when doing descriptor fuzz testing).

Note that USB core will reject URBs submitted for endpoints with zero
wMaxPacketSize but that drivers doing packet-size calculations still
need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
endpoint descriptors with maxpacket=0")).

Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support")
Cc: stable@vger.kernel.org # 2.6.34
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211026095401.26522-1-johan@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: line6: fix control and interrupt message timeouts

USB control and interrupt message timeouts are specified in milliseconds
and should specifically not vary with CONFIG_HZ.

Fixes: 705ececd1c60 ("Staging: add line6 usb driver")
Cc: stable@vger.kernel.org # 2.6.30
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211025121142.6531-3-johan@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: 6fire: fix control and bulk message timeouts

USB control and bulk message timeouts are specified in milliseconds and
should specifically not vary with CONFIG_HZ.

Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB")
Cc: stable@vger.kernel.org # 2.6.39
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211025121142.6531-2-johan@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: fix null pointer dereference on pointer cs_desc

The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.

Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
Link: https://lore.kernel.org/r/20211024111736.11342-1-cyeaa@connect.ust.hk
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: gus: fix null pointer dereference on pointer block

The pointer block return from snd_gf1_dma_next_block could be
null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.

Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
Link: https://lore.kernel.org/r/20211024104611.9919-1-cyeaa@connect.ust.hk
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: mixer: fix deadlock in snd_mixer_oss_set_volume

In commit 411cef6adfb3 ("ALSA: mixer: oss: Fix racy access to slots")
added mutex protection in snd_mixer_oss_set_volume(). Second
mutex_lock() in same function looks like typo, fix it.

Reported-by: syzbot+ace149a75a9a0a399ac7@syzkaller.appspotmail.com
Fixes: 411cef6adfb3 ("ALSA: mixer: oss: Fix racy access to slots")
Cc: <stable@vger.kernel.org>
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/20211024140315.16704-1-paskripkin@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Fix mic mute LED for the HP Spectre x360 14

On the 'HP Spectre x360 Convertible 14-ea0xx' the microphone mute led is
controlled by GPIO 0x04. The speaker mute LED does not seem to be
exposed by GPIO and is there not set.

[ a slight coding-style fix by tiwai ]

Fixes: c3bb2b521944 ("ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup")
Signed-off-by: Johnathon Clark <john.clark@cantab.net>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211020131253.35894-1-john.clark@cantab.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: mixer: oss: Fix racy access to slots

The OSS mixer can reassign the mapping slots dynamically via proc
file.  Although the addition and deletion of those slots are protected
by mixer->reg_mutex, the access to slots aren't, hence this may cause
UAF when the slots in use are deleted concurrently.

This patch applies the mixer->reg_mutex in all appropriate code paths
(i.e. the ioctl functions) that may access slots.

Reported-by: syzbot+9988f17cf72a1045a189@syzkaller.appspotmail.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/00000000000036adc005ceca9175@google.com
Link: https://lore.kernel.org/r/20211020164846.922-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: memalloc: Fix a typo in snd_dma_buffer_sync() description

It caused a warning for kernel-doc build.

Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20211019165402.4fa82c38@canb.auug.org.au
Link: https://lore.kernel.org/r/20211019060536.26089-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: memalloc: Drop superfluous snd_dma_buffer_sync() declaration

snd_dma_buffer_sync() is declared twice, and the one outside the ifdef
CONFIG_HAS_DMA could lead to a build error when CONFIG_HAS_DMA=n.
As it's an overlooked leftover after rebase, drop this line.

Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20211019165402.4fa82c38@canb.auug.org.au
Link: https://lore.kernel.org/r/20211019060536.26089-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Fix microphone sound on Jieli webcam.

When a Jieli Technology USB Webcam is connected, the video part works
well, but the mic sound is speeded up. On dmesg there are messages
about different rates from the runtime rates, warnings about volume
resolution and lastly, the log is filled, every 5 seconds, with
retire_capture_urb error messages.

The mic works only when ep packet size is set to wMaxPacketSize (normal
sound and no more retire_capture_urb error messages). Skipping reading
sample rate, fixes the messages about different rates and forcing a volume
resolution, fixes warnings about volume range. I have arbitrarily choosed
the value (16): I read in a comment that there should be no more than 255
levels, so 4096 (max volume) / 16 = 0-255.

Signed-off-by: Marco Giunta <giun7a@gmail.com>
Link: https://lore.kernel.org/r/20211018162552.12082-1-giun7a@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: uapi: Fix a C++ style comment in asound.h

UAPI header should have no C++ style comment but only in the
traditional C style comment, but there is still one place we used it
mistakenly.  This patch corrects it.

Fixes: 542283566679 ("ALSA: ctl: remove unused macro for timestamping of elem_value")
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211018114035.18433-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire: Fix C++ style comments in uapi header

UAPI headers are built with -std=c90 and C++ style comments are
explicitly prohibited.  The recent commit overlooked the rule and
caused the error at header installation.  This patch corrects those.

Fixes: bea36afa102e ("ALSA: firewire-motu: add message parser to gather meter information in register DSP model")
Fixes: 90b28f3bb85c ("ALSA: firewire-motu: add message parser for meter information in command DSP model")
Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211018113812.0a16efb0@canb.auug.org.au
Link: https://lore.kernel.org/r/20211018063700.30834-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: memalloc: Convert x86 SG-buffer handling with non-contiguous type

We've had an x86-specific SG-buffer handling code, but now it can be
merged gracefully with the standard non-contiguous DMA pages.

After the migration, SNDRV_DMA_TYPE_DMA_SG becomes identical with
SNDRV_DMA_TYPE_NONCONTIG on x86, while others still fall back to
SNDRV_DMA_TYPE_DEV.

The remaining problem is about the SG-buffer with WC pages: the DMA
core stuff on x86 doesn't treat it well, so we still need some special
handling to manipulate the page attribute manually.  The mmap handler
for SNDRV_DMA_TYPE_DEV_SG_WC still returns -ENOENT intentionally for
the fallback to the default handler.

Link: https://lore.kernel.org/r/20211017074859.24112-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: memalloc: Support for non-coherent page allocation

Following to the addition of non-contiguous pages, this patch adds the
new contiguous non-coherent page allocation to the standard memalloc
helper.  Like the previous non-contig type, this non-coherent type is
also directional and requires the explicit sync, too.  Hence the
driver using this type of buffer may need to set
SNDRV_PCM_INFO_EXPLICIT_SYNC flag to the PCM hardware.info as well,
unless it's set up in the managed mode.

Link: https://lore.kernel.org/r/20211017074859.24112-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: memalloc: Support for non-contiguous page allocation

This patch adds the support for allocation of non-contiguous DMA pages
in the common memalloc helper.  It's another SG-buffer type, but
unlike the existing one, this is directional and requires the explicit
sync / invalidation of dirty pages on non-coherent architectures.

For this enhancement, the following points are changed:
- snd_dma_device stores the DMA direction.
- snd_dma_device stores need_sync flag indicating whether the explicit
  sync is required or not.
- A new variant of helper functions, snd_dma_alloc_dir_pages() and
  *_all() are introduced; the old snd_dma_alloc_pages() and *_all()
  kept as just wrappers with DMA_BIDIRECTIONAL.
- A new helper snd_dma_buffer_sync() is introduced; this gets called
  in the appropriate places.
- A new allocation type, SNDRV_DMA_TYPE_NONCONTIG, is introduced.

When the driver allocates pages with this new type, and it may require
the SNDRV_PCM_INFO_EXPLICIT_SYNC flag set to the PCM hardware.info for
taking the full control of PCM applptr and hwptr changes (that implies
disabling the mmap of control/status data).  When the buffer
allocation is managed by snd_pcm_set_managed_buffer(), this flag is
automatically set depending on the result of dma_need_sync()
internally.  Otherwise, if the buffer is managed manually, the driver
has to set the flag explicitly, too.

The explicit sync between CPU and device for non-coherent memory is
performed at the points before and after read/write transfer as well
as the applptr/hwptr syncptr ioctl.  In the case of mmap mode,
user-space is supposed to call the syncptr ioctl with the hwptr flag
to update and fetch the status at first; this corresponds to CPU-sync.
Then user-space advances the applptr via syncptr ioctl again with
applptr flag, and this corresponds to the device sync with flushing.

Other than the DMA direction and the explicit sync, the usage of this
new buffer type is almost equivalent with the existing
SNDRV_DMA_TYPE_DEV_SG; you can get the page and the address via
snd_sgbuf_get_page() and snd_sgbuf_get_addr(), also calculate the
continuous pages via snd_sgbuf_get_chunk_size().

For those SG-page handling, the non-contig type shares the same ops
with the vmalloc handler.  As we do always vmap the SG pages at first,
the actual address can be deduced from the vmapped address easily
without iterating the SG-list.

Link: https://lore.kernel.org/r/20211017074859.24112-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: ISA: not for M68K

On m68k, compiling drivers under SND_ISA causes build errors:

../sound/core/isadma.c: In function 'snd_dma_program':
../sound/core/isadma.c:33:17: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration]
   33 |         flags = claim_dma_lock();
      |                 ^~~~~~~~~~~~~~
../sound/core/isadma.c:41:9: error: implicit declaration of function 'release_dma_lock' [-Werror=implicit-function-declaration]
   41 |         release_dma_lock(flags);
      |         ^~~~~~~~~~~~~~~~

../sound/isa/sb/sb16_main.c: In function 'snd_sb16_playback_prepare':
../sound/isa/sb/sb16_main.c:253:72: error: 'DMA_AUTOINIT' undeclared (first use in this function)
  253 |         snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_WRITE | DMA_AUTOINIT);
      |                                                                        ^~~~~~~~~~~~
../sound/isa/sb/sb16_main.c:253:72: note: each undeclared identifier is reported only once for each function it appears in
../sound/isa/sb/sb16_main.c: In function 'snd_sb16_capture_prepare':
../sound/isa/sb/sb16_main.c:322:71: error: 'DMA_AUTOINIT' undeclared (first use in this function)
  322 |         snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_READ | DMA_AUTOINIT);
      |                                                                       ^~~~~~~~~~~~

and more...

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20211016062602.3588-1-rdunlap@infradead.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: notify event for parameter change in register DSP model

This commit copies queued event for change of register DSP into
userspace when application operates ALSA hwdep character device.
The notification occurs only when packet streaming is running.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-12-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: queue event for parameter change in register DSP model

This commit is a preparation to notify parameter change of register DSP
to userspace application. A simple queue is added to store encoded data
for the change as long as ALSA hwdep character device is opened by
application.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-11-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: add ioctl command to read cached parameters in register DSP model

This patch adds new ioctl command for userspace applications to read
cached parameters of register DSP.

The structured data includes model-dependent parameters. Userspace
application should be carefully programmed so that what parameter is
common and specific.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: parse messages for input parameters in register DSP model

This commit parses message and cache current parameters of input function,
available for MOTU Ultralite, 4 pre, and Audio Express.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: parse messages for line input parameters in register DSP model

This commit parses message and cache current parameters of line input
function, available for MOTU 828 mk2 and Traveler.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: parse messages for output parameters in register DSP model

This commit parses message and cache current parameters of output
function, commonly available for all of register DSP model.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: parse messages for mixer output parameters in register DSP model

This commit parses message and cache current parameters of mixer output
function, commonly available for all of register DSP model

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: parse messages for mixer source parameters in register-DSP model

In register DSP models, current parameters of DSP are always reported by
messages in isochronous packet. When user operates hardware component such
as rotary knob, corresponding message is changed.

This commit parses the message and cache current parameters of mixer
source function, commonly available for all of register DSP models.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: add ioctl command to read cached hardware meter

This patch adds new ioctl commands for userspace applications to read
cached image about hardware meters in register DSP and command DSP models.

The content of image differs depending on models. Model-specific parser
should be implemented in userspace.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: add message parser for meter information in command DSP model

Some of MOTU models allows software to configure their DSP parameters by
command included in asynchronous transaction. The models multiplex messages
for hardware meters into isochronous packet as well as PCM frames. For
convenience, I call them as 'command DSP' model.

This patch adds message parser for them to gather hardware meter
information.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: add message parser to gather meter information in register DSP model

Some of MOTU models allows software to configure their DSP parameters by
accessing to their registers. The models multiplex messages for status of
DSP into isochronous packet as well as PCM frames. The message includes
information of hardware metering, MIDI message, current parameters of DSP.
For my convenience, I call them as 'register DSP' model.

This patch adds message parser for them to gather hardware meter
information.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211015080826.34847-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge tag 'asoc-fix-v5.15-rc5' of https://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v5.15

A colletion of smallish mostly driver specific fixes, the biggest thing
here is fixing some of the core code to generate change notifications
properly when writing to controls which will fix issues with UIs not
showing the correct values.

There's one build fix here with a slightly misleading changelog saying
it's adding IRQ config support, it's adding a missing select of the
regmap-irq code rather than adding a feature.

ALSA: hda/realtek: Fixes HP Spectre x360 15-eb1xxx speakers

In laptop 'HP Spectre x360 Convertible 15-eb1xxx/8811' both front and
rear speakers are silent, this patch fixes that by overriding the pin
layout and by initializing the amplifier which needs a GPIO pin to be
set to 1 then 0, similar to the existing HP Spectre x360 14 model.

In order to have volume control, both front and rear speakers were
forced to use the DAC1.

This patch also correctly map the mute LED but since there is no
microphone on/off switch exposed by the alsa subsystem it never turns
on by itself.

There are still known audio issues in this laptop: headset microphone
doesn't work, the button to mute/unmute microphone is not yet mapped,
the LED of the mute/unmute speakers doesn't seems to be exposed via
GPIO and never turns on.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213953
Signed-off-by: Davide Baldo <davide@baldo.me>
Link: https://lore.kernel.org/r/20211015072121.5287-1-davide@baldo.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Provide quirk for Sennheiser GSP670 Headset

As per discussion at: https://github.com/szszoke/sennheiser-gsp670-pulseaudio-profile/issues/13

The GSP670 has 2 playback and 1 recording device that by default are
detected in an incompatible order for alsa. This may have been done to make
it compatible for the console by the manufacturer and only affects the
latest firmware which uses its own ID.

This quirk will resolve this by reordering the channels.

Signed-off-by: Brendan Grieve <brendan@grieve.com.au>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211015025335.196592-1-brendan@grieve.com.au
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: pcm: Unify snd_pcm_delay() and snd_pcm_hwsync()

Both snd_pcm_delay() and snd_pcm_hwsync() do the almost same thing.
The only difference is that the former calculate the delay, so unify
them as a code cleanup, and treat NULL delay argument only for hwsync
operation.

Also, the patch does a slight code refactoring in snd_pcm_delay().
The initialization of the delay value is done in the caller side now.

Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211014145323.26506-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Initialize every feature unit once at probe time

So far we used to read the current value of the mixer element
dynamically at the first access, and the error from a GET_CUR message
is treated as a fatal error (unless QUIRK_IGNORE_CTL_ERROR is set).
It's rather inconvenient, as most of GET_CUR errors are no fatal, and
we can continue operation with assumption of some fixed value.

This patch makes the USB-audio driver to change the behavior at probe
time; now it tries to initialize the current value of each mixer
element that is built from a feature unit (those for typically for
mixer volumes and switches).  When a read failure happens, it tries to
set the known minimum value.  After that point, a cached value is used
always, hence we won't hit GET_CUR message error any longer.

The error from GET_CUR message is still shown as a warning normally,
but only once at the probe time, and it'll keep operating.  If the
message is confirmed to be harmless, it can be shut up by
QUIRK_IGNORE_CTL_ERROR quirk flag, too.

Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Drop superfluous error message after disconnection

The error from snd_usb_lock_shutdown() indicates that the device is
disconnected, hence it makes no sense to show any further control
message error in get_ctl_value_v2().  Return the error directly
instead.

Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Downgrade error message in get_ctl_value_v2()

The error message in get_ctl_value_v2() (for UAC2/3) is shown via
KERN_ERR level but it was intended to be rather a debug message as
seen in get_ctl_value_v1() (for UAC1).  This patch downgrade the
printk level.

Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge branch 'for-linus' into for-next

A back-merge of 5.15 branch into 5.16-devel branch for further
development of USB and ALSA core stuff that depends on 5.15 fixes.

Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Add quirk for Clevo PC50HS

Apply existing PCI quirk to the Clevo PC50HS and related models to fix
audio output on the built in speakers.

Signed-off-by: Steven Clarkson <sc@lambdal.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211014133554.1326741-1-sc@lambdal.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: add Schiit Hel device to quirk table

The Shciit Hel device responds to the ctl message for the mic capture
switch with a timeout of -EPIPE:

usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1

This seems safe to ignore as the device works properly with the control
message quirk, so add it to the quirk table so all is good.

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/YWgR3nOI1osvr5Yo@kroah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: wm8960: Fix clock configuration on slave mode

There is a noise issue for 8kHz sample rate on slave mode.
Compared with master mode, the difference is the DACDIV
setting, after correcting the DACDIV, the noise is gone.

There is no noise issue for 48kHz sample rate, because
the default value of DACDIV is correct for 48kHz.

So wm8960_configure_clocking() should be functional for
ADC and DAC function even if it is slave mode.

In order to be compatible for old use case, just add
condition for checking that sysclk is zero with
slave mode.

Fixes: 0e50b51aa22f ("ASoC: wm8960: Let wm8960 driver configure its bit clock and frame clock")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/1634102224-3922-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ALSA: usb-audio: Add quirk for VF0770

The device advertises 8 formats, but only a rate of 48kHz is honored
by the hardware and 24 bits give chopped audio, so only report the
one working combination. This fixes out-of-the-box audio experience
with PipeWire which otherwise attempts to choose S24_3LE (while
PulseAudio defaulted to S16_LE).

Signed-off-by: Jonas Hahnfeld <hahnjo@hahnjo.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda: avoid write to STATESTS if controller is in reset

The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
before performing controller reset. This code dates back to an old
bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
codec probing robustness"). Originally the code was added to
azx_reset().

The code was moved around in commit a41d122449be ("ALSA: hda - Embed bus
into controller object") and ended up to snd_hdac_bus_reset_link() and
called primarily via snd_hdac_bus_init_chip().

The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
called when controller is not in reset. In this case, STATESTS can be
cleared. This can be useful e.g. when forcing a controller reset to retry
codec probe. A normal non-power-on reset will not clear the bits.

However, this old logic is problematic when controller is already in
reset. The HDA specification states that controller must be taken out of
reset before writing to registers other than GCTL.CRST (1.0a spec,
3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
if the controller is already in reset per the HDA specification mentioned.

This has been harmless on older hardware. On newer generation of Intel
PCIe based HDA controllers, if configured to report issues, this write
will emit an unsupported request error. If ACPI Platform Error Interface
(APEI) is enabled in kernel, this will end up to kernel log.

Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
the function is called when controller is not in reset. Otherwise
clearing the bits is not possible and should be skipped.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211012142935.3731820-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Less restriction for low-latency playback mode

The recent support for the improved low-latency playback mode applied
the SNDRV_PCM_INFO_EXPLICIT_SYNC flag for the target streams, but this
was a slight overkill.  The use of the flag above disables effectively
both PCM status and control mmaps, while basically what we want to
track is only about the appl_ptr update.

For less restriction, use a more proper flag,
SNDRV_PCM_INFO_SYNC_APPLPTR instead, which disables only the control
mmap.

Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Link: https://lore.kernel.org/r/20211011103650.10182-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW

We need to define the codec pin 0x1b to be the mic, but somehow
the mic doesn't support hot plugging detection, and Windows also has
this issue, so we set it to phantom headset-mic.

Also the determine_headset_type() often returns the omtp type by a
mistake when we plug a ctia headset, this makes the mic can't record
sound at all. Because most of the headset are ctia type nowadays and
some machines have the fixed ctia type audio jack, it is possible this
machine has the fixed ctia jack too. Here we set this mic jack to
fixed ctia type, this could avoid the mic type detection mistake and
make the ctia headset work stable.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214537
Reported-and-tested-by: msd <msd.mmq@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20211012114748.5238-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: cs42l42: Ensure 0dB full scale volume is used for headsets

Ensure the default 0dB playback path is always used.

The code that set FULL_SCALE_VOL based on LOAD_DET_RCSTAT was
spurious, and resulted in a -6dB attenuation being accidentally
inserted into the playback path.

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20211011144903.28915-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl

Michael Forney reported an incorrect padding type that was defined in
the commit 80fe7430c708 ("ALSA: add new 32-bit layout for
snd_pcm_mmap_status/control") for PCM control mmap data.
His analysis is correct, and this caused the misplacements of PCM
control data on 32bit arch and 32bit compat mode.

The bug is that the __pad2 definition in __snd_pcm_mmap_control64
struct was wrongly with __pad_before_uframe, which should have been
__pad_after_uframe instead.  This struct is used in SYNC_PTR ioctl and
control mmap.  Basically this bug leads to two problems:

- The offset of avail_min field becomes wrong, it's placed right after
  appl_ptr without padding on little-endian

- When appl_ptr and avail_min are read as 64bit values in kernel side,
  the values become either zero or corrupted (mixed up)

One good news is that, because both user-space and kernel
misunderstand the wrong offset, at least, 32bit application running on
32bit kernel works as is.  Also, 64bit applications are unaffected
because the padding size is zero.  The remaining problem is the 32bit
compat mode; as mentioned in the above, avail_min is placed right
after appl_ptr on little-endian archs, 64bit kernel reads bogus values
for appl_ptr updates, which may lead to streaming bugs like jumping,
XRUN or whatever unexpected.
(However, we haven't heard any serious bug reports due to this over
years, so practically seen, it's fairly safe to assume that the impact
by this bug is limited.)

Ideally speaking, we should correct the wrong mmap status control
definition.  But this would cause again incompatibility with the
existing binaries, and fixing it (e.g. by renumbering ioctls) would be
really messy.

So, as of this patch, we only correct the behavior of 32bit compat
mode and keep the rest as is.  Namely, the SYNC_PTR ioctl is now
handled differently in compat mode to read/write the 32bit values at
the right offsets.  The control mmap of 32bit apps on 64bit kernels
has been already disabled (which is likely rather an overlook, but
this worked fine at this time :), so covering SYNC_PTR ioctl should
suffice as a fallback.

Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control")
Reported-by: Michael Forney <mforney@mforney.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: <stable@vger.kernel.org>
Cc: Rich Felker <dalias@libc.org>
Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org
Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: soc-core: fix null-ptr-deref in snd_soc_del_component_unlocked()

'component' is allocated in snd_soc_register_component(), but component->list
is not initalized, this may cause snd_soc_del_component_unlocked() deref null
ptr in the error handing case.

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:__list_del_entry_valid+0x81/0xf0
Call Trace:
 snd_soc_del_component_unlocked+0x69/0x1b0 [snd_soc_core]
 snd_soc_add_component.cold+0x54/0x6c [snd_soc_core]
 snd_soc_register_component+0x70/0x90 [snd_soc_core]
 devm_snd_soc_register_component+0x5e/0xd0 [snd_soc_core]
 tas2552_probe+0x265/0x320 [snd_soc_tas2552]
 ? tas2552_component_probe+0x1e0/0x1e0 [snd_soc_tas2552]
 i2c_device_probe+0xa31/0xbe0

Fix by adding INIT_LIST_HEAD() to snd_soc_component_initialize().

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20211009065840.3196239-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2

The previous patch's HDA verb initialization for the Lenovo 13s
sequence was slightly off. This updated verb sequence has been tested
and confirmed working.

Fixes: ad7cc2d41b7a ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555
Cc: <stable@vger.kernel.org>
Signed-off-by: Cameron Berkenpas <cam@neo-zeon.de>
Link: https://lore.kernel.org/r/20211010225410.23423-1-cam@neo-zeon.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Add support for the Pioneer DJM 750MK2 Mixer/Soundcard

The kernel already has support for very similar Pioneer djm products
and this work is based on that.

Added device to quirks-table.h and added control info to
mixer_quirks.c.

Tested on my hardware and all working.

Signed-off-by: William Overton <willovertonuk@gmail.com>
Link: https://lore.kernel.org/r/20211010145841.11907-1-willovertonuk@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: codec: wcd938x: Add irq config support

This patch fixes compilation error in wcd98x codec driver.

Fixes: 045442228868 ("ASoC: codecs: wcd938x: add audio routing and Kconfig")

Signed-off-by: Venkata Prasad Potturu <potturu@codeaurora.org>
Signed-off-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/1633614675-27122-1-git-send-email-srivasam@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: DAPM: Fix missing kctl change notifications

The put callback of a kcontrol is supposed to return 1 when the value
is changed, and this will be notified to user-space.  However, some
DAPM kcontrols always return 0 (except for errors), hence the
user-space misses the update of a control value.

This patch corrects the behavior by properly returning 1 when the
value gets updated.

Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20211006141712.2439-1-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: Intel: bytcht_es8316: Utilize dev_err_probe() to avoid log saturation

dev_err_probe() avoids printing into log when the deferred probe is invoked.
This is possible when clock provider is pending to appear.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211006150428.16434-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: Intel: bytcht_es8316: Switch to use gpiod_get_optional()

First of all, replace indexed API by plain one since we have index 0.
Second, switch to optional variant and drop duplicated code.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211006150428.16434-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: Intel: bytcht_es8316: Use temporary variable for struct device

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211006150428.16434-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: Intel: bytcht_es8316: Get platform data via dev_get_platdata()

Access to platform data via dev_get_platdata() getter to make code cleaner.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.com>
Link: https://lore.kernel.org/r/20211006150428.16434-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: wcd938x: Fix jack detection issue

This patch is to fix audio 3.5mm jack detection failure
on wcd938x codec based target.

Fixes: bcee7ed09b8e (ASoC: codecs: wcd938x: add Multi Button Headset Control support)

Signed-off-by: Venkata Prasad Potturu <potturu@codeaurora.org>
Signed-off-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/1633614619-27026-1-git-send-email-srivasam@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>

ALSA: usb-audio: Pass JOINT_DUPLEX info flag for implicit fb streams

When a stream is in the implicit feedback mode, it's more or less tied
with a capture stream.  Passing SNDRV_PCM_INFO_JOINT_DUPLEX may help
for user-space to understand the situation.

Link: https://lore.kernel.org/r/20211007083528.4184-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: pcm: Add more disconnection checks at file ops

In the case of hot-disconnection of a PCM device, all file operations
except for close should be rejected.  This patch adds more sanity
checks in the file operation code paths.

Link: https://lore.kernel.org/r/20211006142214.3089-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda: intel: Allow repeatedly probing on codec configuration errors

It seems that a few recent AMD systems show the codec configuration
errors at the early boot, while loading the driver at a later stage
works magically.  Although the root cause of the error isn't clear,
it's certainly not bad to allow retrying the codec probe in such a
case if that helps.

This patch adds the capability for retrying the probe upon codec probe
errors on the certain AMD platforms.  The probe_work is changed to a
delayed work, and at the secondary call, it'll jump to the codec
probing.

Note that, not only adding the re-probing, this includes the behavior
changes in the codec configuration function.  Namely,
snd_hda_codec_configure() won't unregister the codec at errors any
longer.  Instead, its caller, azx_codec_configure() unregisters the
codecs with the probe failures *if* any codec has been successfully
configured.  If all codec probe failed, it doesn't unregister but let
it re-probed -- which is the most case we're seeing and this patch
tries to improve.

Even if the driver doesn't re-probe or give up, it will go to the
"free-all" error path, hence the leftover codecs shall be disabled /
deleted in anyway.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190801
Link: https://lore.kernel.org/r/20211006141940.2897-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Add quirk for TongFang PHxTxX1

This applies a SND_PCI_QUIRK(...) to the TongFang PHxTxX1 barebone. This
fixes the issue of the internal Microphone not working after booting
another OS.

When booting a certain another OS this barebone keeps some coeff settings
even after a cold shutdown. These coeffs prevent the microphone detection
from working in Linux, making the Laptop think that there is always an
external microphone plugged-in and therefore preventing the use of the
internal one.

The relevant indexes and values where gathered by naively diff-ing and
reading a working and a non-working coeff dump.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211006130415.538243-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek - ALC236 headset MIC recording issue

In power save mode, the recording voice from headset mic will 2s more delay.
Add this patch will solve this issue.

[ minor coding style fix by tiwai ]

Signed-off-by: Kailang Yang <kailang@realtek.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/ccb0cdd5bbd7486eabbd8d987d384cb0@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Enable rate validation for Scarlett devices

The Scarlett device series from Focusrite Novation seem requiring the
sample rate validations as we've done for MOTU devices; otherwise the
driver probes invalid audioformat entries that contain the sample
rates that actually don't work, and this may result in an incomplete
setup as reported recently.

This patch adds the needed quirk flag for enabling the sample rate
validation for Focusrite Novation devices.

Fixes: fe773b8711e3 ("ALSA: usb-audio: workaround for iface reset issue")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214493
Link: https://lore.kernel.org/r/20211004074050.28241-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Add quirk for Clevo X170KM-G

This applies a SND_PCI_QUIRK(...) to the Clevo X170KM-G barebone. This
fixes the issue of the devices internal Speaker not working.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211001133111.428249-3-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Complete partial device name to avoid ambiguity

The string "Clevo X170" is not enough to unambiguously identify the correct
device.

Fixing it so another Clevo barebone name starting with "X170" can be added
without causing confusion.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211001133111.428249-2-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Fix packet size calculation regression

The commit d215f63d49da ("ALSA: usb-audio: Check available frames for
the next packet size") introduced the available frame size check, but
the conversion forgot to initialize the temporary variable properly,
and it resulted in a bogus calculation.  This patch fixes it.

Fixes: d215f63d49da ("ALSA: usb-audio: Check available frames for the next packet size")
Reported-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20211001104417.14291-1-colin.king@canonical.com
Link: https://lore.kernel.org/r/20211001105425.16191-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Enable headphone mic on Dell Latitude laptops with ALC3254

The headphone mic is not working on Dell Latitude laptops with ALC3254.
The codec vendor id is 0x10ec0295 and share the same pincfg as defined
in ALC295_STANDARD_PINS. So the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE will
be applied per alc269_pin_fixup_tbl[] but actually the headphone mic is
using NID 0x1b instead of 0x1a. The ALC269_FIXUP_DELL4_MIC_NO_PRESENCE
need to be applied instead.

Use ALC269_FIXUP_DELL4_MIC_NO_PRESENCE for particular models before
a generic fixup comes out.

Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211001062856.1037901-1-chris.chiu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: disable implicit feedback sync for Behringer UFX1204 and UFX1604

Behringer UFX1204 and UFX1604 have Synchronous endpoints to which
current ALSA code applies implicit feedback sync as if they were
Asynchronous endpoints. This breaks UAC compliance and is unneeded.

The commit 5e35dc0338d85ccebacf3f77eca1e5dea73155e8 and subsequent
1a15718b41df026cffd0e42cfdc38a1384ce19f9 were meant to clear up noise.

Unfortunately, noise persisted for those using higher sample rates and
this was only solved by commit d2e8f641257d0d3af6e45d6ac2d6f9d56b8ea964

Since there are no more reports of noise, let's get rid of the
implicit-fb quirks breaking UAC compliance.

Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
Link: https://lore.kernel.org/r/YVYSnoQ7nxLXT0Dq@geday
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: nau8824: Fix headphone vs headset, button-press detection no longer working

Commit 1d25684e2251 ("ASoC: nau8824: Fix open coded prefix handling")
replaced the nau8824_dapm_enable_pin() helper with direct calls to
snd_soc_dapm_enable_pin(), but the helper was using
snd_soc_dapm_force_enable_pin() and not forcing the MICBIAS + SAR
supplies on breaks headphone vs headset and button-press detection.

Replace the snd_soc_dapm_enable_pin() calls with
snd_soc_dapm_force_enable_pin() to fix this.

Cc: stable@vger.kernel.org
Fixes: 1d25684e2251 ("ASoC: nau8824: Fix open coded prefix handling")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210929201512.460360-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ALSA: seq: Fix a potential UAF by wrong private_free call order

John Keeping reported and posted a patch for a potential UAF in
rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be
called after the associated rawmidi object got already freed.
After a deeper look, it turned out that the bug is rather the
incorrect private_free call order for a snd_seq_device.  The
snd_seq_device private_free gets called at the release callback of the
sequencer device object, while this was rather expected to be executed
at the snd_device call chains that runs at the beginning of the whole
card-free procedure.  It's been broken since the rewrite of
sequencer-device binding (although it hasn't surfaced because the
sequencer device release happens usually right along with the card
device release).

This patch corrects the private_free call to be done in the right
place, at snd_seq_device_dev_free().

Fixes: 7c37ae5c625a ("ALSA: seq: Rewrite sequencer device binding with standard bus")
Reported-and-tested-by: John Keeping <john@metanate.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Avoid killing in-flight URBs during draining

While draining a stream, ALSA PCM core stops the stream by issuing
snd_pcm_stop() after all data has been sent out.  And, at PCM trigger
stop, currently USB-audio driver kills the in-flight URBs explicitly,
then at sync-stop ops, sync with the finish of all remaining URBs.
This might result in a drop of the drained samples as most of
USB-audio devices / hosts allow relatively long in-flight samples (as
a sort of FIFO).

For avoiding the trimming, this patch changes the stream-stop behavior
during PCM draining state.  Under that condition, the pending URBs
won't be killed.  The leftover in-flight URBs are caught by the
sync-stop operation that shall be performed after the trigger-stop
operation.

Link: https://lore.kernel.org/r/20210929080844.11583-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Improved lowlatency playback support

This is another attempt to improve further the handling of playback
stream in the low latency mode.  The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily.  In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.

Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode.  The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold.  The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs.  In the complete
callback, we try to fill the data and submit as much as possible
again.  When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition.  In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.

The following things are changed to achieve the behavior above:

* The endpoint prepare callback is changed to return an error code;
  when there is no enough data available, it may return -EAGAIN.
  Currently only prepare_playback_urb() returns the error.

  The evaluation of the available data is a bit messy here; we can't
  check with snd_pcm_avail() at the point of prepare callback (as
  runtime->status->hwptr hasn't been updated yet), hence we manually
  estimate the appl_ptr and compare with the internal hwptr_done to
  calculate the available frames.

* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
  callback returns -EAGAIN, and puts the remaining URBs to the ready
  list for the later submission.

* snd_complete_urb() treats the URBs in the low-latency mode similarly
  like the implicit feedback mode, and submissions are done in
  (now exported) snd_usb_queue_pending_output_urbs().

* snd_usb_queue_pending_output_urbs() again checks the error value
  from the prepare callback.  If it's -EAGAIN for the normal stream
  (i.e. not implicit feedback mode), we push it back to the ready list
  again.

* PCM ack callback is introduced for the playback stream, and it calls
  snd_usb_queue_pending_output_urbs() if there is no in-flight URB
  while the stream is running.  This corresponds to the case where the
  system needs the appl_ptr update for re-submitting a new URB.

* snd_usb_queue_pending_output_urbs() and the prepare EP callback
  receive in_stream_lock argument, which is a bool flag indicating the
  call path from PCM ack.  It's needed for avoiding the deadlock of
  snd_pcm_period_elapsed() calls.

* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
  low-latency mode is deployed.  This assures catching each applptr
  update even in the mmap mode.

Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Add spinlock to stop_urbs()

In theory, stop_urbs() may be called concurrently.
Although we have the state check beforehand, it's safer to apply
ep->lock during the critical list head manipulations.

Link: https://lore.kernel.org/r/20210929080844.11583-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Check available frames for the next packet size

This is yet more preparation for the upcoming changes.

Extend snd_usb_endpoint_next_packet_size() to check the available
frames and return -EAGAIN if the next packet size is equal or exceeds
the given size.  This will be needed for avoiding XRUN during the low
latency operation.

As of this patch, avail=0 is passed, i.e. the check is skipped and no
behavior change.

Link: https://lore.kernel.org/r/20210929080844.11583-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Disable low-latency mode for implicit feedback sync

When a playback stream runs in the implicit feedback mode, its
operation is passive and won't start unless the capture packet is
received.  This behavior contradicts with the low-latency playback
mode, and we should turn off lowlatency_playback flag accordingly.

In theory, we may take the low-latency mode when the playback-first
quirk is set, but it still conflicts with the later operation with the
fixed packet numbers, so it's disabled all together for now.

Link: https://lore.kernel.org/r/20210929080844.11583-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Disable low-latency playback for free-wheel mode

The free-wheel stream operation like dmix may not update the appl_ptr
appropriately, and it doesn't fit with the low-latency playback mode.
Disable the low-latency playback operation when the stream is set up
in such a mode.

Link: https://lore.kernel.org/r/20210929080844.11583-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Rename early_playback_start flag with lowlatency_playback

This is a preparation patch for the upcoming low-latency improvement
changes.

Rename early_playback_start flag with lowlatency_playback as it's more
intuitive.  The new flag is basically a reverse meaning.

Along with the rename, factor out the code to set the flag to a
function.  This makes the complex condition checks simpler.

Also, the same flag is introduced to snd_usb_endpoint, too, that is
carried from the snd_usb_substream flag.  Currently the endpoint flag
isn't still referred, but will be used in later patches.

Link: https://lore.kernel.org/r/20210929080844.11583-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Fix possible race at sync of urb completions

USB-audio driver tries to sync with the clear of all pending URBs in
wait_clear_urbs(), and it waits for all bits in active_mask getting
cleared.  This works fine for the normal operations, but when a stream
is managed in the implicit feedback mode, there is still a very thin
race window: namely, in snd_complete_usb(), the active_mask bit for
the current URB is once cleared before re-submitted in
queue_pending_output_urbs().  If wait_clear_urbs() is called during
that period, it may pass the test and go forward even though there may
be a still pending URB.

For covering it, this patch adds a new counter to each endpoint to
keep the number of in-flight URBs, and changes wait_clear_urbs()
checking this number instead.  The counter is decremented at the end
of URB complete, hence the reference is kept as long as the URB
complete is in process.

Link: https://lore.kernel.org/r/20210929080844.11583-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Restrict rates for the shared clocks

When a single clock source is shared among several endpoints, we have
to keep the same rate on all active endpoints as long as the clock is
being used.  For dealing with such a case, this patch adds one more
check in the hw params constraint for the rate to take the shared
clocks into account.  The current rate is evaluated from the endpoint
list that applies the same clock source.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190418
Link: https://lore.kernel.org/r/20210929080844.11583-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek: Enable 4-speaker output for Dell Precision 5560 laptop

The Dell Precision 5560 laptop appears to use the 4-speakers-on-ALC289
audio just like its sibling product XPS 9510, so it requires the same
quirk to enable woofer output. Tested on my Dell Precision 5560.

Signed-off-by: John Liu <johnliu55tw@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210930115316.659-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda: Use position buffer for SKL+ again

The commit f87e7f25893d ("ALSA: hda - Improved position reporting on
SKL+") changed the PCM position report for SKL+ chips to use DPIB, but
according to Pierre, DPIB is no best choice for the accurate position
reports and it often reports too early.  The recommended method is
rather the classical position buffer.

This patch makes the PCM position reporting on SKL+ back to the
position buffer again.

Fixes: f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+")
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210929072934.6809-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda: Reduce udelay() at SKL+ position reporting

The position reporting on Intel Skylake and later chips via
azx_get_pos_skl() contains a udelay(20) call for the capture streams.
A call for this alone doesn't sound too harmful.  However, as the
pointer PCM ops is one of the hottest path in the PCM operations --
especially for the timer-scheduled operations like PulseAudio -- such
a delay hogs CPU usage significantly in the total performance.

The code there was taken from the original code in ASoC SST Skylake
driver blindly.  The udelay() is a workaround for the case where the
reported position is behind the period boundary at the timing
triggered from interrupts; applications often expect that the full
data is available for the whole period when returned (and also that's
the definition of the ALSA PCM period).

OTOH, HD-audio (legacy) driver has already some workarounds for the
delayed position reporting due to its relatively large FIFO, such as
the BDL position adjustment and the delayed period-elapsed call in the
work.  That said, the udelay() is almost superfluous for HD-audio
driver unlike SST, and we can drop the udelay().

Though, the current code doesn't guarantee the full period readiness
as mentioned in the above, but rather it checks the wallclock and
detects the unexpected jump.  That's one missing piece, and the drop
of udelay() needs a bit more sanity checks for the delayed handling.

This patch implements those: the drop of udelay() call in
azx_get_pos_skl() and the more proper check of hwptr in
azx_position_ok().  The latter change is applied only for the case
where the stream is running in the normal mode without
no_period_wakeup flag.  When no_period_wakeup is set, it essentially
ignores the period handling and rather concentrates only on the
current position; which implies that we don't need to care about the
period boundary at all.

Fixes: f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+")
Reported-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210929072934.6809-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: Fix a missing error check in scarlett gen2 mixer

The check of the returned error code is missing in
scarlett2_update_monitor_other().  Let's fix it.

Fixes: d5bda7e03982 ("ALSA: usb-audio: scarlett2: Add support for the talkback feature")
Reported-by: kernel test robot <lkp@intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/202109131831.9IodEzRx-lkp@intel.com
Link: https://lore.kernel.org/r/20210929073540.9611-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: virtio: Replace zero-length array with flexible-array member

There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].

Also, make use of the struct_size() helper in kzalloc().

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays

Link: https://github.com/KSPP/linux/issues/78
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20210929191504.GA337268@embeddedor
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: pcsp: Make hrtimer forwarding more robust

The hrtimer callback pcsp_do_timer() prepares rearming of the timer with
hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to
forward the expiry time of the hrtimer by a multiple of the period argument
so that the expiry time greater than the time provided in the 'now'
argument.

pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry
time as 'now' argument. That's providing a periodic timer expiry, but is
not really robust when the timer callback is delayed so that the resulting
new expiry time is already in the past which causes the callback to be
invoked immediately again. If the timer is delayed then the back to back
invocation is not really making it better than skipping the missed
periods. Sound is distorted in any case.

Use hrtimer_forward_now() which ensures that the next expiry is in the
future. This prevents hogging the CPU in the timer expiry code and allows
later on to remove hrtimer_forward() from the public interfaces.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: alsa-devel@alsa-project.org
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: SOF: Intel: hda-dai: fix potential locking issue

The initial hdac_stream code was adapted a third time with the same
locking issues. Move the spin_lock outside the loops and make sure the
fields are protected on read/write.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210924192417.169243-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda: hdac_ext_stream: fix potential locking issues

The code for hdac_ext_stream seems inherited from hdac_stream, and
similar locking issues are present: the use of the bus->reg_lock
spinlock is inconsistent, with only writes to specific fields being
protected.

Apply similar fix as in hdac_stream by protecting all accesses to
'link_locked' and 'decoupled' fields, with a new helper
snd_hdac_ext_stream_decouple_locked() added to simplify code
changes.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210924192417.169243-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda: hdac_stream: fix potential locking issue in snd_hdac_stream_assign()

The fields 'opened', 'running', 'assigned_key' are all protected by a
spinlock, but the spinlock is not taken when looking for a
stream. This can result in a possible race between assign() and
release().

Fix by taking the spinlock before walking through the bus stream list.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210924192417.169243-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: usb-audio: fix comment reference in __uac_clock_find_source

snd_usb_find_clock_source and snd_usb_find_clock_selector are helper
macros that look at an entity id and validate that this entity id is
in fact a clock source or a clock selector. The present comments
inside __uac_clock_find_source give the reader the impression we're
looking for an entity id.

We're looking for an entity id indeed, the clock source, but since
__uac_clock_find_source is recursive, we're also looking *at* the
entity ids, in the search for the one clock source.

Fix the comment so we don't give readers a wrong idea.

Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
Link: https://lore.kernel.org/r/YU6Kj05oOqRmhJDf@geday
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: cs4341: Add SPI device ID table

Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding SPI IDs for parts that
only have a compatible listed.

Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: patches@opensource.cirrus.com
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210924194844.45974-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: pcm179x: Add missing entries SPI to device ID table

Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding SPI IDs for parts that
only have a compatible listed.

Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210924194956.46079-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

ALSA: rawmidi: introduce SNDRV_RAWMIDI_IOCTL_USER_PVERSION

The new framing mode causes the user space regression, because
the alsa-lib code does not initialize the reserved space in
the params structure when the device is opened.

This change adds SNDRV_RAWMIDI_IOCTL_USER_PVERSION like we
do for the PCM interface for the protocol acknowledgment.

Cc: David Henningsson <coding@diwic.se>
Cc: <stable@vger.kernel.org>
Fixes: 08fdced60ca0 ("ALSA: rawmidi: Add framing mode")
BugLink: https://github.com/alsa-project/alsa-lib/issues/178
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210920171850.154186-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: firewire-motu: fix truncated bytes in message tracepoints

In MOTU protocol v2/v3, first two data chunks across 2nd and 3rd data
channels includes message bytes from device. The total size of message
is 48 bits per data block.

The 'data_block_message' tracepoints event produced by ALSA firewire-motu
driver exposes the sequence of messages to userspace in 64 bit storage,
however lower 32 bits are actually available since current implementation
truncates 16 bits in upper of the message as a result of bit shift
operation within 32 bit storage.

This commit fixes the bug by perform the bit shift in 64 bit storage.

Fixes: c6b0b9e65f09 ("ALSA: firewire-motu: add tracepoints for messages for unique protocol")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210920110734.27161-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge tag 'asoc-fix-v5.15-rc2' of https://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v5.15

A crop of mostly device specific fixes that have been applied since
the merge window, nothing particularly standout here.

ALSA: usx2y: Prefer struct_size over open coded arithmetic

As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them overflowing. This could lead
to values wrapping around and a smaller allocation being made than the
caller was expecting. Using those allocations could lead to linear
overflows of heap memory and other misbehaviors.

In this case this is not actually dynamic size: all the operands
involved in the calculation are constant values. However it is better to
refactor this anyway, just to keep the open-coded math idiom out of
code.

So, use the struct_size() helper to do the arithmetic instead of the
argument "size + size * count" in the kzalloc() function.

Also, take the opportunity to refactor the declaration variables to make
it more easy to read.

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments

Signed-off-by: Len Baker <len.baker@gmx.com>
Link: https://lore.kernel.org/r/20210919133727.44694-1-len.baker@gmx.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>