- 02 May, 2018 11 commits
-
-
Takashi Sakamoto authored
At present, to check running stream, available stream formats are used at current sampling transmission frequency (stf). But when changing stf, it's convenient to use cache of stream formats. This commit applies this idea. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
TC Applied Technologies (TCAT) have added extension to DICE protocol. This protocol extension is called as Extended Application Protocol, a.k.a. EAP. In this protocol extension, units get additional 9 address spaces. One of it is for current configuration. In this address space, a pair of router and stream formats are exposed per mode of three sampling transmission frequencies. This commit adds support the protocol extension for address space of the current configuration to generate cache of stream formats. Signed-off-by:
-
Takashi Sakamoto authored
Alesis shipped some models with DICE ASICs. All of them just support DICE original protocol and drivers can't retrieve all of available stream formats without changing status of sampling transmission frequency actually. This commit puts some hard-coded parameters for the models. When detecting the models, the corresponding parameters are copied as cache of stream formats. I note that each of pair of iO14/iO26 and MultiMix 8/12/16 has the same model ID on their configuration ROM. The MultiMix 8/12/16 just support one mode for sampling transmission frequency and ALSA dice driver already handles them correctly. The iO14/iO26 support three modes and need hard-coded parameters. To distinguish these two models, this commit let the driver to retrieve current stream formats and compare it to known parameters, then decide it. Signed-off-by:
-
Takashi Sakamoto authored
TC Electronic shipped some models with DICE ASICs. All of them just support DICE original protocol and drivers can't retrieve all of available stream formats without changing status of sampling transmission frequency actually. This commit puts some hard-coded parameters for the models. When detecting the models, the corresponding parameters are copied as cache of stream formats. Signed-off-by:
-
Takashi Sakamoto authored
In former commits, proxy structure get members for cache of stream formats. This commit fills the cache with stream formats at current mode of sampling transmission frequency. Signed-off-by:
-
Takashi Sakamoto authored
Products with DICE interface in market can support variable stream formats for three levels of sampling transmission frequencies. To record these formats, a proxy structure got several fields in former commit. This commit adds a proc node to output the stream formats for debugging purpose. Signed-off-by:
-
Takashi Sakamoto authored
Unlike the other drivers in ALSA firewire stack, ALSA dice driver does't create 'firewire' directory for proc nodes because it has 'dice' node only. But this is inconvenient because I have a plan to add another proc node to output available stream formats from cache. This commit let the driver to create the directory and put 'dice' node into it. Signed-off-by:
-
Takashi Sakamoto authored
A previous commit 6f688268 ('ALSA: dice: purge generating channel cache') purged cache of stream formats. DICE interface originally has no feature to assist drivers to retrieve available formats for all of supported sampling transmission frequencies, without changing the frequency actually. For later release of Dice ASICs such as TCD2210, Dice interface has extended protocol and can support the feature. This assists drivers to retrieve available stream formats. This commit is a first step to regain the cache to generate PCM rules for all of supported sampling transmission frequencies. Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in KERN_ERR error messages Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Takashi Sakamoto authored
DECLARE_TLV_DB_SCALE (alias of SNDRV_CTL_TLVD_DECLARE_DB_SCALE) is used but tlv.h is not included. This causes build failure when local macro is defined by comment-out. This commit fixes the bug. At the same time, the alias macro is replaced with a destination macro added at a commit 46e860f7 ("ALSA: rename TLV-related macros so that they're friendly to user applications") Reported-by:
Connor McAdams <conmanx360@gmail.com> Fixes: 44f0c978 ('ALSA: hda/ca0132: Add tuning controls') Signed-off-by:
-
Takashi Iwai authored
The DP-MST support requires more PCM streams than usual, hence CONFIG_SND_DYNAMIC_MINORS is almost mandatory. Currently the driver just warns and continues even if streams are missing, but it doesn't seem to enough convince users to switch to the modern setup. This patch adds the enforced selection of CONFIG_SND_DYNAMIC_MINORS from CONFIG_SND_HDA_CODEC_HDMI for covering that. Signed-off-by:
-
- 27 Apr, 2018 1 commit
-
-
Colin Ian King authored
Trivial fix to spelling mistake in module parameter description text Signed-off-by:
-
- 25 Apr, 2018 16 commits
-
-
Takashi Iwai authored
Back-merge 4.17-rc3 fixes for further development. This will bump the base to 4.17-rc2, too. Signed-off-by: -
Takashi Iwai authored
When CONFIG_SND_DYNAMIC_MINORS isn't set, there are only limited number of devices available, and HD-audio, especially with HDMI/DP codec, will fail to create more than two devices. The driver warns about the lack of such devices and skips the PCM device creations, but the HDMI driver still tries to create the corresponding JACK, SPDIF and ELD controls even for the non-existing PCM substreams. This results in confusion on user-space, and even may break the operation. Similarly, Intel HDMI/DP codec builds the ELD notification from i915 graphics driver, and this may be broken if a notification is sent for the non-existing PCM stream. This patch adds the check of the existence of the assigned PCM substream in the both scenarios above, and skips the further operation if the PCM substream is not assigned. Fixes: 9152085d ("ALSA: hda - add DP MST audio support") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
Merge tag 'asoc-fix-4.17-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.17 A small batch of fixes collected since the merge window, none of which are particularly large or remarkable. They've all been cooking in -next for a while.
-
Kailang Yang authored
On this Lenovo ThinkCentre machine. There are two front mics, we change the location for one of them. Relation: f33f79f3 ("ALSA: hda/realtek - change the location for one of two front microphones") Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in RME9652 driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/rme9652.c:2074 snd_rme9652_channel_info() warn: potential spectre issue 'rme9652->channel_map' (local cap) This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
As recently Smatch suggested, a couple of places in HDSP MADI driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/hdspm.c:5717 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_out' (local cap) sound/pci/rme9652/hdspm.c:5734 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_in' (local cap) This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, a couple of places in ASIHPI driver may expand the array directly from the user-space value with speculation: sound/pci/asihpi/hpimsginit.c:70 hpi_init_response() warn: potential spectre issue 'res_size' (local cap) sound/pci/asihpi/hpioctl.c:189 asihpi_hpi_ioctl() warn: potential spectre issue 'adapters' This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in OPL3 driver may expand the array directly from the user-space value with speculation: sound/drivers/opl3/opl3_synth.c:476 snd_opl3_set_voice() warn: potential spectre issue 'snd_opl3_regmap' This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in HD-audio hwdep ioctl codes may expand the array directly from the user-space value with speculation: sound/pci/hda/hda_local.h:467 get_wcaps() warn: potential spectre issue 'codec->wcaps' As get_wcaps() itself is a fairly frequently called inline function, and there is only one single call with a user-space value, we replace only the latter one to open-code locally with array_index_nospec() hardening in this patch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, a few places in ALSA control core codes may expand the array directly from the user-space value with speculation: sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd' sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd' sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. In this patch, we put array_index_nospec() to the common snd_ctl_get_ioff*() helpers instead of each caller. These helpers are also referred from some drivers, too, and basically all usages are to calculate the array index from the user-space value, hence it's better to cover there. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As Smatch recently suggested, a few places in OSS sequencer codes may expand the array directly from the user-space value with speculation, namely there are a significant amount of references to either info->ch[] or dp->synths[] array: sound/core/seq/oss/seq_oss_event.c:315 note_on_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_event.c:362 note_off_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_synth.c:470 snd_seq_oss_synth_load_patch() warn: potential spectre issue 'dp->synths' (local cap) sound/core/seq/oss/seq_oss_event.c:293 note_on_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_event.c:353 note_off_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:506 snd_seq_oss_synth_sysex() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:580 snd_seq_oss_synth_ioctl() warn: potential spectre issue 'dp->synths' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. We may put array_index_nospec() at each place, but here we take a different approach: - For dp->synths[], change the helpers to retrieve seq_oss_synthinfo pointer directly instead of the array expansion at each place - For info->ch[], harden in a normal way, as there are only a couple of places As a result, the existing helper, snd_seq_oss_synth_is_valid() is replaced with snd_seq_oss_synth_info(). Also, we cover MIDI device where a similar array expansion is done, too, although it wasn't reported by Smatch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
When get_synthdev() is called for a MIDI device, it returns the fixed midi_synth_dev without the use refcounting. OTOH, the caller is supposed to unreference unconditionally after the usage, so this would lead to unbalanced refcount. This patch corrects the behavior and keep up the refcount balance also for the MIDI synth device. Cc: <stable@vger.kernel.org> Signed-off-by: -
Kailang Yang authored
Add ALC255 its own depop functions for alc_init and alc_shutup. Assign it to ALC256 usage. Signed-off-by:
-
Kailang Yang authored
Fill COEF to change EAPD to verb control. Assigned codec type. This is an additional fix over 92f974df ("ALSA: hda/realtek - New vendor ID for ALC233"). [ More notes: according to Kailang, the chip is 10ec:0235 bonding for ALC233b, which is equivalent with ALC255. It's only used for Lenovo. The chip needs no alc_process_coef_fw() for headset unlike ALC255. ] Signed-off-by:
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Commit 1c8f4220 ("mm: change return type to vm_fault_t") Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by:
Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by:
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Commit 1c8f4220 ("mm: change return type to vm_fault_t") Signed-off-by:
-
- 24 Apr, 2018 7 commits
-
-
Michael Drake authored
The channel mapping is defined by bChRelationship, not bChPurpose. Fixes: 9a2fe9b8 ("ALSA: usb: initial USB Audio Device Class 3.0 support") Reviewed-by:
Ruslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by:
Michael Drake <michael.drake@codethink.co.uk> Signed-off-by:
Jorge Sanjuan <jorge.sanjuan@codethink.co.uk> Signed-off-by:
-
Takashi Iwai authored
Put WARN_ON() and bail out if the given index is over the allocated array of the given SPDIF controls. It's merely a sanity check to catch any potential issues (if any). Signed-off-by: -
Takashi Sakamoto authored
In early stage of firmware SDK, DICE seems to lose its backward compatibility due to some registers on global address section. I found this with Alesis Multimix 12 FireWire with ancient firmware (approx. shipped version). According to retrieved log from the unit, global section has 96 byte space. On the other hand, current version of ALSA dice driver assumes that all of supported unit has at least 100 byte space. $ ./firewire-request /dev/fw1 read 0xffffe0000000 28 result: 000: 00 00 00 0a 00 00 00 18 00 00 00 22 00 00 00 8a result: 010: 00 00 00 ac 00 00 01 12 00 00 00 00 00 00 00 00 result: 020: 00 00 00 00 00 00 00 00 This commit adds support for the ancient firmware. Check of global section is loosened to accept the smaller space. The lack of information is already compensated by hard-coded parameters. I experienced that the latest version of Windows driver for this model can't handle this unit, too. This means that TCAT releases firmware SDK without backward compatibility for the ancient firmware. Below list is a early history of driver/firmware package released by Alesis. I investigated on wayback machine on Internet Archive: * Unknown: PAL v1.0.41.2, firmware v1.0.3 * Mar 2006: PAL v1.54.0, firmware v1.0.4 * Dec 2006: PAL v2.0.0.2, firmware v2.0 * Jun 2007: PAL v3.0.41.5, firmware v2.0 * Jul 2007: PAL v3.0.56.2. firmware v2.0 * Jan 2008: PAL v3.0.81.1080, firmware v2.0 If I can assume that firmware version is the same as DICE version, DICE version for the issued firmware may be v1.0.3. According to code base of userspace driver project (FFADO), I can read DICE v1.0.4 supports global space larger than 100 byte. I guess the smaller space of global section is a feature of DICE v1.0.3. Signed-off-by:
-
Takashi Sakamoto authored
OUI for TC Electronic is 0x000166, for TC GROUP A/S. 0x001486 is for Echo Digital Audio Corporation. Fixes: 7cafc65b ('ALSA: dice: force to add two pcm devices for listed models') Cc: <stable@vger.kernel.org> # v4.6+ Reference: http://standards-oui.ieee.org/oui/oui.txtSigned-off-by:
-
Takashi Iwai authored
Introduce a new helper macro, snd_array_for_each(), to iterate for each snd_array element. It slightly improves the readability than lengthy open codes at each place. Along with it, add const prefix to some obvious places. There should be no functional changes by this. Signed-off-by: -
Takashi Iwai authored
The Dell Dock USB-audio device with 0bda:4014 is behaving notoriously bad, and we have already applied some workaround to avoid the firmware hiccup. Yet we still need to skip one thing, the Extension Unit at ID 4, which doesn't react correctly to the mixer ctl access. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1090658 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
The UAC2 jack detection support introduced the bmControls checks in a couple of places, but they forgot the endian conversion; the bmControls of UAC2 terminal descriptor is __le16, not a byte like in UAC1. Fixes: 5a222e84 ("ALSA: usb-audio: UAC2 jack detection") Tested-by:
Andrew Chant <achant@google.com> Signed-off-by:
-
- 23 Apr, 2018 5 commits
-
-
Takashi Iwai authored
The recent code refactoring made the argument for some helper functions to be the explicit UAC_CS_* and UAC2_CS_* value instead of 0-based offset. However, there was one place left forgotten, and it caused a regression on some devices appearing as the inconsistent mixer setup. This patch corrects the forgotten conversion. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199449 Fixes: 21e9b3e9 ("ALSA: usb-audio: fix uac control query argument") Tested-by:
Nazar Mokrynskyi <nazar@mokrynskyi.com> Signed-off-by:
-
Takashi Iwai authored
There is one place missing __user annotation to the pointer used by the recent code refactoring. Reported by sparse. Fixes: 450296f3 ("ALSA: control: code refactoring TLV ioctl handler") Reviewed-by:
-
Daniel Mack authored
Based on a downstream patch from Harry ten Berge. Signed-off-by:
Daniel Mack <daniel@zonque.org> Reported-and-tested-by: wenyi@tianyu-wool.com Original-by:
Harry ten Berge <htenberge@gmail.com> Signed-off-by:
-
kbuild test robot authored
Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
David Henningsson authored
It looks like a simple mistake that this struct member was forgotten. Audio_tstamp isn't used much, and on some archs (such as x86) this ioctl is not used by default, so that might be the reason why this has slipped for so long. Fixes: 4eeaaeae ("ALSA: core: add hooks for audio timestamps") Signed-off-by:
David Henningsson <diwic@ubuntu.com> Reviewed-by:
-
