linux-2.6-microblaze.git
4 years agoMerge branch 'for-linus' into for-next
Takashi Iwai [Thu, 28 May 2020 08:08:46 +0000 (10:08 +0200)]
Merge branch 'for-linus' into for-next

Back-merge 5.7-devel branch for further development.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Add new codec supported for ALC287
Kailang Yang [Wed, 27 May 2020 06:10:26 +0000 (14:10 +0800)]
ALSA: hda/realtek - Add new codec supported for ALC287

Enable new codec supported for ALC287.

Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/dcf5ce5507104d0589a917cbb71dc3c6@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Quirks for Gigabyte TRX40 Aorus Master onboard audio
Takashi Iwai [Tue, 26 May 2020 08:28:10 +0000 (10:28 +0200)]
ALSA: usb-audio: Quirks for Gigabyte TRX40 Aorus Master onboard audio

Gigabyte TRX40 Aorus Master is equipped with two USB-audio devices,
a Realtek ALC1220-VB codec (USB ID 0414:a001) and an ESS SABRE9218 DAC
(USB ID 0414:a000).  The latter serves solely for the headphone output
on the front panel while the former serves for the rest I/Os (mostly
for the I/Os in the rear panel but also including the front mic).

Both chips do work more or less with the unmodified USB-audio driver,
but there are a few glitches.  The ALC1220-VB returns an error for an
inquiry to some jacks, as already seen on other TRX40-based mobos.
However this machine has a slightly incompatible configuration, hence
the existing mapping cannot be used as is.

Meanwhile the ESS chip seems working without any quirk.  But since
both audio devices don't provide any specific names, both cards appear
as "USB-Audio", and it's quite confusing for users.

This patch is an attempt to overcome those issues:

- The specific mapping table for ALC1220-VB is provided, reducing the
  non-working nodes and renaming the badly chosen controls.
  The connector map isn't needed here unlike other TRX40 quirks.

- For both USB IDs (0414:a000 and 0414:a001), provide specific card
  name strings, so that user-space can identify more easily; and more
  importantly, UCM profile can be applied to each.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200526082810.29506-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: mixer: volume quirk for ESS Technology Asus USB DAC
Chris Chiu [Tue, 26 May 2020 06:26:13 +0000 (14:26 +0800)]
ALSA: usb-audio: mixer: volume quirk for ESS Technology Asus USB DAC

The Asus USB DAC is a USB type-C audio dongle for connecting to
the headset and headphone. The volume minimum value -23040 which
is 0xa600 in hexadecimal with the resolution value 1 indicates
this should be endianness issue caused by the firmware bug. Add
a volume quirk to fix the volume control problem.

Also fixes this warning:
  Warning! Unlikely big volume range (=23040), cval->res is probably wrong.
  [5] FU [Headset Capture Volume] ch = 1, val = -23040/0/1
  Warning! Unlikely big volume range (=23040), cval->res is probably wrong.
  [7] FU [Headset Playback Volume] ch = 1, val = -23040/0/1

Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200526062613.55401-1-chiu@endlessm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Add a model for Thinkpad T570 without DAC workaround
Takashi Iwai [Tue, 26 May 2020 06:24:06 +0000 (08:24 +0200)]
ALSA: hda/realtek - Add a model for Thinkpad T570 without DAC workaround

