OSDN Git Service
Takashi Iwai [Tue, 8 Jun 2021 14:05:32 +0000 (16:05 +0200)]
ALSA: sparc: Fix assignment in if condition
SPARC drivers contain a few assignments in if condition, which is a
bad coding style that may confuse readers and occasionally lead to
bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-59-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:31 +0000 (16:05 +0200)]
ALSA: pcmcia: Fix assignment in if condition
PCMCIA VX222 and PDAudioCF drivers contain a few assignments in if
condition, which is a bad coding style that may confuse readers and
occasionally lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-58-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:30 +0000 (16:05 +0200)]
ALSA: seq: Fix assignment in if condition
There are lots of places doing assignments in if condition in ALSA
sequencer core, which is a bad coding style that may confuse readers
and occasionally lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-57-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:29 +0000 (16:05 +0200)]
ALSA: oss: Fix assignment in if condition
There are a few places doing assignments in if condition in ALSA PCM
and OSS emulation layers, which is a bad coding style that may confuse
readers and occasionally lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-56-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:28 +0000 (16:05 +0200)]
ALSA: pcm: Fix assignment in if condition
There are a few places doing assignments in if condition in ALSA PCM
core code, which is a bad coding style that may confuse readers and
occasionally lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-55-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:27 +0000 (16:05 +0200)]
ALSA: core: Fix assignment in if condition
There are a few places doing assignments in if condition in ALSA core
code, which is a bad coding style that may confuse readers and
occasionally lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-54-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:26 +0000 (16:05 +0200)]
ALSA: ymfpci: Fix assignment in if condition
PCI YMFPCI driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-53-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:25 +0000 (16:05 +0200)]
ALSA: vx222: Fix assignment in if condition
PCI VX222 driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-52-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:24 +0000 (16:05 +0200)]
ALSA: trident: Fix assignment in if condition
PCI Trident driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-51-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:23 +0000 (16:05 +0200)]
ALSA: rme9652: Fix assignment in if condition
PCI RME9652 driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-50-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:22 +0000 (16:05 +0200)]
ALSA: hdsp: Fix assignment in if condition
PCI HDSP driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-49-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:21 +0000 (16:05 +0200)]
ALSA: riptide: Fix assignment in if condition
PCI riptide driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-48-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:20 +0000 (16:05 +0200)]
ALSA: pcxhr: Fix assignment in if condition
PCI PCXHR driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-47-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:19 +0000 (16:05 +0200)]
ALSA: nm256: Fix assignment in if condition
PCI NM256 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-46-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:18 +0000 (16:05 +0200)]
ALSA: mixart: Fix assignment in if condition
PCI miXart driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-45-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:17 +0000 (16:05 +0200)]
ALSA: korg1212: Fix assignment in if condition
PCI Korg1212 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-44-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:16 +0000 (16:05 +0200)]
ALSA: ice1712: Fix assignment in if condition
PCI ICE1712 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-43-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:15 +0000 (16:05 +0200)]
ALSA: emu10k1x: Fix assignment in if condition
PCI EMU10k1X driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-42-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:14 +0000 (16:05 +0200)]
ALSA: emu10k1: Fix assignment in if condition
PCI EMU10k1 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-41-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:13 +0000 (16:05 +0200)]
ALSA: echoaudio: Fix assignment in if condition
PCI echoaudio drivers contain a few assignments in if condition, which
is a bad coding style that may confuse readers and occasionally lead
to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-40-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:12 +0000 (16:05 +0200)]
ALSA: cs5535audio: Fix assignment in if condition
PCI CS5535 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-39-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:11 +0000 (16:05 +0200)]
ALSA: cs46xx: Fix assignment in if condition
PCI CS46xx driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-38-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:10 +0000 (16:05 +0200)]
ALSA: ca0106: Fix assignment in if condition
PCI CA0106 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-37-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:09 +0000 (16:05 +0200)]
ALSA: au88x0: Fix assignment in if condition
PCI AU88x0 driver code contains a lot of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes. A potential real fix is
about the PCI AGP bridge management refcount in addition while spotted
out during conversions.
Link: https://lore.kernel.org/r/20210608140540.17885-36-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:08 +0000 (16:05 +0200)]
ALSA: ac97: Fix assignment in if condition
AC97 codec driver code contains a lot of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-35-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:07 +0000 (16:05 +0200)]
ALSA: via82xx: Fix assignment in if condition
PCI VIA82xx driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-34-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:06 +0000 (16:05 +0200)]
ALSA: sonicvibes: Fix assignment in if condition
PCI sonicvibes driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-33-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:05 +0000 (16:05 +0200)]
ALSA: rme96: Fix assignment in if condition
PCI RME96 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes (only systematic
conversions except for a few rate handling codes), no functional
changes.
Link: https://lore.kernel.org/r/20210608140540.17885-32-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:04 +0000 (16:05 +0200)]
ALSA: rme32: Fix assignment in if condition
PCI RME32 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes (except for a slight
refactoring about AutoSync rate check, only systematic conversions),
no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-31-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:03 +0000 (16:05 +0200)]
ALSA: maestro3: Fix assignment in if condition
PCI maestro3 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-30-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:02 +0000 (16:05 +0200)]
ALSA: intel8x0: Fix assignment in if condition
PCI intel8x0 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-29-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:01 +0000 (16:05 +0200)]
ALSA: fm801: Fix assignment in if condition
PCI FM801 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-28-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:05:00 +0000 (16:05 +0200)]
ALSA: es1968: Fix assignment in if condition
PCI ES1968 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-27-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:59 +0000 (16:04 +0200)]
ALSA: es1938: Fix assignment in if condition
PCI ES1938 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:58 +0000 (16:04 +0200)]
ALSA: ens137x: Fix assignment in if condition
PCI ENS137x driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-25-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:57 +0000 (16:04 +0200)]
ALSA: cs4281: Fix assignment in if condition
PCI CS4281 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-24-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:56 +0000 (16:04 +0200)]
ALSA: cmipci: Fix assignment in if condition
PCI CMIPCI driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:55 +0000 (16:04 +0200)]
ALSA: bt87x: Fix assignment in if condition
PCI BT87x driver code contains an assignments in if condition, which
is a bad coding style that may confuse readers and occasionally lead
to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-22-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:54 +0000 (16:04 +0200)]
ALSA: azt3328: Fix assignment in if condition
PCI AZT3328 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-21-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:53 +0000 (16:04 +0200)]
ALSA: atiixp: Fix assignment in if condition
PCI ATIIXP driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-20-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:52 +0000 (16:04 +0200)]
ALSA: als4000: Fix assignment in if condition
PCI ALS4000 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-19-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:51 +0000 (16:04 +0200)]
ALSA: als300: Fix assignment in if condition
PCI ALS300 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-18-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:50 +0000 (16:04 +0200)]
ALSA: ak4531: Fix assignment in if condition
AK4531 codec driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-17-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:49 +0000 (16:04 +0200)]
ALSA: ad1889: Fix assignment in if condition
PCI AD1889 driver code contains a few assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-16-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:48 +0000 (16:04 +0200)]
ALSA: isa: Fix assignment in if condition
ISA ES1688 and WSS driver code contains a few assignments in if
condition, which is a bad coding style that may confuse readers and
occasionally lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-15-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:47 +0000 (16:04 +0200)]
ALSA: azt2320: Fix assignment in if condition
ISA AZT2320 driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-14-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:46 +0000 (16:04 +0200)]
ALSA: als100: Fix assignment in if condition
ISA ALS100 driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-13-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:45 +0000 (16:04 +0200)]
ALSA: cmi8330: Fix assignment in if condition
ISA CMI8330 driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-12-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:44 +0000 (16:04 +0200)]
ALSA: es18xx: Fix assignment in if condition
ISA ES18xx driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:43 +0000 (16:04 +0200)]
ALSA: opl3sa2: Fix assignment in if condition
ISA OPL3SA2 driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:42 +0000 (16:04 +0200)]
ALSA: opti9xx: Fix assignment in if condition
ISA Opti9xx driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:41 +0000 (16:04 +0200)]
ALSA: cs423x: Fix assignment in if condition
ISA CS423x driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:40 +0000 (16:04 +0200)]
ALSA: wavefront: Fix assignment in if condition
ISA WaveFront driver code contains lots of assignments in if
condition, which is a bad coding style that may confuse readers and
occasionally lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:39 +0000 (16:04 +0200)]
ALSA:
ad1816a: Fix assignment in if condition
ISA
AD1816A driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:38 +0000 (16:04 +0200)]
ALSA: gus: Fix assignment in if condition
ISA GUS driver code contains lots of assignments in if condition,
which is a bad coding style that may confuse readers and occasionally
lead to bugs.
This patch is merely for coding-style fixes, no functional changes.
Link: https://lore.kernel.org/r/20210608140540.17885-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:37 +0000 (16:04 +0200)]
ALSA: sb: Fix potential double-free of CSP mixer elements
snd_sb_qsound_destroy() contains the calls of removing the previously
created mixer controls, but it doesn't clear the pointers. As
snd_sb_qsound_destroy() itself may be repeatedly called via ioctl,
this could lead to double-free potentially.
Fix it by clearing the struct fields properly afterwards.
Link: https://lore.kernel.org/r/20210608140540.17885-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:36 +0000 (16:04 +0200)]
ALSA: sb: Minor coding style fixes
The handling of snd_ctl_new1() and snd_ctl_add() can be sometimes
tricky, as snd_ctl_add() automatically removes the passed object at
its error path. The recent fix addressed an overlooked issue that is
relevant with that in SB driver code, and it can be a bit more
simplified by assigning to a temporary variable, i.e. storing to the
struct field only after the creation succeeds.
Link: https://lore.kernel.org/r/20210608140540.17885-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 14:04:35 +0000 (16:04 +0200)]
ALSA: sb: Fix assignment in if condition
A lot of code for SB drivers is in a legacy style with assignment in
if condition. This also made harder to catch some bugs (e.g. the
commit
1c98f574403d "ALSA: emu8000: Fix a use after free in
snd_emu8000_create_mixer").
This patch fixes the coding style. All are rather simple conversions
and there should be no functional changes.
(The changes in snd_emu8000_new() for hw->res_port1, 2 and 3 are
slightly different from the older ones, but this shouldn't matter
much in practice.)
Link: https://lore.kernel.org/r/20210608140540.17885-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Geoffrey D. Bennett [Mon, 7 Jun 2021 19:13:51 +0000 (04:43 +0930)]
ALSA: usb-audio: scarlett2: Read mux at init time
Add support for retrieving the mux configuration from the hardware
when the driver is initialising. Previously the ALSA controls were
initialised to a default hard-coded state instead of being initialised
to match the hardware state.
Fixes:
9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
Suggested-by: Vladimir Sadovnikov <sadko4u@gmail.com>
Tested-by: Markus Schroetter <project.m.schroetter@gmail.com>
Tested-by: Alex Fellows <alex.fellows@gmail.com>
Tested-by: Daniel Sales <daniel.sales.z@gmail.com>
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Link: https://lore.kernel.org/r/15b17c60a2bca174bcddcec41c9419b746f21c1d.1623091570.git.g@b4.vu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Geoffrey D. Bennett [Mon, 7 Jun 2021 19:13:25 +0000 (04:43 +0930)]
ALSA: usb-audio: scarlett2: Read mixer volumes at init time
Add support for reading the mixer volumes from the hardware when the
driver is initialising. Previously these ALSA volume controls were
initialised to zero instead of being initialised to match the hardware
state.
Fixes:
9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
Suggested-by: Vladimir Sadovnikov <sadko4u@gmail.com>
Tested-by: Markus Schroetter <project.m.schroetter@gmail.com>
Tested-by: Alex Fellows <alex.fellows@gmail.com>
Tested-by: Daniel Sales <daniel.sales.z@gmail.com>
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Link: https://lore.kernel.org/r/bb33fa9b79efc6f7a0f0e6fb7018cc8d4d59b3ba.1623091570.git.g@b4.vu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 8 Jun 2021 12:02:06 +0000 (14:02 +0200)]
Merge branch 'for-linus' into for-next
Jeremy Szu [Tue, 8 Jun 2021 11:47:48 +0000 (19:47 +0800)]
ALSA: hda/realtek: fix mute/micmute LEDs for HP ZBook Power G8
The HP ZBook Power G8 using ALC236 codec which using 0x02 to
control mute LED and 0x01 to control micmute LED.
Therefore, add a quirk to make it works.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210608114750.32009-1-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Hui Wang [Tue, 8 Jun 2021 02:46:00 +0000 (10:46 +0800)]
ALSA: hda/realtek: headphone and mic don't work on an Acer laptop
There are 2 issues on this machine, the 1st one is mic's plug/unplug
can't be detected, that is because the mic is set to manual detecting
mode, need to apply ALC255_FIXUP_XIAOMI_HEADSET_MIC to set it to auto
detecting mode. The other one is headphone's plug/unplug can't be
detected by pulseaudio, that is because the pulseaudio will use
ucm2/sof-hda-dsp on this machine, and the ucm2 only handle
'Headphone Jack', but on this machine the headphone's pincfg sets the
location to Front, then the alsa mixer name is "Front Headphone Jack"
instead of "Headphone Jack", so override the pincfg to change location
to Left.
BugLink: http://bugs.launchpad.net/bugs/1930188
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20210608024600.6198-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:50 +0000 (17:12 +0900)]
ALSA: firewire-lib: delete unused kernel API
No driver use snd_fw_schedule_registration(). Let's delete it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:49 +0000 (17:12 +0900)]
ALSA: fireface: cease from delayed card registration
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:48 +0000 (17:12 +0900)]
ALSA: firewire-motu: cease from delayed card registration
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:47 +0000 (17:12 +0900)]
ALSA: firewire-tascam: cease from delayed card registration
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:46 +0000 (17:12 +0900)]
ALSA: firewire-digi00x: cease from delayed card registration
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:45 +0000 (17:12 +0900)]
ALSA: dice: cease from delayed card registration
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:44 +0000 (17:12 +0900)]
ALSA: oxfw: cease from delayed card registration
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:43 +0000 (17:12 +0900)]
ALSA: fireworks: cease from delayed card registration
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 7 Jun 2021 08:12:42 +0000 (17:12 +0900)]
ALSA: bebob: cease from delayed card registration
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sun, 6 Jun 2021 04:34:09 +0000 (13:34 +0900)]
ALSA: firewire-motu: add support for hybrid model of MOTU Ultralite mk3
This commit adds support for the hybrid model of MOTU Ultralite mk3 with
alpha connector, which is already discontinued. The hardware specification
of the model is the same as the one of FireWire-only model.
$ cd linux-firewire-utils
$ python3 src/crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400
04101573 bus_info_length 4, crc_length 16, crc 5491
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
000a059c device_id
00000a059c | EUI-64
0001f200000a059c
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
0003f00b directory_length 3, crc 61451
42c
120001f2 specifier id
430
13000030 version
434
17103800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438
0002d89c leaf_length 2, crc 55452
43c
0001f200 company_id 0001f2 |
440
000a059c device_id
00000a059c | EUI-64
0001f200000a059c
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210606043409.40019-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sun, 6 Jun 2021 02:56:51 +0000 (11:56 +0900)]
ALSA: firewire-lib: remove useless operations for kernel preemption
In all of drivers of ALSA firewire stack, the callback of .pointer and
.ack in snd_pcm_ops structure is done in acquired spin_lock of PCM
substream, therefore already under disabled kernel preemption.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210606025651.29970-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Dan Carpenter [Sat, 5 Jun 2021 12:46:39 +0000 (15:46 +0300)]
ALSA: firewire-lib: fix error codes for allocation failure
Return -ENOMEM if kcalloc() fails. Currently the code returns success.
Fixes:
f9e5ecdfc2c2 ("ALSA: firewire-lib: add replay target to cache sequence of packet")
Fixes:
6f24bb8a157c ("ALSA: firewire-lib: pool sequence of packet in IT context independently")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/YLtyL4VoArwVLor1@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sat, 5 Jun 2021 09:10:54 +0000 (18:10 +0900)]
ALSA: firewire-lib: fix the context to call snd_pcm_stop_xrun()
In the workqueue to queue wake-up event, isochronous context is not
processed, thus it's useless to check context for the workqueue to switch
status of runtime for PCM substream to XRUN. On the other hand, in
software IRQ context of 1394 OHCI, it's needed.
This commit fixes the bug introduced when tasklet was replaced with
workqueue.
Cc: <stable@vger.kernel.org>
Fixes:
2b3d2987d800 ("ALSA: firewire: Replace tasklet with work")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210605091054.68866-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Jeremy Szu [Sat, 5 Jun 2021 08:25:38 +0000 (16:25 +0800)]
ALSA: hda/realtek: fix mute/micmute LEDs for HP EliteBook 840 Aero G8
The HP EliteBook 840 Aero G8 using ALC285 codec which using 0x04 to
control mute LED and 0x01 to control micmute LED.
In the other hand, there is no output from right channel of speaker.
Therefore, add a quirk to make it works.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210605082539.41797-3-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Jeremy Szu [Sat, 5 Jun 2021 08:25:37 +0000 (16:25 +0800)]
ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP EliteBook x360 1040 G8
The HP EliteBook x360 1040 G8 using ALC285 codec which using 0x04 to control
mute LED and 0x01 to control micmute LED.
In the other hand, there is no output from right channel of speaker.
Therefore, add a quirk to make it works.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210605082539.41797-2-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Jeremy Szu [Sat, 5 Jun 2021 08:25:36 +0000 (16:25 +0800)]
ALSA: hda/realtek: fix mute/micmute LEDs and speaker for HP Elite Dragonfly G2
The HP Elite Dragonfly G2 using ALC285 codec which using 0x04 to control
mute LED and 0x01 to control micmute LED.
In the other hand, there is no output from right channel of speaker.
Therefore, add a quirk to make it works.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210605082539.41797-1-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Werner Sembach [Fri, 4 Jun 2021 14:02:07 +0000 (16:02 +0200)]
ALSA: hda/realtek: Change device names for quirks to barebone names
Change the name string of several devices needing quirks to the Clevo-barebone
ones. Also make the names follow the same pattern for multiple Clevo names
referring to the same mainboard.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://lore.kernel.org/r/20210604140207.8023-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Yang Yingliang [Thu, 3 Jun 2021 14:32:03 +0000 (22:32 +0800)]
ALSA: firewire-motu: fix error return code in snd_motu_stream_reserve_duplex()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes:
e50dfac81f73 ("ALSA: firewire-motu: cache event ticks in source packet header per data block")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210603143203.582017-1-yangyingliang@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Hui Wang [Wed, 2 Jun 2021 14:54:24 +0000 (22:54 +0800)]
ALSA: hda: update the power_state during the direct-complete
The patch_realtek.c needs to check if the power_state.event equals
PM_EVENT_SUSPEND, after using the direct-complete, the suspend() and
resume() will be skipped if the codec is already rt_suspended, in this
case, the patch_realtek.c will always get PM_EVENT_ON even the system
is really resumed from S3.
We could set power_state to PMSG_SUSPEND in the prepare(), if other
PM functions are called before complete(), those functions will
override power_state; if no other PM functions are called before
complete(), we could know the suspend() and resume() are skipped since
only S3 pm functions could be skipped by direct-complete, in this case
set power_state to PMSG_RESUME in the complete(). This could guarantee
the first time of calling hda_codec_runtime_resume() after complete()
has the correct power_state.
Fixes:
215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization")
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20210602145424.3132-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Wed, 2 Jun 2021 11:38:23 +0000 (13:38 +0200)]
ALSA: timer: Fix master timer notification
snd_timer_notify1() calls the notification to each slave for a master
event, but it passes a wrong event number. It should be +10 offset,
corresponding to SNDRV_TIMER_EVENT_MXXX, but it's incorrectly with
+100 offset. Casually this was spotted by UBSAN check via syzkaller.
Reported-by: syzbot+d102fa5b35335a7e544e@syzkaller.appspotmail.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/000000000000e5560e05c3bd1d63@google.com
Link: https://lore.kernel.org/r/20210602113823.23777-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Dongliang Mu [Wed, 2 Jun 2021 03:41:36 +0000 (11:41 +0800)]
ALSA: control led: fix memory leak in snd_ctl_led_register
The snd_ctl_led_sysfs_add and snd_ctl_led_sysfs_remove should contain
the refcount operations in pair. However, snd_ctl_led_sysfs_remove fails
to decrease the refcount to zero, which causes device_release never to
be invoked. This leads to memory leak to some resources, like struct
device_private. In addition, we also free some other similar memory
leaks in snd_ctl_led_init/snd_ctl_led_exit.
Fix this by replacing device_del to device_unregister
in snd_ctl_led_sysfs_remove/snd_ctl_led_init/snd_ctl_led_exit.
Note that, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device will
call kobject_release and delay the release of kobject, which will cause
use-after-free when the memory backing the kobject is freed at once.
Reported-by: syzbot+08a7d8b51ea048a74ffb@syzkaller.appspotmail.com
Fixes:
a135dfb5de15 ("ALSA: led control - add sysfs kcontrol LED marking layer")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210602034136.2762497-1-mudongliangabcd@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 1 Jun 2021 16:24:57 +0000 (18:24 +0200)]
ALSA: usb-audio: Reduce latency at playback start
USB-audio driver behaves a bit strangely for the playback stream --
namely, it starts sending silent packets at PCM prepare state while
the actual data is submitted at first when the trigger START is kicked
off. This is a workaround for the behavior where URBs are processed
too quickly at the beginning. That is, if we start submitting URBs at
trigger START, the first few URBs will be immediately completed, and
this would result in the immediate period-elapsed calls right after
the start, which may confuse applications.
OTOH, submitting the data after silent URBs would, of course, result
in a certain delay of the actual data processing, and this is rather
more serious problem on modern systems, in practice.
This patch tries to revert the workaround and lets the URB submission
starting at PCM trigger for the playback again. As far as I've tested
with various backends (native ALSA, PA, JACK, PW), I haven't seen any
problems (famous last words :)
Note that the capture stream handling needs no such workaround, since
the capture is driven per received URB.
Link: https://lore.kernel.org/r/20210601162457.4877-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 1 Jun 2021 16:24:56 +0000 (18:24 +0200)]
ALSA: usb-audio: Factor out DSD bitrev copy function
Just minor code refactoring. Like DOP DSD code, it can be better in a
separate function for code readability.
Link: https://lore.kernel.org/r/20210601162457.4877-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 1 Jun 2021 16:24:55 +0000 (18:24 +0200)]
ALSA: usb-audio: Refactoring delay account code
The PCM delay accounting in USB-audio driver is a bit complex to
follow, and this is an attempt to improve the readability and provide
some potential fix.
Basically, the PCM position delay is calculated from two factors: the
in-flight data on URBs and the USB frame counter. For the playback
stream, we advance the hwptr already at submitting URBs. Those
"in-flight" data amount is now tracked, and this is used as the base
value for the PCM delay correction. The in-flight data is decreased
again at URB completion in return. For the capture stream, OTOH,
there is no in-flight data, hence the delay base is zero.
The USB frame counter is used in addition for correcting the current
position. The reference frame counter is updated at each submission
and receiving time, and the difference from the current counter value
is taken into account.
In this patch, each in-flight data bytes is recorded in the new
snd_usb_ctx.queued field, and the total in-flight amount is tracked in
snd_usb_substream.inflight_bytes field, as the replacement of
last_delay field.
Note that updating the hwptr after URB completion doesn't work for
PulseAudio who tries to scratch the buffer on the fly; USB-audio is
basically a double-buffer implementation, hence the scratching the
buffer can't work for the already submitted data. So we always update
hwptr beforehand. It's not ideal, but the delay account should give
enough correctness.
Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 1 Jun 2021 16:24:54 +0000 (18:24 +0200)]
ALSA: usb-audio: Pre-calculate buffer byte size
There are a bunch of lines calculating the buffer size in bytes at
each time. Keep the value in subs->buffer_bytes and use it
consistently for the code simplicity.
Link: https://lore.kernel.org/r/20210601162457.4877-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 1 Jun 2021 16:24:53 +0000 (18:24 +0200)]
ALSA: usb-audio: Make snd_usb_pcm_delay() static
It's a local function, let's make it static.
Link: https://lore.kernel.org/r/20210601162457.4877-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Wed, 2 Jun 2021 01:34:06 +0000 (10:34 +0900)]
ALSA: firewire-motu: sequence replay for source packet header
This commit takes ALSA firewire-motu driver to perform sequence replay for
media clock recovery.
Unlike the other types of device, the devices in MOTU FireWire series
require two levels of sequence replay; the sequence of the number of
data blocks per packet and the sequence of source packet header per data
block. The former is already cached by ALSA IEC 61883-1/6 packet streaming
engine and ready to be replayed. The latter is also cached by ALSA
firewire-motu driver itself with a previous patch. This commit takes
the driver to replay both of them from the caches.
The sequence replay is tested with below models:
* 828 mkII
* Traveler
* UltraLite
* 828 mk3 FireWire
* 828 mk3 Hybrid (except for high sampling transfer frequency
* UltraLite mk3 FireWire
* 4pre
* AudioExpress
Unfortunately, below models still don't generate better sound, requires
more work:
* 8pre
* 828 mk3 Hybrid at high sampling transfer frequency
As long as I know, MOTU protocol version 1 requires extra care of the
format of data block, thus below models are not supported yet in this
time:
* 828
* 896
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210602013406.26442-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Wed, 2 Jun 2021 01:34:05 +0000 (10:34 +0900)]
ALSA: firewire-motu: cache event ticks in source packet header per data block
The devices in MOTU FireWire series put source packet header (SPH) into
each data block of tx packet for presentation time of event. The format
of timestamp is compliant to IEC 61883-1, with cycle and offset fields
without sec field of 32 bit cycle time.
This commit takes ALSA firewire-motu driver to cache the presentation
time as offset from cycle in which the packet is transferred.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210602013406.26442-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Wed, 2 Jun 2021 01:34:04 +0000 (10:34 +0900)]
ALSA: firewire-motu: use macro for magic numbers relevant to IEC 61883-1
ALSA firewire-motu driver has some magic numbers from IEC 61883-1 to
operates source packet header (SPH). This commit replaces them with
macros.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210602013406.26442-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Tue, 1 Jun 2021 08:17:53 +0000 (17:17 +0900)]
ALSA: bebob: perform sequence replay for media clock recovery
This commit takes ALSA bebob driver to perform sequence replay for media
clock recovery.
Many users have reported discontinuity of data block counter field of CIP
header in tx packet from the devices based on BeBoB ASICs. In the worst
case, the device corrupts not to respond to any transaction, then generate
bus-reset voluntarily for recovery. The sequence replay for media clock
recovery is expected to suppress most of the problems.
In the beginning of packet streaming, the device transfers NODATA packets
for a while, then multiplexes any event and syt information. ALSA
IEC 61883-1/6 packet streaming engine has implementation for it to drop
the initial NODATA packets. It starts sequence replay when detecting any
event multiplexed to tx packets.
The sequence replay is tested with below models:
* Focusrite Saffire
* Focusrite Saffire LE
* Focusrite Saffire Pro 10 I/O
* Focusrite Saffire Pro 26 I/O
* M-Audio FireWire Solo
* M-Audio FireWire Audiophile
* M-Audio Ozonic
* M-Audio FireWire 410
* M-Audio FireWire 1814
* Edirol FA-66
* ESI Quatafire 610
* Apogee Ensemble
* Phonic Firefly 202
* Behringer F-Control Audio 610
Unfortunately, below models doesn't generate sound. This seems regression
introduced recent few years:
* Stanton Final Scratch ScratchAmp at middle sampling transfer frequency
* Yamaha GO44
* Yamaha GO46
* Terratec Phase x24
As I reported, below model has quirk of discontinuity:
* M-Audio ProFire Lightbridge
DM1000/DM1100 ASICs in BeBoB solution are known to have bugs at switch of
sampling transfer frequency between low/middle/high rates. The switch
generates the similar problems about which I mention in the above. Some
vendors customizes firmware so that the switch of frequency is done in
vendor-specific registers, then restrict users to switch the frequency.
For example of Focusrite Saffire Pro 10 i/o and 26 i/o, users allows to
switch the frequency within the three steps; e.g. 44.1/48.0 kHz are
available at low step. Between the steps, extra operation is required and
it always generates bus-reset.
Another example of Edirol FA-66, users are prohibited to switch the
frequency by software. It's done by hardware switch and power-off.
I note that the sequence replay is not a solution for the ASIC bugs. Users
need to disconnect the device corrupted by the bug, then reconnect it to
refresh state machine inner the ASIC.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Tue, 1 Jun 2021 08:17:52 +0000 (17:17 +0900)]
ALSA: dice: perform sequence replay for media clock recovery
This commit takes ALSA dice driver to perform sequence replay for media
clock recovery.
Unlike the other types of device, DICE-based devices interpret the value
of syt field of CIP header in rx packets as presentation time for audio
playback, thus it's required for driver to compute value for outgoing
packet adequate to the device. It's done by media clock recovery by
handling tx packets.
The device starts packet transmission immediately at operation to
GLOBAL_ENABLE thus on-the-fly mode is not required.
DICE ASICs supports several pairs of isochronous packet streams.
Actually, maximum two pairs of streams are supported by devices.
We have three cases regarding to the number of streams:
1. a pair of streams
2. two tx packet streams and one rx packet streams
3. one tx packet streams and two rx packet streams
4. two pair of streams
The decision of playback timing is slightly different in the four cases.
In the case 1, sequence replay in the pair results in suitable playback
timing.
In the case 2, sequence replay from the first tx packet stream to rx
packet stream results in suitable playback timing.
In the case 3, sequence replay from tx packet stream to all of rx packet
stream results in suitable playback timing. Furthermore, the cycle to
start receiving packets should be the same between all rx packet streams.
In the case 4, sequence replay in each pair results in suitable playback
timing. Furthermore, the cycle to start receiving packets should be the
same between all rx packet streams.
The sequence replay is tested with below models:
* For case 1:
* TC Electronic Konnekt 24d (DiceII)
* TC Electronic Konnekt 8 (DiceII)
* TC Electronic Konnekt Live (DiceII)
* TC Electronic Impact Twin (DiceII)
* TC Electronic Digital Konnekt X32 (DiceII)
* TC Electronic Desktop Konnekt 6 (TCD2220)
* Solid State Logic Duende Classic (DiceII)
* Solid State Logic Duende Mini (DiceII)
* PreSonus FireStudio Project (TCD2210)
* PreSonus FireStudio Mobile (TCD2210)
* Lexicon I-ONIX FW810s (TCD2220)
* Avid Mbox 3 Pro (TCD2220)
* For case 2 (but case 1 depends on sampling transfer frequency):
* Alesis iO 26 (DiceII)
* Alesis iO 14 (DiceII)
* Alesis MultiMix 12 FireWire (DiceII)
* Focusrite Saffire Pro 26 (TCD2220)
* For case 3 (but case 1 depends on sampling transfer frequency):
* M-Audio Profire 610 (TCD2220)
* Loud Technology Mackie Onyx Blackbird (TCD2210)
* For case 4:
* TC Electronic Studio Konnekt 48 (DiceII + TCD2220)
* PreSonus FireStudio (DiceII)
* M-Audio Profire 2626 (TCD2220)
* Focusrite Liquid Saffire 56 (TCD2220)
* Focusrite Saffire Pro 40 (TCD2220)
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Tue, 1 Jun 2021 08:17:51 +0000 (17:17 +0900)]
ALSA: dice: wait just for NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation
NOTIFY_CLOCK_ACCEPTED notification is always generated as a result of
GLOBAL_CLOCK_SELECT operation, however NOTIFY_LOCK_CHG notification
doesn't, as long as the selected clock is already configured. In the case,
ALSA dice driver waits so long. It's inconvenient for some devices to lock
to the sequence of value in syt field of CIP header in rx packets.
This commit wait just for NOTIFY_CLOCK_ACCEPTED notification by reverting
changes partially done by two commits below:
* commit
fbeac84dbe9e ("ALSA: dice: old firmware optimization for Dice notification")
* commit
aec045b80d79 ("ALSA: dice: change notification mask to detect lock status change")
I note that the successful lock to the sequence of value in syt field of
CIP header in rx packets results in NOTIFY_EXT_STATUS notification, then
EXT_STATUS_ARX1_LOCKED bit stands in GLOBAL_EXTENDED_STATUS register.
The notification can occur enough after receiving the batch of rx packets.
When the sequence doesn't include value in syt field of CIP header in rx
packets adequate to the device, the notification occurs again and the bit
is off.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210601081753.9191-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Carlos M [Mon, 31 May 2021 20:20:26 +0000 (22:20 +0200)]
ALSA: hda: Fix for mute key LED for HP Pavilion 15-CK0xx
For the HP Pavilion 15-CK0xx, with audio subsystem ID 0x103c:0x841c,
adding a line in patch_realtek.c to apply the ALC269_FIXUP_HP_MUTE_LED_MIC3
fix activates the mute key LED.
Signed-off-by: Carlos M <carlos.marr.pz@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210531202026.35427-1-carlos.marr.pz@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Stefan Binding [Mon, 31 May 2021 16:37:54 +0000 (17:37 +0100)]
ALSA: hda/cirrus: Set Initial DMIC volume to -26 dB
Previously this fix was applied only to Bullseye variant laptops,
and should be applied to Cyborg and Warlock variants.
Fixes:
45b14fe200ba ("ALSA: hda/cirrus: Use CS8409 filter to fix abnormal sounds on Bullseye")
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210531163754.136736-1-vitalyr@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 31 May 2021 02:51:03 +0000 (11:51 +0900)]
ALSA: fireface: perform sequence replay for media clock recovery
This commit takes ALSA fireface driver to perform sequence replay for
media clock recovery.
The protocol specific to RME Fireface series is not compliant to
IEC 61883-1/6 since it has no CIP header, therefore presentation time
is not used for media clock recovery. The sequence of the number of data
blocks per packet is important.
I note that the device skips an isochronous cycle corresponding to an
empty packet or a NODATA packet in blocking transmission method of
IEC 61883-1/6. For sequence replay, the cycle is handled as receiving an
empty packet. Furthermore, it doesn't start packet transmission till
receiving any packet.
The sequence replay is tested with below models:
* Fireface 400
* Fireface 800
* Fireface 802
I note that it is better to initialize Fireface 400 in advance by
initialization transaction implemented in snd-fireface-ctl-service of
snd-firewire-ctl-services project. You can see whether initialized or
not by HOST LED on the device. Unless, the device often stops packet
transmission even if session starts.
I guess the sequence replay also works well with below models:
* Fireface UFX
* Fireface UCX
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 31 May 2021 02:51:02 +0000 (11:51 +0900)]
ALSA: firewire-tascam: perform sequence replay for media clock recovery
This commit takes ALSA firewire-tascam driver to perform sequence replay
for media clock recovery.
The protocol specific to Tascam FireWire series is not compliant to
IEC 61883-1/6 in terms of syt field of CIP. The protocol doesn't use
presentation time in received CIP for playback timing. The sequence of
the number of data blocks per packet is important for media clock
recovery.
Although the devices in Tascam FireWire series transfer packets
regardless of receiving packets, the tx packets includes no events
in the beginning of streaming. It takes so long to multiplex any event
into the packet after receiving the sequence of packets. As long as I
experienced, it takes several thousands of isochronous cycle. Furthermore,
just after changing sampling transmission frequency, it stops multiplexing
event at once, then starts multiplexing again.
The sequence replay is tested with below models:
* FW-1884
* FW-1804
* FW-1082
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 31 May 2021 02:51:01 +0000 (11:51 +0900)]
ALSA: firewire-digi00x: perform sequence replay for media clock recovery
This commit takes ALSA firewire-digi00x driver to perform sequence replay
for media clock recovery.
All of models in Digidesign digi00x family don't transfer isochronous
packets till receiving isochronous packets. The on-the-fly mode is used
for the purpose. They don't interpret presentation time expressed in syt
field of received CIP, therefore the sequence of the number of data blocks
per packet is important for media clock recovery.
The sequence replay is tested with below models:
* Digidesign Digi 002
* Digidesign Digi 002 Rack
* Digidesign Digi 003
* Digidesign Digi 003 Rack
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>