We fixed the regression of the speaker volume for some Thinkpad models
(e.g. T570) by the commit 54947cd64c1b ("ALSA: hda/realtek - Fix
speaker output regression on Thinkpad T570").  Essentially it fixes
the DAC / pin pairing by a static table.  It was confirmed and merged
to stable kernel later.

Now, interestingly, we got another regression report for the very same
model (T570) about the similar problem, and the commit above was the
culprit.  That is, by some reason, there are devices that prefer the
DAC1, and another device DAC2!

Unfortunately those have the same ID and we have no idea what can
differentiate, in this patch, a new fixup model "tpt470-dock-fix" is
provided, so that users with such a machine can apply it manually.
When model=tpt470-dock-fix option is passed to snd-hda-intel module,
it avoids the fixed DAC pairing and the DAC1 is assigned to the
speaker like the earlier versions.

Fixes: 54947cd64c1b ("ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570")
BugLink: https://apibugzilla.suse.com/show_bug.cgi?id=1172017
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200526062406.9799-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hwdep: fix a left shifting 1 by 31 UB bug
Changming Liu [Tue, 26 May 2020 00:39:21 +0000 (00:39 +0000)]
ALSA: hwdep: fix a left shifting 1 by 31 UB bug

The "info.index" variable can be 31 in "1 << info.index".
This might trigger an undefined behavior since 1 is signed.

Fix this by casting 1 to 1u just to be sure "1u << 31" is defined.

Signed-off-by: Changming Liu <liu.changm@northeastern.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/BL0PR06MB4548170B842CB055C9AF695DE5B00@BL0PR06MB4548.namprd06.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: add support for MOTU UltraLite-mk3 (FireWire only model)
Takashi Sakamoto [Sat, 23 May 2020 07:17:33 +0000 (16:17 +0900)]
ALSA: firewire-motu: add support for MOTU UltraLite-mk3 (FireWire only model)

UltraLite-mk3 was shipped 2008 by MOTU. This model has two lineups;
FireWire-only and FireWire/USB2.0 Hybrid model. Additionally, the latter
has two variants in respect of the type of IEEE 1394 connector; alpha
and beta connector.

This commit adds support for the FireWire-only model, which is already
discontinued.

$ python3 crpp < /sys/bus/firewire/devices/fw1/config_rom
               ROM header and bus information block
               -----------------------------------------------------------------
400  0410353a  bus_info_length 4, crc_length 16, crc 13626
404  31333934  bus_name "1394"
408  20ff7000  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c  0001f200  company_id 0001f2     |
410  000902c7  device_id 00000902c7  | EUI-64 0001f200000902c7

               root directory
               -----------------------------------------------------------------
414  0004ef04  directory_length 4, crc 61188
418  030001f2  vendor
41c  0c0083c0  node capabilities per IEEE 1394
420  d1000002  --> unit directory at 428
424  8d000005  --> eui-64 leaf at 438

               unit directory at 428
               -----------------------------------------------------------------
428  00035556  directory_length 3, crc 21846
42c  120001f2  specifier id
430  13000019  version
434  17100800  model

               eui-64 leaf at 438
               -----------------------------------------------------------------
438  0002f3c5  leaf_length 2, crc 62405
43c  0001f200  company_id 0001f2     |
440  000902c7  device_id 00000902c7  | EUI-64 0001f200000902c7

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200523071733.170129-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: refactoring protocol v2 for fetching mode switch
Takashi Sakamoto [Tue, 19 May 2020 11:16:41 +0000 (20:16 +0900)]
ALSA: firewire-motu: refactoring protocol v2 for fetching mode switch

This commit splits the method to switch fetching mode for protocol
version 2 so that model-dependent operations are explicitly defined.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-15-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: refactoring protocol v3 for clock source getter
Takashi Sakamoto [Tue, 19 May 2020 11:16:40 +0000 (20:16 +0900)]
ALSA: firewire-motu: refactoring protocol v3 for clock source getter

This commit splits the method to get clock source for protocol
version 3 so that model-dependent operations are explicitly defined.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-14-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: refactoring protocol v2 for clock source getter
Takashi Sakamoto [Tue, 19 May 2020 11:16:39 +0000 (20:16 +0900)]
ALSA: firewire-motu: refactoring protocol v2 for clock source getter

This commit splits the method to get clock source for protocol
version 2 so that model-dependent operations are explicitly defined.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-13-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: remove obsoleted codes
Takashi Sakamoto [Tue, 19 May 2020 11:16:38 +0000 (20:16 +0900)]
ALSA: firewire-motu: remove obsoleted codes

The way to decide CIP payload size by calculation with any flag is now
obsoleted. This commit removes the codes.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-12-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: use table-based calculation of packet formats for stream management
Takashi Sakamoto [Tue, 19 May 2020 11:16:37 +0000 (20:16 +0900)]
ALSA: firewire-motu: use table-based calculation of packet formats for stream management

This commit uses table-based calculation of packet formats for stream
management.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-11-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: use table-based calculation of packet formats for proc
Takashi Sakamoto [Tue, 19 May 2020 11:16:36 +0000 (20:16 +0900)]
ALSA: firewire-motu: use table-based calculation of packet formats for proc

This commit uses table-based calculation of packet formats for proc
nodes.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: add alternative functions to detect packet format for protocol v3
Takashi Sakamoto [Tue, 19 May 2020 11:16:35 +0000 (20:16 +0900)]
ALSA: firewire-motu: add alternative functions to detect packet format for protocol v3

This commit adds alternative functions to detect packet format so that
each function corresponds to each model.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: add alternative functions to detect packet format for protocol v2
Takashi Sakamoto [Tue, 19 May 2020 11:16:34 +0000 (20:16 +0900)]
ALSA: firewire-motu: add alternative functions to detect packet format for protocol v2

This commit adds alternative functions to detect packet format so that
each function corresponds to each model.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: add model-specific table of chunk count
Takashi Sakamoto [Tue, 19 May 2020 11:16:33 +0000 (20:16 +0900)]
ALSA: firewire-motu: add model-specific table of chunk count

In MOTU protocol, data block consists of SPH and 24-bit chunks
aligned to quadlet. The number of chunks per data block is specific
to model. For models with optical interface, the number differs
depending on I/O settings for the interface (ADAT, TOSLINK).

Currently the number is calculated from flags in model-specific
data. However this is weak in the case that the model has quirks.
Actually, for quirks of some models, flags are used against their
original meanings.

This commit adds model-specific table of chunk count. For future
integration, this table is based on the calculation.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: drop protocol structure
Takashi Sakamoto [Tue, 19 May 2020 11:16:32 +0000 (20:16 +0900)]
ALSA: firewire-motu: drop protocol structure

Now protocol structure becomes useless. This commit drops it.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: add wrapper functions for protocol-dependent operations
Takashi Sakamoto [Tue, 19 May 2020 11:16:31 +0000 (20:16 +0900)]
ALSA: firewire-motu: add wrapper functions for protocol-dependent operations

This commit adds helper functions which wraps function call for each
protocol.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: localize protocol data
Takashi Sakamoto [Tue, 19 May 2020 11:16:30 +0000 (20:16 +0900)]
ALSA: firewire-motu: localize protocol data

This commit adds enumerations of protocol version to localize protocol
data.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: move spec data to v3 protocol file
Takashi Sakamoto [Tue, 19 May 2020 11:16:29 +0000 (20:16 +0900)]
ALSA: firewire-motu: move spec data to v3 protocol file

The most of members in spec data is used in each protocol file. It's
better to capsulate the data to the file.

This commit moves the data to the file for protocol version 3.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: move spec data to v2 protocol file
Takashi Sakamoto [Tue, 19 May 2020 11:16:28 +0000 (20:16 +0900)]
ALSA: firewire-motu: move spec data to v2 protocol file

The most of members in spec data is used in each protocol file. It's
better to capsulate the data to the file.

This commit moves the data to the file for protocol version 2.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200519111641.123211-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Add more fixup entries for Clevo machines
PeiSen Hou [Tue, 19 May 2020 06:50:12 +0000 (08:50 +0200)]
ALSA: hda/realtek - Add more fixup entries for Clevo machines

A few known Clevo machines (PC50, PC70, X170) with ALC1220 codec need
the existing quirk for pins for PB51 and co.

Signed-off-by: PeiSen Hou <pshou@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200519065012.13119-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: iec1712: Initialize STDSP24 properly when using the model=staudio option
Scott Bahling [Mon, 18 May 2020 17:57:28 +0000 (19:57 +0200)]
ALSA: iec1712: Initialize STDSP24 properly when using the model=staudio option

The ST Audio ADCIII is an STDSP24 card plus extension box. With commit
e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII") we
enabled the ADCIII ports using the model=staudio option but forgot
this part to ensure the STDSP24 card is initialized properly.

Fixes: e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII")
Signed-off-by: Scott Bahling <sbahling@suse.com>
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1048934
Link: https://lore.kernel.org/r/20200518175728.28766-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme
Christian Lachner [Mon, 18 May 2020 05:38:44 +0000 (07:38 +0200)]
ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme

The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec
requires a similar workaround for Clevo laptops to enforce the
DAC/mixer connection path. Set up a quirk entry for that.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275
Signed-off-by: Christian Lachner <gladiac@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200518053844.42743-2-gladiac@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: pcm: fix incorrect hw_base increase
Brent Lu [Mon, 18 May 2020 04:30:38 +0000 (12:30 +0800)]
ALSA: pcm: fix incorrect hw_base increase

There is a corner case that ALSA keeps increasing the hw_ptr but DMA
already stop working/updating the position for a long time.

In following log we can see the position returned from DMA driver does
not move at all but the hw_ptr got increased at some point of time so
snd_pcm_avail() will return a large number which seems to be a buffer
underrun event from user space program point of view. The program
thinks there is space in the buffer and fill more data.

[  418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[  418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554
...
[  418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362
[  418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
[  418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368

This is because the hw_base will be increased by runtime->buffer_size
frames unconditionally if the hw_ptr is not updated for over half of
buffer time. As the hw_base increases, so does the hw_ptr increased
by the same number.

The avail value returned from snd_pcm_avail() could exceed the limit
(buffer_size) easily becase the hw_ptr itself got increased by same
buffer_size samples when the corner case happens. In following log,
the buffer_size is 16368 samples but the avail is 21810 samples so
CRAS server complains about it.

[  418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442
[  418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810

cras_server[1907]: pcm_avail returned frames larger than buf_size:
sof-glkda7219max: :0,5: 21810 > 16368

By updating runtime->hw_ptr_jiffies each time the HWSYNC is called,
the hw_base will keep the same when buffer stall happens at long as
the interval between each HWSYNC call is shorter than half of buffer
time.

Following is a log captured by a patched kernel. The hw_base/hw_ptr
value is fixed in this corner case and user space program should be
aware of the buffer stall and handle it.

[  293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[  293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584
[  293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488
[  293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392
[  293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
...
[  381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0

Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Unexport some local helper functions
Takashi Iwai [Sat, 16 May 2020 06:28:54 +0000 (08:28 +0200)]
ALSA: hda: Unexport some local helper functions

snd_hdac_bus_queue_event() and snd_hdac_bus_exec_verb() are used only
internally in HD-audio core.  Let's drop the exports and move the
declarations into local.h.

Link: https://lore.kernel.org/r/20200516062854.22141-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Drop unused snd_hda_queue_unsol_event()
Takashi Iwai [Sat, 16 May 2020 06:28:53 +0000 (08:28 +0200)]
ALSA: hda: Drop unused snd_hda_queue_unsol_event()

The inline function is nowhere used.  Drop it.

Link: https://lore.kernel.org/r/20200516062854.22141-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Fix potential race in unsol event handler
Takashi Iwai [Sat, 16 May 2020 06:25:56 +0000 (08:25 +0200)]
ALSA: hda: Fix potential race in unsol event handler

The unsol event handling code has a loop retrieving the read/write
indices and the arrays without locking while the append to the array
may happen concurrently.  This may lead to some inconsistency.
Although there hasn't been any proof of this bad results, it's still
safer to protect the racy accesses.

This patch adds the spinlock protection around the unsol handling loop
for addressing it.  Here we take bus->reg_lock as the writer side
snd_hdac_bus_queue_event() is also protected by that lock.

Link: https://lore.kernel.org/r/20200516062556.30951-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Add duplex sound support for USB devices using implicit feedback
Erwin Burema [Sun, 10 May 2020 18:29:11 +0000 (20:29 +0200)]
ALSA: usb-audio: Add duplex sound support for USB devices using implicit feedback

For USB sound devices using implicit feedback the endpoint used for
this feedback should be able to be opened twice, once for required
feedback and second time for audio data. This way these devices can be
put in duplex audio mode. Since this only works if the settings of the
endpoint don't change a check is included for this.

This fixes bug 207023 ("MOTU M2 regression on duplex audio") and
should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device
will not operate full-duplex")

Fixes: c249177944b6 ("ALSA: usb-audio: add implicit fb quirk for MOTU M Series")
Signed-off-by: Erwin Burema <e.burema@gmail.com>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207023
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=103751
Link: https://lore.kernel.org/r/2410739.SCZni40SNb@alpha-wolf
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: fixing upper volume limit for RME Babyface Pro routing crosspoints
Thomas Ebeling [Fri, 15 May 2020 11:46:05 +0000 (13:46 +0200)]
ALSA: usb-audio: fixing upper volume limit for RME Babyface Pro routing crosspoints

In my initial patch, these were set too low.

Fixes: 3e8f3bd04716 ("ALSA: usb-audio: RME Babyface Pro mixer patch")
Signed-off-by: Thomas Ebeling <penguins@bollie.de>
Link: https://lore.kernel.org/r/20200515114556.vtspnonzvp4xp44m@bollie.ca9.eu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Limit int mic boost for Thinkpad T530
Takashi Iwai [Thu, 14 May 2020 16:05:33 +0000 (18:05 +0200)]
ALSA: hda/realtek - Limit int mic boost for Thinkpad T530

Lenovo Thinkpad T530 seems to have a sensitive internal mic capture
that needs to limit the mic boost like a few other Thinkpad models.
Although we may change the quirk for ALC269_FIXUP_LENOVO_DOCK, this
hits way too many other laptop models, so let's add a new fixup model
that limits the internal mic boost on top of the existing quirk and
apply to only T530.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1171293
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200514160533.10337-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Add COEF workaround for ASUS ZenBook UX431DA
Takashi Iwai [Tue, 12 May 2020 07:32:03 +0000 (09:32 +0200)]
ALSA: hda/realtek - Add COEF workaround for ASUS ZenBook UX431DA

ASUS ZenBook UX431DA requires an additional COEF setup when booted
from the recent Windows 10, otherwise it produces the noisy output.
The quirk turns on COEF 0x1b bit 10 that has been cleared supposedly
due to the pop noise reduction.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207553
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200512073203.14091-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek: Enable headset mic of ASUS UX581LV with ALC295
Jian-Hong Pan [Tue, 12 May 2020 06:15:28 +0000 (14:15 +0800)]
ALSA: hda/realtek: Enable headset mic of ASUS UX581LV with ALC295

The ASUS UX581LV laptop's audio (1043:19e1) with ALC295 can't detect the
headset microphone until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk
applied.

Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Link: https://lore.kernel.org/r/20200512061525.133985-3-jian-hong@endlessm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Enable headset mic of ASUS UX550GE with ALC295
Jian-Hong Pan [Tue, 12 May 2020 06:15:26 +0000 (14:15 +0800)]
ALSA: hda/realtek - Enable headset mic of ASUS UX550GE with ALC295

The ASUS laptop UX550GE with ALC295 can't detect the headset microphone
until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.

Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Link: https://lore.kernel.org/r/20200512061525.133985-2-jian-hong@endlessm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Enable headset mic of ASUS GL503VM with ALC295
Chris Chiu [Tue, 12 May 2020 06:15:24 +0000 (14:15 +0800)]
ALSA: hda/realtek - Enable headset mic of ASUS GL503VM with ALC295

The ASUS laptop GL503VM with ALC295 can't detect the headset microphone.
The headset microphone does not work until pin 0x19 is enabled for it.

Signed-off-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Link: https://lore.kernel.org/r/20200512061525.133985-1-jian-hong@endlessm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-motu: fulfill missing entries in Kconfig
Takashi Sakamoto [Mon, 11 May 2020 02:25:40 +0000 (11:25 +0900)]
ALSA: firewire-motu: fulfill missing entries in Kconfig

This is trivial commit but fulfill missing entries in Kconfig for devices
supported by ALSA firewire-motu driver.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200511022540.161363-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: fireface: add support for RME Fireface UFX (untested)
Takashi Sakamoto [Sun, 10 May 2020 07:43:01 +0000 (16:43 +0900)]
ALSA: fireface: add support for RME Fireface UFX (untested)

Fireface UFX was shipped by RME GmbH in 2010, and now discontinued.
Although this model has some enhanced feature which Fireface 802
doesn't have (e.g. on-board USB mass storage device class, configuration
interface with color display), the functionality relevant to
packet communication on IEEE 1394 bus seems to be the same as
Fireface 802 (e.g. available number of channels for PCM frame in
each sampling transfer frequency).

With the assumption, this commit adds support for Fireface UFX. In ALSA
fireface driver, these two models are handled as the same one.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: fireface: add support for RME FireFace 802
Takashi Sakamoto [Sun, 10 May 2020 07:43:00 +0000 (16:43 +0900)]
ALSA: fireface: add support for RME FireFace 802

Fireface 802 was shipped by RME GmbH in 2014. This model supports later
protocol for management of isochronous communication and synchronization
of sampling transmission frequency.

This model consists of below ICs:
 * TI TSB41AB2
 * Xilinx Spartan-6 FPGA XC6SLX16
 * TI TMS320 C6747
 * SMSC USB3250

Especially, this model just supports IEEE 1394a, against its name which
evokes Fireface 800.

This commit adds support for Fireface 802 (tested). Userspace applications
can transfer PCM frames and MIDI messages via ALSA PCM/Rawmidi interface.
I note that 4 channels for ADAt1 and ADAT2 are disabled at higher sampling
transfer frequency since isochronous resources reservation fails due to
bandwidth limitation of IEEE 1394a.

The value read from LATTER_SYNC_STATUS register is slightly different
from the one of Fireface UCX. The higher 4 bits and lower 4 bits are
swapped within the same byte.

Without any assist of userspace application, transmitted MIDI messages
from the device are not going to be processed. For detail, please refer
to my comment in code of latter protocol.

$ python crpp < /sys/bus/firewire/devices/fw1/config_rom
               ROM header and bus information block
               -----------------------------------------------------------------
400  0404ffff  bus_info_length 4, crc_length 4, crc 65535 (should be 26805)
404  31333934  bus_name "1394"
408  20008000  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 8 (512)
40c  000a3504  company_id 000a35     |
410  38077423  device_id 0438077423  | EUI-64 000a350438077423

               root directory
               -----------------------------------------------------------------
414  0005ffff  directory_length 5, crc 65535 (should be 9514)
418  0c0083c0  node capabilities per IEEE 1394
41c  03000a35  vendor
420  8100000b  --> descriptor leaf at 44c
424  8d000007  --> eui-64 leaf at 440
428  d1000001  --> unit directory at 42c

               unit directory at 42c
               -----------------------------------------------------------------
42c  0004ffff  directory_length 4, crc 65535 (should be 45134)
430  12000a35  specifier id
434  13000005  version
438  17101800  model
43c  81000008  --> descriptor leaf at 45c

               eui-64 leaf at 440
               -----------------------------------------------------------------
440  0002ffff  leaf_length 2, crc 65535 (should be 60131)
444  000a3504  company_id 000a35     |
448  38077423  device_id 0438077423  | EUI-64 000a350438077423

               descriptor leaf at 44c
               -----------------------------------------------------------------
44c  0003ffff  leaf_length 3, crc 65535 (should be 469)
450  00000000  textual descriptor
454  00000000  minimal ASCII
458  524d4521  "RME!"

               descriptor leaf at 45c
               -----------------------------------------------------------------
45c  0005ffff  leaf_length 5, crc 65535 (should be 10561)
460  00000000  textual descriptor
464  00000000  minimal ASCII
468  46697265  "Fire"
46c  66616365  "face"
470  20383032  " 802"

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: fireface: code refactoring to decide name of sound card
Takashi Sakamoto [Sun, 10 May 2020 07:42:59 +0000 (16:42 +0900)]
ALSA: fireface: code refactoring to decide name of sound card

This commit uses enumeration constants as index of table for the
list of name of sound card.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: fireface: code refactoring to add enumeration constants for model identification
Takashi Sakamoto [Sun, 10 May 2020 07:42:58 +0000 (16:42 +0900)]
ALSA: fireface: code refactoring to add enumeration constants for model identification

In RME fireface series, version field of unit directory in configuration
ROM is used to distinguish each model. The value of field is known and
it's better to use enumeration constants for code representation.

This commit adds enumeration constants for model identification.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: fireface: start IR context immediately
Takashi Sakamoto [Sun, 10 May 2020 07:42:57 +0000 (16:42 +0900)]
ALSA: fireface: start IR context immediately

In the latter models of RME Fireface series, device start to transfer
packets several dozens of milliseconds. On the other hand, ALSA fireface
driver starts IR context 2 milliseconds after the start. This results
in loss to handle incoming packets on the context.

This commit changes to start IR context immediately instead of
postponement. For Fireface 800, this affects nothing because the device
transfer packets 100 milliseconds or so after the start and this is
within wait timeout.

Cc: <stable@vger.kernel.org>
Fixes: acfedcbe1ce4 ("ALSA: firewire-lib: postpone to start IR context")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: fireface: fix configuration error for nominal sampling transfer frequency
Takashi Sakamoto [Sun, 10 May 2020 07:42:56 +0000 (16:42 +0900)]
ALSA: fireface: fix configuration error for nominal sampling transfer frequency

128000 and 192000 are congruence modulo 32000, thus it's wrong to
distinguish them as multiple of 32000 and 48000 by modulo 32000 at
first.

Additionally, used condition statement to detect quadruple speed can
cause missing bit flag.

Furthermore, counter to ensure the configuration is wrong and it
causes false positive.

This commit fixes the above three bugs.

Cc: <stable@vger.kernel.org>
Fixes: 60aec494b389 ("ALSA: fireface: support allocate_resources operation in latter protocol")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek: Add quirk for Samsung Notebook
Mike Pozulp [Sun, 10 May 2020 03:28:37 +0000 (20:28 -0700)]
ALSA: hda/realtek: Add quirk for Samsung Notebook

Some models of the Samsung Notebook 9 have very quiet and distorted
headphone output. This quirk changes the VREF value of the ALC298
codec NID 0x1a from default HIZ to new 100.

[ adjusted to 5.7-base and rearranged in SSID order -- tiwai ]

Signed-off-by: Mike Pozulp <pozulp.kernel@gmail.com>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423
Link: https://lore.kernel.org/r/20200510032838.1989130-1-pozulp.kernel@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: use sequence of syt offset and data block on pool in AMDTP domain
Takashi Sakamoto [Fri, 8 May 2020 04:36:35 +0000 (13:36 +0900)]
ALSA: firewire-lib: use sequence of syt offset and data block on pool in AMDTP domain

In previous commit, the sequence of syt offset and the number of data
blocks per packet is calculated for pool in AMDTP domain structure in
advance of processing outgoing packets.

This commit uses the sequence for outgoing packet processing to obsolete
per-stream processing of the sequence.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-11-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: pool ideal sequence of syt offset and data block
Takashi Sakamoto [Fri, 8 May 2020 04:36:34 +0000 (13:36 +0900)]
ALSA: firewire-lib: pool ideal sequence of syt offset and data block

In current implementation, sequence of syt offset and the number of data
blocks is generated when packets for outgoing stream are going to be
queued.

This commit generates and pools the sequence independently of the
processing of outgoing packets for future extension.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: add cache for packet sequence to AMDTP domain structure
Takashi Sakamoto [Fri, 8 May 2020 04:36:33 +0000 (13:36 +0900)]
ALSA: firewire-lib: add cache for packet sequence to AMDTP domain structure

For future extension, storage is required to store packet sequence in
incoming AMDTP stream to recover media clock for outgoing AMDTP stream.

This commit adds the storage to AMDTP domain for this purpose. The
packet sequence is represented by 'struct seq_desc' which has two
members; syt_offset and the number of data blocks. The size of storage
is decided according to the size of packet queue.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: code refactoring for data block calculation
Takashi Sakamoto [Fri, 8 May 2020 04:36:32 +0000 (13:36 +0900)]
ALSA: firewire-lib: code refactoring for data block calculation

When calculating the number of data blocks per packet, some states are
stored in AMDTP stream structure. This is inconvenient when reuse the
calculation from non-stream structure.

This commit applies refactoring to helper function for the calculation
so that the function doesn't touch AMDTP stream structure.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: code refactoring for syt offset calculation
Takashi Sakamoto [Fri, 8 May 2020 04:36:31 +0000 (13:36 +0900)]
ALSA: firewire-lib: code refactoring for syt offset calculation

When calculating syt offset, some states are stored in AMDTP stream
structure. This is inconvenient when reuse the calculation from
non-stream structure.

This commit applies refactoring to helper function for the calculation
so that the function doesn't touch AMDTP stream structure.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: code refactoring for syt computation
Takashi Sakamoto [Fri, 8 May 2020 04:36:30 +0000 (13:36 +0900)]
ALSA: firewire-lib: code refactoring for syt computation

In current implementation for outgoing AMDTP packet, the value of syt
field in CIP header is computed when calculating syt offset. For
future extension, it's convenient to split the computation and
calculation.

This commit splits them.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: code refactoring for parameters of packet queue and IRQ timing
Takashi Sakamoto [Fri, 8 May 2020 04:36:29 +0000 (13:36 +0900)]
ALSA: firewire-lib: code refactoring for parameters of packet queue and IRQ timing

Although the parameter for packet queue and IRQ timing is calculated when
AMDTP stream starts, the calculated parameters are the same between
streams in AMDTP domain.

This commit moves the calculation and decide the parameters when AMDTP
domain starts.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: add reference to domain structure from stream structure
Takashi Sakamoto [Fri, 8 May 2020 04:36:28 +0000 (13:36 +0900)]
ALSA: firewire-lib: add reference to domain structure from stream structure

In current implementation, AMDTP domain structure and AMDTP stream
structure has one way of reference from the former to the latter. For
future extension, bidirectional reference is needed.

This commit adds a member into stream structure to refer to domain
structure to which the stream belongs.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: use macro for maximum value of second in 1394 OHCI isoc descriptor
Takashi Sakamoto [Fri, 8 May 2020 04:36:27 +0000 (13:36 +0900)]
ALSA: firewire-lib: use macro for maximum value of second in 1394 OHCI isoc descriptor

In descriptor of isochronous context in 1394 OHCI, the field of second
has 3 bit, thus the maximum value is 8. The value is used for correct
cycle calculation.

This commit replaces hard-coded value with macro to obsolete magic
number.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: fix invalid assignment to union data for directional parameter
Takashi Sakamoto [Fri, 8 May 2020 04:36:26 +0000 (13:36 +0900)]
ALSA: firewire-lib: fix invalid assignment to union data for directional parameter

Although the value of FDF is used just for outgoing stream, the assignment
to union member is done for both directions of stream. At present this
causes no issue because the value of same position is reassigned later for
opposite stream. However, it's better to add if statement.

Fixes: d3d10a4a1b19 ("ALSA: firewire-lib: use union for directional parameters")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: fireworks: Replace zero-length array with flexible-array
Gustavo A. R. Silva [Thu, 7 May 2020 18:52:45 +0000 (13:52 -0500)]
ALSA: fireworks: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200507185245.GA14270@embeddedor
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: Replace zero-length array with flexible-array
Gustavo A. R. Silva [Thu, 7 May 2020 19:22:23 +0000 (14:22 -0500)]
ALSA: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507192223.GA16335@embeddedor
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: rawmidi: Fix racy buffer resize under concurrent accesses
Takashi Iwai [Thu, 7 May 2020 11:44:56 +0000 (13:44 +0200)]
ALSA: rawmidi: Fix racy buffer resize under concurrent accesses

The rawmidi core allows user to resize the runtime buffer via ioctl,
and this may lead to UAF when performed during concurrent reads or
writes: the read/write functions unlock the runtime lock temporarily
during copying form/to user-space, and that's the race window.

This patch fixes the hole by introducing a reference counter for the
runtime buffer read/write access and returns -EBUSY error when the
resize is performed concurrently against read/write.

Note that the ref count field is a simple integer instead of
refcount_t here, since the all contexts accessing the buffer is
basically protected with a spinlock, hence we need no expensive atomic
ops.  Also, note that this busy check is needed only against read /
write functions, and not in receive/transmit callbacks; the race can
happen only at the spinlock hole mentioned in the above, while the
whole function is protected for receive / transmit callbacks.

Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAFcO6XMWpUVK_yzzCpp8_XP7+=oUpQvuBeCbMffEDkpe8jWrfg@mail.gmail.com
Link: https://lore.kernel.org/r/s5heerw3r5z.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Allow SST driver on SKL and KBL platforms with DMIC
Cezary Rojewski [Wed, 6 May 2020 20:39:51 +0000 (22:39 +0200)]
ALSA: hda: Allow SST driver on SKL and KBL platforms with DMIC

Update intel-dspcfg with FLAG_SST_ONLY_IF_DMIC option and use it for
Skylake and Kabylake platforms when DMIC is present.

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200506203951.6369-1-cezary.rojewski@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: portman2x4: Use bitwise instead of arithmetic operator for flags
Samuel Zou [Thu, 7 May 2020 06:48:55 +0000 (14:48 +0800)]
ALSA: portman2x4: Use bitwise instead of arithmetic operator for flags

Fix the following coccinelle warning:

sound/drivers/portman2x4.c:460:34-35: WARNING: sum of probable bitmasks, consider |

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1588834135-14842-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: sound/ppc: Use bitwise instead of arithmetic operator for flags
Samuel Zou [Thu, 7 May 2020 03:54:07 +0000 (11:54 +0800)]
ALSA: sound/ppc: Use bitwise instead of arithmetic operator for flags

Fix the following coccinelle warnings:

sound/ppc/pmac.c:729:57-58: WARNING: sum of probable bitmasks, consider |
sound/ppc/pmac.c:229:37-38: WARNING: sum of probable bitmasks, consider |

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1588823647-12480-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Return true,false for return type bool
Jason Yan [Wed, 6 May 2020 06:17:16 +0000 (14:17 +0800)]
ALSA: hda: Return true,false for return type bool

Fix the following coccicheck warning:

include/sound/hdaudio.h:210:73-74: WARNING: return of 0/1 in function
'snd_hdac_is_in_pm' with return type bool
include/sound/hdaudio.h:211:76-77: WARNING: return of 0/1 in function
'snd_hdac_is_power_on' with return type bool

Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200506061716.19209-1-yanaijie@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Use hdac_to_hda_codec macro
Kai-Heng Feng [Tue, 5 May 2020 03:03:53 +0000 (11:03 +0800)]
ALSA: hda: Use hdac_to_hda_codec macro

Use hdac_to_hda_codec() instead of container_of().

No functional change intended.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200505030357.28004-2-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Use dev_to_hdac_dev macro
Kai-Heng Feng [Tue, 5 May 2020 03:03:52 +0000 (11:03 +0800)]
ALSA: hda: Use dev_to_hdac_dev macro

Use dev_to_hdac_dev() instead of container_of().

No functional change intended.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200505030357.28004-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/tegra: workaround playback failure on Tegra194
Sameer Pujar [Mon, 4 May 2020 08:16:16 +0000 (13:46 +0530)]
ALSA: hda/tegra: workaround playback failure on Tegra194

Tegra194 has 4 SDO lines and with this configuration playback fails
for 44.1K/48K, 2-channel and 16-bps. It results in below print,
  "aplay: pcm_write:2011: write error: Input/output error"

Below relation is used to derive stripe control and is referenced
from HD Audio Specification: Revision 1.0a.
  { ((num_channels * bits_per_sample) / number of SDOs) >= 8 }

Due to a legacy HW design problem, playback issue is hit while using
a stripe value resulting from above formula when ratio is '8'. Thus
it is recommended that the ratio must be greater than '8'. Since the
number of SDO lines is in powers of 2, next available ratio '16' is
used as a limiting factor on Tegra194 to workaround the problem.

Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-4-git-send-email-spujar@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: add member to store ratio for stripe control
Sameer Pujar [Mon, 4 May 2020 08:16:15 +0000 (13:46 +0530)]
ALSA: hda: add member to store ratio for stripe control

Stripe control programming is governed by following formula, which is
referenced from the HD Audio specification(Revision 1.0a).
  { ((num_channels * bits_per_sample) / number of SDOs) >= 8 }

Currently above is implemented in snd_hdac_get_stream_stripe_ctl().
This patch introduces a structure member to store the default factor
of '8'. If any HW wants to use a different value, this member can be
easily updated.

Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-3-git-send-email-spujar@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/tegra: correct number of SDO lines for Tegra194
Sameer Pujar [Mon, 4 May 2020 08:16:14 +0000 (13:46 +0530)]
ALSA: hda/tegra: correct number of SDO lines for Tegra194

Tegra194 supports 4 SDO lines but GCAP register indicates 2 lines. Thus it
does not reflect the true capability of the HW. This patch presents a
workaround by updating NSDO value accordingly in T_AZA_DBG_CFG_2 register.

Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-2-git-send-email-spujar@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: add mapping for ASRock TRX40 Creator
Andrew Oakley [Sun, 3 May 2020 14:16:39 +0000 (15:16 +0100)]
ALSA: usb-audio: add mapping for ASRock TRX40 Creator

This is another TRX40 based motherboard with ALC1220-VB USB-audio
that requires a static mapping table.

This motherboard also has a PCI device which advertises no codecs.  The
PCI ID is 1022:1487 and PCI SSID is 1022:d102.  As this is using the AMD
vendor ID, don't blacklist for now in case other boards have a working
audio device with the same ssid.

alsa-info.sh report for this board:
http://alsa-project.org/db/?f=0a742f89066527497b77ce16bca486daccf8a70c

Signed-off-by: Andrew Oakley <andrew@adoakley.name>
Link: https://lore.kernel.org/r/20200503141639.35519-1-andrew@adoakley.name
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Fix S3 pop noise on Dell Wyse
Kai-Heng Feng [Sun, 3 May 2020 15:24:47 +0000 (23:24 +0800)]
ALSA: hda/realtek - Fix S3 pop noise on Dell Wyse

Commit 317d9313925c ("ALSA: hda/realtek - Set default power save node to
0") makes the ALC225 have pop noise on S3 resume and cold boot.

The previous fix enable power save node universally for ALC225, however
it makes some ALC225 systems unable to produce any sound.

So let's only enable power save node for the affected Dell Wyse
platform.

Fixes: 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0")
BugLink: https://bugs.launchpad.net/bugs/1866357
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200503152449.22761-2-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoRevert "ALSA: hda/realtek: Fix pop noise on ALC225"
Kai-Heng Feng [Sun, 3 May 2020 15:24:46 +0000 (23:24 +0800)]
Revert "ALSA: hda/realtek: Fix pop noise on ALC225"

This reverts commit 3b36b13d5e69d6f51ff1c55d1b404a74646c9757.

Enable power save node breaks some systems with ACL225. Revert the patch
and use a platform specific quirk for the original issue isntead.

Fixes: 3b36b13d5e69 ("ALSA: hda/realtek: Fix pop noise on ALC225")
BugLink: https://bugs.launchpad.net/bugs/1875916
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200503152449.22761-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: firewire-lib: fix 'function sizeof not defined' error of tracepoints format
Takashi Sakamoto [Sun, 3 May 2020 04:57:18 +0000 (13:57 +0900)]
ALSA: firewire-lib: fix 'function sizeof not defined' error of tracepoints format

The snd-firewire-lib.ko has 'amdtp-packet' event of tracepoints. Current
printk format for the event includes 'sizeof(u8)' macro expected to be
extended in compilation time. However, this is not done. As a result,
perf tools cannot parse the event for printing:

$ mount -l -t debugfs
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
$ cat /sys/kernel/debug/tracing/events/snd_firewire_lib/amdtp_packet/format
...
print fmt: "%02u %04u %04x %04x %02d %03u %02u %03u %02u %01u %02u %s",
  REC->second, REC->cycle, REC->src, REC->dest, REC->channel,
  REC->payload_quadlets, REC->data_blocks, REC->data_block_counter,
  REC->packet_index, REC->irq, REC->index,
  __print_array(__get_dynamic_array(cip_header),
                __get_dynamic_array_len(cip_header),
                sizeof(u8))

$ sudo perf record -e snd_firewire_lib:amdtp_packet
  [snd_firewire_lib:amdtp_packet] function sizeof not defined
  Error: expected type 5 but read 0

This commit fixes it by obsoleting the macro with actual size.

Cc: <stable@vger.kernel.org>
Fixes: bde2bbdb307a ("ALSA: firewire-lib: use dynamic array for CIP header of tracing events")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200503045718.86337-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: line6: Add poll callback for hwdep
Vasily Khoruzhick [Sat, 2 May 2020 19:31:20 +0000 (12:31 -0700)]
ALSA: line6: Add poll callback for hwdep

At least POD HD500 uses message-based communication, both sides can
send messages. Add poll callback so application can wait for device
messages without using busy loop.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://lore.kernel.org/r/20200502193120.79115-3-anarsoul@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: line6: hwdep: add support for O_NONBLOCK opening mode
Vasily Khoruzhick [Sat, 2 May 2020 19:31:19 +0000 (12:31 -0700)]
ALSA: line6: hwdep: add support for O_NONBLOCK opening mode

Currently line6 hwdep interface ignores O_NONBLOCK flag when
opening device and it renders it somewhat useless when using poll.

Check for O_NONBLOCK flag when opening device and don't block read()
if it is set.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://lore.kernel.org/r/20200502193120.79115-2-anarsoul@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Add control message quirk delay for Kingston HyperX headset
Jesus Ramos [Mon, 27 Apr 2020 13:21:39 +0000 (06:21 -0700)]
ALSA: usb-audio: Add control message quirk delay for Kingston HyperX headset

Kingston HyperX headset with 0951:16ad also needs the same quirk for
delaying the frequency controls.

Signed-off-by: Jesus Ramos <jesus-ramos@live.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/BY5PR19MB3634BA68C7CCA23D8DF428E796AF0@BY5PR19MB3634.namprd19.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: isa/wavefront: prevent out of bounds write in ioctl
Dan Carpenter [Fri, 1 May 2020 09:40:11 +0000 (12:40 +0300)]
ALSA: isa/wavefront: prevent out of bounds write in ioctl

The "header->number" comes from the ioctl and it needs to be clamped to
prevent out of bounds writes.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200501094011.GA960082@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Fix unused variable warning w/o CONFIG_LEDS_TRIGGER_AUDIO
Takashi Iwai [Fri, 1 May 2020 07:28:56 +0000 (09:28 +0200)]
ALSA: hda/realtek - Fix unused variable warning w/o CONFIG_LEDS_TRIGGER_AUDIO

Cover with a proper ifdef around the variable declaration for fixing
the following compilation warning without CONFIG_LEDS_TRIGGER_AUDIO:
  sound/pci/hda/patch_realtek.c: In function 'alc_fixup_hp_gpio_led':
  sound/pci/hda/patch_realtek.c:4134:6: warning: unused variable 'err' [-Wunused-variable]

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 87dc36482cab ("ALSA: hda/realtek - Add LED class support for micmute LED")
Link: https://lore.kernel.org/r/20200501072857.13720-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Add LED class support for micmute LED
Kai-Heng Feng [Thu, 30 Apr 2020 13:52:07 +0000 (21:52 +0800)]
ALSA: hda/realtek - Add LED class support for micmute LED

Currently DMIC controls micmute LED via "audio mute LED trigger".

However, unlike Dell and Lenovo platforms, HP platforms don't provide a
way to control micmute LED via ACPI, it's controlled by HDA codec
instead.

So let's register an LED class for micmute so other subsystems like DMIC
can facilitate the codec-controlled LED.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430135209.14703-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Enable micmute LED on and HP system
Kai-Heng Feng [Thu, 30 Apr 2020 08:32:52 +0000 (16:32 +0800)]
ALSA: hda/realtek - Enable micmute LED on and HP system

Though the system uses DMIC, headset mic still uses the HDA, let's use
GPIO 0x1 to control the micmute LED.

The micmute LED GPIO has a different polarity to the mute LED GPIO, we
can use the newly added micmute_led_polarity to indicate that.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430083255.5093-2-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Introduce polarity for micmute LED GPIO
Kai-Heng Feng [Thu, 30 Apr 2020 08:32:51 +0000 (16:32 +0800)]
ALSA: hda/realtek - Introduce polarity for micmute LED GPIO

Currently mute LED and micmute LED share the same GPIO polarity.

So split the polarity for mute and micmute, in case they have different
polarities.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430083255.5093-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
Takashi Iwai [Thu, 30 Apr 2020 12:47:55 +0000 (14:47 +0200)]
ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID

The USB vendor ID of NuPrime DAC-10 is not 16b0 but 16d0.

Fixes: f656891c6619 ("ALSA: usb-audio: add more quirks for DSD interfaces")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200430124755.15940-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: opti9xx: shut up gcc-10 range warning
Arnd Bergmann [Wed, 29 Apr 2020 19:02:03 +0000 (21:02 +0200)]
ALSA: opti9xx: shut up gcc-10 range warning

gcc-10 points out a few instances of suspicious integer arithmetic
leading to value truncation:

sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure':
sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
  322 |   (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask)))
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask'
  351 |   snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
      |   ^~~~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/miro.c: In function 'snd_miro_configure':
sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
  873 |   (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask)))
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask'
 1010 |   snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
      |   ^~~~~~~~~~~~~~~~~~~

These are all harmless here as only the low 8 bit are passed down
anyway. Change the macros to inline functions to make the code
more readable and also avoid the warning.

Strictly speaking those functions also need locking to make the
read/write pair atomic, but it seems unlikely that anyone would
still run into that issue.

Fixes: 1841f613fd2e ("[ALSA] Add snd-miro driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200429190216.85919-1-arnd@arndb.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: seq: oss: remove unused inline function snd_seq_oss_timer_is_realtime
YueHaibing [Wed, 29 Apr 2020 13:28:05 +0000 (21:28 +0800)]
ALSA: seq: oss: remove unused inline function snd_seq_oss_timer_is_realtime

There's no callers in-tree.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200429132805.18712-1-yuehaibing@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/hdmi: fix without unlocked before return
Wu Bo [Sun, 26 Apr 2020 13:17:22 +0000 (21:17 +0800)]
ALSA: hda/hdmi: fix without unlocked before return

Fix the following coccicheck warning:
sound/pci/hda/patch_hdmi.c:1852:2-8: preceding lock on line 1846

After add sanity check to pass klockwork check,
The spdif_mutex should be unlock before return true
in check_non_pcm_per_cvt().

Fixes: 960a581e22d9 ("ALSA: hda: fix some klockwork scan warnings")
Signed-off-by: Wu Bo <wubo40@huawei.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1587907042-694161-1-git-send-email-wubo40@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/hdmi: fix race in monitor detection during probe
Kai Vehmanen [Tue, 28 Apr 2020 12:38:36 +0000 (15:38 +0300)]
ALSA: hda/hdmi: fix race in monitor detection during probe

A race exists between build_pcms() and build_controls() phases of codec
setup. Build_pcms() sets up notifier for jack events. If a monitor event
is received before build_controls() is run, the initial jack state is
lost and never reported via mixer controls.

The problem can be hit at least with SOF as the controller driver. SOF
calls snd_hda_codec_build_controls() in its workqueue-based probe and
this can be delayed enough to hit the race condition.

Fix the issue by invalidating the per-pin ELD information when
build_controls() is called. The existing call to hdmi_present_sense()
will update the ELD contents. This ensures initial monitor state is
correctly reflected via mixer controls.

BugLink: https://github.com/thesofproject/linux/issues/1687
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200428123836.24512-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
Hui Wang [Mon, 27 Apr 2020 03:00:39 +0000 (11:00 +0800)]
ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter

This new Lenovo ThinkCenter has two front mics which can't be handled
by PA so far, so apply the fixup ALC283_FIXUP_HEADSET_MIC to change
the location for one of the mics.

Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20200427030039.10121-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: line6: Fix POD HD500 audio playback
Vasily Khoruzhick [Sat, 25 Apr 2020 20:11:15 +0000 (13:11 -0700)]
ALSA: line6: Fix POD HD500 audio playback

Apparently interface 1 is control interface akin to HD500X,
setting LINE6_CAP_CONTROL and choosing it as ctrl_if fixes
audio playback on POD HD500.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200425201115.3430-1-anarsoul@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoMerge branch 'topic/pcm-oss-fix' into for-linus
Takashi Iwai [Fri, 24 Apr 2020 19:39:26 +0000 (21:39 +0200)]
Merge branch 'topic/pcm-oss-fix' into for-linus

An empty merge of PCM OSS fix for 5.6 code base.
The fix for 5.7 was already applied.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: pcm: oss: Place the plugin buffer overflow checks correctly (for 5.7)
Takashi Iwai [Fri, 24 Apr 2020 19:38:43 +0000 (21:38 +0200)]
ALSA: pcm: oss: Place the plugin buffer overflow checks correctly (for 5.7)

[ This is again a forward-port of the fix applied for 5.6-base code
  (commit 4285de0725b1) to 5.7-base, hence neither Fixes nor
  Cc-to-stable tags are included here -- tiwai ]

The checks of the plugin buffer overflow in the previous fix by commit
  f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
are put in the wrong places mistakenly, which leads to the expected
(repeated) sound when the rate plugin is involved.  Fix in the right
places.

Also, at those right places, the zero check is needed for the
termination node, so added there as well, and let's get it done,
finally.

Link: https://lore.kernel.org/r/20200424193843.20397-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: pcm: oss: Place the plugin buffer overflow checks correctly
Takashi Iwai [Fri, 24 Apr 2020 19:33:50 +0000 (21:33 +0200)]
ALSA: pcm: oss: Place the plugin buffer overflow checks correctly

The checks of the plugin buffer overflow in the previous fix by commit
  f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
are put in the wrong places mistakenly, which leads to the expected
(repeated) sound when the rate plugin is involved.  Fix in the right
places.

Also, at those right places, the zero check is needed for the
termination node, so added there as well, and let's get it done,
finally.

Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200424193350.19678-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Fix racy list management in output queue
Takashi Iwai [Fri, 24 Apr 2020 07:40:16 +0000 (09:40 +0200)]
ALSA: usb-audio: Fix racy list management in output queue

The linked list entry from FIFO is peeked at
queue_pending_output_urbs() but the actual element pop-out is
performed outside the spinlock, and it's potentially racy.

Do delete the link at the right place inside the spinlock.

Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model")
Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Remove async workaround for Scarlett 2nd gen
Alexander Tsoy [Fri, 24 Apr 2020 02:24:49 +0000 (05:24 +0300)]
ALSA: usb-audio: Remove async workaround for Scarlett 2nd gen

Frame size computation has been fixed and the workaround is no longer
needed.

Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200424022449.14972-2-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Improve frames size computation
Alexander Tsoy [Fri, 24 Apr 2020 02:24:48 +0000 (05:24 +0300)]
ALSA: usb-audio: Improve frames size computation

For computation of the the next frame size current value of fs/fps and
accumulated fractional parts of fs/fps are used, where values are stored
in Q16.16 format. This is quite natural for computing frame size for
asynchronous endpoints driven by explicit feedback, since in this case
fs/fps is a value provided by the feedback endpoint and it's already in
the Q format. If an error is accumulated over time, the device can
adjust fs/fps value to prevent buffer overruns/underruns.

But for synchronous endpoints the accuracy provided by these computations
is not enough. Due to accumulated error the driver periodically produces
frames with incorrect size (+/- 1 audio sample).

This patch fixes this issue by implementing a different algorithm for
frame size computation. It is based on accumulating of the remainders
from division fs/fps and it doesn't accumulate errors over time. This
new method is enabled for synchronous and adaptive playback endpoints.

Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoMerge branch 'for-linus' into for-next
Takashi Iwai [Fri, 24 Apr 2020 06:24:39 +0000 (08:24 +0200)]
Merge branch 'for-linus' into for-next

Back-merge 5.7-rc devel branch for further changes.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Match both PCI ID and SSID for driver blacklist
Takashi Iwai [Fri, 24 Apr 2020 06:12:22 +0000 (08:12 +0200)]
ALSA: hda: Match both PCI ID and SSID for driver blacklist

The commit 3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist") added a
new blacklist for the devices that are known to have empty codecs, and
one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f).
However, it turned out that the very same PCI SSID is used for the
previous model that does have the valid HD-audio codecs and the change
broke the sound on it.

Since the empty codec problem appear on the certain AMD platform (PCI
ID 1022:1487), this patch changes the blacklist matching to both PCI
ID and SSID using pci_match_id().  Also, the entry that was removed by
the previous fix for ASUS ROG Zenigh II is re-added.

Link: https://lore.kernel.org/r/20200424061222.19792-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoMerge branch 'topic/nhlt' into for-next
Takashi Iwai [Fri, 24 Apr 2020 06:22:16 +0000 (08:22 +0200)]
Merge branch 'topic/nhlt' into for-next

Merge NHLT init cleanup.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Refactor Intel NHLT init
Cezary Rojewski [Thu, 23 Apr 2020 16:03:10 +0000 (18:03 +0200)]
ALSA: hda: Refactor Intel NHLT init

NHLT fetch based on _DSM prevents ACPI table override mechanism from
being utilized. Make use of acpi_get_table to enable it and get rid of
redundant code. In consequence, NHLT can be overridden just like any
other ACPI table, e.g.: DSDT or SSDT.

Change has been verified on all Intel AVS architecture platforms, RVP
and production laptops both.

Change possible due to addition of NHLT signature to the list of
standard ACPI tables:
https://patchwork.kernel.org/patch/11463235/

Override helps not only with debug purposes but also allows user for
table adjustment when one found on their production hardware is invalid.
Shared official NHLT spec is now available to community at:
https://01.org/blogs/intel-smart-sound-technology-audio-dsp

NHLT support for iASL is still ongoing subject but should be available
in nearest future.

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200423160310.28019-1-cezary.rojewski@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda: Always use jackpoll helper for jack update after resume
Takashi Iwai [Wed, 22 Apr 2020 20:37:44 +0000 (22:37 +0200)]
ALSA: hda: Always use jackpoll helper for jack update after resume

HD-audio codec driver applies a tricky procedure to forcibly perform
the runtime resume by mimicking the usage count even if the device has
been runtime-suspended beforehand.  This was needed to assure to
trigger the jack detection update after the system resume.

And recently we also applied the similar logic to the HD-audio
controller side.  However this seems leading to some inconsistency,
and eventually PCI controller gets screwed up.

This patch is an attempt to fix and clean up those behavior: instead
of the tricky runtime resume procedure, the existing jackpoll work is
scheduled when such a forced codec resume is required.  The jackpoll
work will power up the codec, and this alone should suffice for the
jack status update in usual cases.  If the extra polling is requested
(by checking codec->jackpoll_interval), the manual update is invoked
after that, and the codec is powered down again.

Also, we filter the spurious wake up of the codec from the controller
runtime resume by checking codec->relaxed_resume flag.  If this flag
is set, basically we don't need to wake up explicitly, but it's
supposed to be done via the audio component notifier.

Fixes: c4c8dd6ef807 ("ALSA: hda: Skip controller resume if not needed")
Link: https://lore.kernel.org/r/20200422203744.26299-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: hda/realtek - Add new codec supported for ALC245
Kailang Yang [Thu, 23 Apr 2020 06:18:31 +0000 (14:18 +0800)]
ALSA: hda/realtek - Add new codec supported for ALC245

Enable new codec supported for ALC245.

Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/8c0804738b2c42439f59c39c8437817f@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Fix usb audio refcnt leak when getting spdif
Xiyu Yang [Thu, 23 Apr 2020 04:54:19 +0000 (12:54 +0800)]
ALSA: usb-audio: Fix usb audio refcnt leak when getting spdif

snd_microii_spdif_default_get() invokes snd_usb_lock_shutdown(), which
increases the refcount of the snd_usb_audio object "chip".

When snd_microii_spdif_default_get() returns, local variable "chip"
becomes invalid, so the refcount should be decreased to keep refcount
balanced.

The reference counting issue happens in several exception handling paths
of snd_microii_spdif_default_get(). When those error scenarios occur
such as usb_ifnum_to_if() returns NULL, the function forgets to decrease
the refcnt increased by snd_usb_lock_shutdown(), causing a refcnt leak.

Fix this issue by jumping to "end" label when those error scenarios
occur.

Fixes: 447d6275f0c2 ("ALSA: usb-audio: Add sanity checks for endpoint accesses")
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1587617711-13200-1-git-send-email-xiyuyang19@fudan.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Add connector notifier delegation
Takashi Iwai [Wed, 22 Apr 2020 11:33:20 +0000 (13:33 +0200)]
ALSA: usb-audio: Add connector notifier delegation

It turned out that ALC1220-VB USB-audio device gives the interrupt
event to some PCM terminals while those don't allow the connector
state request but only the actual I/O terminals return the request.
The recent commit 7dc3c5a0172e ("ALSA: usb-audio: Don't create jack
controls for PCM terminals") excluded those phantom terminals, so
those events are ignored, too.

My first thought was that this could be easily deduced from the
associated terminals, but some of them have even no associate terminal
ID, hence it's not too trivial to figure out.

Since the number of such terminals are small and limited, this patch
implements another quirk table for the simple mapping of the
connectors.  It's not really scalable, but let's hope that there will
be not many such funky devices in future.

Fixes: 7dc3c5a0172e ("ALSA: usb-audio: Don't create jack controls for PCM terminals")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873
Link: https://lore.kernel.org/r/20200422113320.26664-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: oxygen: use true,false for bool variables
Jason Yan [Wed, 22 Apr 2020 07:16:46 +0000 (15:16 +0800)]
ALSA: oxygen: use true,false for bool variables

Fix the following coccicheck warning:

sound/pci/oxygen/xonar_pcm179x.c:463:1-17: WARNING: Assignment of 0/1 to
bool variable
sound/pci/oxygen/xonar_pcm179x.c:505:1-17: WARNING: Assignment of 0/1 to
bool variable

Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200422071646.48436-1-yanaijie@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
4 years agoALSA: usb-audio: Fix a limit check in proc_dump_substream_formats()
Dan Carpenter [Wed, 22 Apr 2020 09:22:55 +0000 (12:22 +0300)]
ALSA: usb-audio: Fix a limit check in proc_dump_substream_formats()

This should be ARRAY_SIZE() instead of sizeof().  The sizeof() limit is
too high so it doesn't work.

Fixes: 093b8494f299 ("ALSA: usb-audio: Print more information in stream proc files")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200422092255.GB195357@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>