- 25 Dec, 2021 6 commits
-
-
Ville Syrjälä authored
The silent stream stuff recurses back into i915 audio component .get_power() from the .pin_eld_notify() hook. On GLK this will deadlock as i915 may already be holding the relevant modeset locks during .pin_eld_notify() and the GLK audio vs. CDCLK workaround will try to grab the same locks from .get_power(). Until someone comes up with a better fix just disable the silent stream support on GLK. Cc: stable@vger.kernel.org Cc: Harsha Priya <harshapriya.n@intel.com> Cc: Emmanuel Jillela <emmanuel.jillela@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2623 Fixes: 951894cf ("ALSA: hda/hdmi: Add Intel silent stream support") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211222145350.24342-1-ville.syrjala@linux.intel.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Yang Guang authored
Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid opencoding it. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
David Yang <davidcomponentone@gmail.com> Signed-off-by:
Yang Guang <yang.guang5@zte.com.cn> Link: https://lore.kernel.org/r/ebc9db44b802dfc88e1538629b517e000acb27b3.1639790796.git.yang.guang5@zte.com.cnSigned-off-by:
-
Mark Brown authored
Enumerations should return a value between 0 and items-1, check that this is the case. Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20211217130213.3893415-3-broonie@kernel.orgSigned-off-by:
-
Mark Brown authored
To simplify the code a bit and allow future reuse factor the checks that values we read are valid out of test_ctl_get_value() into a separate function which can be reused later. As part of this extend the test to check all the values for the control, not just the first one. Signed-off-by:
-
Pierre-Louis Bossart authored
The existing code maximizes confusion by using 'stream' and 'hstream' variables of different types. Examples: struct hdac_stream *stream; struct hdac_ext_stream *stream; struct hdac_stream *hstream; struct hdac_ext_stream *hstream; with some additional copy/paste remains: struct hdac_ext_stream *azx_dev; This patch suggests a consistent naming across all 'hdac_ext_stream' functions. The convention is: struct hdac_stream *hstream; struct hdac_ext_stream *hext_stream; No functionality change - just renaming of variables and more consistent indentation. Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20211216231128.344321-3-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Pierre-Louis Bossart authored
snd_hdac_ext_stop_streams() has really nothing to do with the extension, it just loops over the bus streams. Move it to the hdac_stream layer and rename to remove the 'ext' prefix and add the precision that the chip will also be stopped. Signed-off-by:
Kai Vehmanen <kai.vehmanen@intel.com> Reviewed-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
-
- 13 Dec, 2021 5 commits
-
-
Takashi Iwai authored
When snd_gf1_mem_xalloc() returns NULL, the current code still leaves the formerly allocated block.name string but returns an error immediately. This patch does code-refactoring to move the kstrdup() call itself into snd_gf1_mem_xalloc() and deals with the resource free in the helper code by itself for fixing those memory leaks. Suggested-by:
Jaroslav Kysela <perex@perex.cz> Reviewed-by:
-
Takashi Iwai authored
snd_gf1_mem_xalloc() returns NULL incorrectly when the memory chunk is allocated in the middle of the chain. This patch corrects the return value to treat it properly. Reviewed-by:
-
Xiaoke Wang authored
kstrdup() returns NULL when some internal memory errors happen, it is better to check the return value of it. Otherwise, we may not to be able to catch some memory errors in time. Signed-off-by:
Xiaoke Wang <xkernel.wang@foxmail.com> Link: https://lore.kernel.org/r/tencent_1E3950293AC22395ACFE99404C985D738309@qq.comSigned-off-by:
-
Takashi Sakamoto authored
UAPI headers are built with compiler option for C90, thus double-slashes comment introduced in C99 is not preferable. Fixes: fb6723da ("ALSA: pcm: comment about relation between msbits hw parameter and [S|U]32 formats") Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20211213081257.36097-1-o-takashi@sakamocchi.jpSigned-off-by:
-
Takashi Sakamoto authored
Regarding to handling [U|S][32|24] PCM formats, many userspace application developers and driver developers have confusion, since they require them to understand justification or padding. It easily loses consistency and soundness to operate with many type of devices. In this commit, I attempt to solve the situation by adding comment about relation between [S|U]32 formats and 'msbits' hardware parameter. The formats are used for 'left-justified' sample format, and the available bit count in most significant bit is delivered to userspace in msbits hardware parameter (struct snd_pcm_hw_params.msbits), which is decided by msbits constraint added by pcm drivers (snd_pcm_hw_constraint_msbits()). In driver side, the msbits constraint includes two elements; the physical width of format and the available width of the format in most significant bit. The former is used to match SAMPLE_BITS of format. (For my convenience, I ignore wildcard in the usage of the constraint.) As a result of interaction between ALSA pcm core and ALSA pcm application, when the format in which SAMPLE_BITS equals to physical width of the msbits constaint, the msbits parameter is set by referring to the available width of the constraint. When the msbits parameter is not changed in the above process, ALSA pcm core set it alternatively with SAMPLE_BIT of chosen format. In userspace application side, the msbits is only available after calling ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS request. Even if the hardware parameter structure includes somewhat value of SAMPLE_BITS interval parameter as width of format, all of the width is not always available since msbits can be less than the width. I note that [S|U]24 formats are used for 'right-justified' 24 bit sample formats within 32 bit frame. The first byte in most significant bit should be invalidated. Although the msbits exposed to userspace should be zero as invalid value, actually it is 32 from physical width of format. [ corrected typos -- tiwai ] Signed-off-by:
-
- 12 Dec, 2021 4 commits
-
-
Jaroslav Kysela authored
As mentined by Takashi Sakamoto, the system-wide alsa-lib configuration may override the standard device declarations. This patch use the private alsa-lib configuration to set the predictable environment. Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Takashi Sakamoto authored
The volatile attribute of control element means that the hardware can voluntarily change the state of control element independent of any operation by software. ALSA control core necessarily sends notification to userspace subscribers for any change from userspace application, while it doesn't for the hardware's voluntary change. This commit adds optimization for the attribute. Even if read value is different from written value, the test reports success as long as the target control element has the attribute. On the other hand, the difference is itself reported for developers' convenience. Signed-off-by:
-
Mark Brown authored
Add a basic test for the mixer control interface. For every control on every sound card in the system it checks that it can read and write the default value where the control supports that and for writeable controls attempts to write all valid values, restoring the default values after each test to minimise disruption for users. There are quite a few areas for improvement - currently no coverage of the generation of notifications, several of the control types don't have any coverage for the values and we don't have any testing of error handling when we attempt to write out of range values - but this provides some basic coverage. This is added as a kselftest since unlike other ALSA test programs it does not require either physical setup of the device or interactive monitoring by users and kselftest is one of the test suites that is frequently run by people doing general automated testing so should increase coverage. It is written in terms of alsa-lib since tinyalsa is not generally packaged for distributions which makes things harder for general users interested in kselftest as a whole but it will be a barrier to people with Android. Signed-off-by:
-
Jason Wang authored
Static variables do not need to be initialised to 0, because compiler will initialise all uninitialised statics to 0. Thus, remove the unneeded initializations. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Link: https://lore.kernel.org/r/20211212070422.281924-1-wangborong@cdjrlc.comSigned-off-by:
-
- 07 Dec, 2021 4 commits
-
-
Takashi Iwai authored
Currently ALSA sequencer core tries to process the queued events as much as possible when they become dispatchable. If applications try to queue too massive events to be processed at the very same timing, the sequencer core would still try to process such all events, either in the interrupt context or via some notifier; in either away, it might be a cause of RCU stall or such problems. As a potential workaround for those problems, this patch adds the upper limit of the amount of events to be processed. The remaining events are processed in the next batch, so they won't be lost. For the time being, it's limited up to 1000 events per queue, which should be high enough for any normal usages. Reported-by:
Zqiang <qiang.zhang1211@gmail.com> Reported-by: syzbot+bb950e68b400ab4f65f8@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20211102033222.3849-1-qiang.zhang1211@gmail.com Link: https://lore.kernel.org/r/20211207165146.2888-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The miXart timer notification is a variable length, and if a hardware is screwed up, we may access over the actual data size. Let's add a sanity check and bail out if an invalid value is received. Link: https://lore.kernel.org/r/20211207153323.27098-1-tiwai@suse.deSigned-off-by:
-
Anders Roxell authored
Clang warns: sound/ppc/beep.c:103:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case SND_TONE: break; ^ sound/ppc/beep.c:103:2: note: insert 'break;' to avoid fall-through case SND_TONE: break; ^ break; 1 warning generated. Clang is more pedantic than GCC, which does not warn when failing through to a case that is just break or return. Clang's version is more in line with the kernel's own stance in deprecated.rst. Add athe missing break to silence the warning. Reported-by:Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
Anders Roxell <anders.roxell@linaro.org> Link: https://lore.kernel.org/r/20211207110053.695712-1-anders.roxell@linaro.orgSigned-off-by:
-
Kees Cook authored
The mixart_timer_notify structure was larger than could be represented by the mixart_msg_data array storage. Adjust the size to as large as possible to fix the warning seen with -Warray-bounds builds: sound/pci/mixart/mixart_core.c: In function 'snd_mixart_threaded_irq': sound/pci/mixart/mixart_core.c:447:50: error: array subscript 'struct mixart_timer_notify[0]' is partly outside array bounds of 'u32[128]' {aka 'unsigned int[128]'} [-Werror=array-bounds] 447 | for(i=0; i<notify->stream_count; i++) { | ^~ sound/pci/mixart/mixart_core.c:328:12: note: while referencing 'mixart_msg_data' 328 | static u32 mixart_msg_data[MSG_DEFAULT_SIZE / 4]; | ^~~~~~~~~~~~~~~ Signed-off-by:Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211207062941.2413679-1-keescook@chromium.orgSigned-off-by:
-
- 06 Dec, 2021 3 commits
-
-
Takashi Iwai authored
Practically seen, CONFIG_PM is almost mandatory. Let's drop the ugly ifdef lines and simplify the code. Link: https://lore.kernel.org/r/20211202084053.18201-1-tiwai@suse.deSigned-off-by:
-
Bernard Zhao authored
Tis patch try to remove useless NULL check before kfree Signed-off-by:
Bernard Zhao <bernard@vivo.com> Link: https://lore.kernel.org/r/20211206014135.320720-1-bernard@vivo.comSigned-off-by:
-
Christophe JAILLET authored
Some comments and include guards are not consistent with the name of the file where they can be found. This is likely some typo or cut'n'paste issues. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/7b2bcbda298f02a34d46d8b6593daaaed9a09a45.1638602790.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
- 02 Dec, 2021 2 commits
-
-
Takashi Iwai authored
The vendor ID of Presonus Studio 1810c had a superfluous '0' in its USB ID. Drop it. Fixes: 8dc5efe3 ("ALSA: usb-audio: Add support for Presonus Studio 1810c") Link: https://lore.kernel.org/r/20211202083833.17784-1-tiwai@suse.deSigned-off-by:
-
Kai-Heng Feng authored
There's a system that reports a bogus HDMI audio interface: $ cat eld#2.0 monitor_present 1 eld_valid 1 monitor_name connection_type DisplayPort eld_version [0x2] CEA-861D or below edid_version [0x3] CEA-861-B, C or D manufacture_id 0xe430 product_id 0x690 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH sad_count 0 Since playing audio is not possible without SAD, also consider ELD is invalid for this case. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20211202073338.1384768-1-kai.heng.feng@canonical.comSigned-off-by:
-
- 01 Dec, 2021 1 commit
-
-
Bixuan Cui authored
Fix compile error when OSS_DEBUG is enabled: sound/core/oss/pcm_oss.c: In function 'snd_pcm_oss_set_trigger': sound/core/oss/pcm_oss.c:2055:10: error: 'substream' undeclared (first use in this function); did you mean 'csubstream'? pcm_dbg(substream->pcm, "pcm_oss: trigger = 0x%x\n", trigger); ^ Fixes: 61efcee8 ("ALSA: oss: Use standard printk helpers") Signed-off-by:Bixuan Cui <cuibixuan@linux.alibaba.com> Link: https://lore.kernel.org/r/1638349134-110369-1-git-send-email-cuibixuan@linux.alibaba.comSigned-off-by:
-
- 30 Nov, 2021 3 commits
-
-
Amadeusz Sławiński authored
With NHLT enriched with new search functions, remove local code in favour of them. This also fixes broken behaviour: search should be based on significant bits count rather than container size. Signed-off-by:
Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by:
-
Amadeusz Sławiński authored
Only DMIC endpoint presence is relevant, not its configuration. Signed-off-by:
-
Amadeusz Sławiński authored
Two key operations missings are: endpoint presence-check and retrieval of matching endpoint hardware configuration (blob). Add operations for both use cases. Signed-off-by:
-
- 29 Nov, 2021 1 commit
-
-
Thomas Gleixner authored
HDA uses a timecounter to read a hardware clock running at 24 MHz. The conversion factor is set with a mult value of 125 and a shift value of 0, which is not converting the hardware clock to nanoseconds, it is converting to 1/3 nanoseconds because the conversion factor from 24Mhz to nanoseconds is 125/3. The usage sites divide the "nanoseconds" value returned by timecounter_read() by 3 to get a real nanoseconds value. There is a lengthy comment in azx_timecounter_init() explaining this choice. That comment makes blatantly wrong assumptions about how timecounters work and what can overflow. The comment says: * Applying the 1/3 factor as part of the multiplication * requires at least 20 bits for a decent precision, however * overflows occur after about 4 hours or less, not a option. timecounters operate on time deltas between two readouts of a clock and use the mult/shift pair to calculate a precise nanoseconds value: delta_nsec = (delta_clock * mult) >> shift; The fractional part is also taken into account and preserved to prevent accumulated rounding errors. For details see cyclecounter_cyc2ns(). The mult/shift pair has to be chosen so that the multiplication of the maximum expected delta value does not result in a 64bit overflow. As the counter wraps around on 32bit, the maximum observable delta between two reads is (1 << 32) - 1 which is about 178.9 seconds. That in turn means the maximum multiplication factor which fits into an u32 will not cause a 64bit overflow ever because it's guaranteed that: ((1 << 32) - 1) ^ 2 < (1 << 64) The resulting correct multiplication factor is 2796202667 and the shift value is 26, i.e. 26 bit precision. The overflow of the multiplication would happen exactly at a clock readout delta of 6597069765 which is way after the wrap around of the hardware clock at around 274.8 seconds which is off from the claimed 4 hours by more than an order of magnitude. If the counter ever wraps around the last read value then the calculation is off by the number of wrap arounds times 178.9 seconds because the overflow cannot be observed. Use clocks_calc_mult_shift(), which calculates the most accurate mult/shift pair based on the given clock frequency, and remove the bogus comment along with the divisions at the readout sites. Fixes: 5d890f59 ("ALSA: hda: support for wallclock timestamps") Signed-off-by:Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
-
- 23 Nov, 2021 1 commit
-
-
Takashi Iwai authored
Fix a sparse warning that complains about the inconsistent type assignment for iface, which is a restricted type of snd_ctl_elem_iface_t. Fixes: a135dfb5 ("ALSA: led control - add sysfs kcontrol LED marking layer") Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
- 20 Nov, 2021 1 commit
-
-
Takashi Iwai authored
The previous fix for more comprehensive runtime PM calls turned out to be not good as hoped; a few calls including pm_runtime_enable() and pm_runtime_disable() are rather utterly superfluous for PCI devices, even triggering a kernel error message. Better to drop those calls. Note that the problem we wanted to solve with that commit seems irrelevant with the fix itself; the original bug (a GPF at azx_remove()) was likely a regression by the recent PCI core cleanup, and the buggy PCI change has been already reverted. So basically we were scratching a wrong surface. OTOH, making the runtime PM calls symmetric for both probe and remove is more consistent, and maybe that's a sensible outcome. Fixes: 4f66a9ef ("ALSA: hda: intel: More comprehensive PM runtime setup for controller driver") Reported-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/d9d76980-966a-e031-70d1-3254ba5be5eb@gmail.com Link: https://lore.kernel.org/r/20211119162730.24423-1-tiwai@suse.deSigned-off-by:
-
- 17 Nov, 2021 1 commit
-
-
Takashi Iwai authored
The HD-audio codec driver remove may happen also at dynamically unbinding during operation, hence it needs manual triggers of snd_device_disconnect() calls, while it's missing for the jack objects that are associated with the codec. This patch adds the manual disconnection call for jacks when the remove happens without card->shutdown (i.e. not under the full removal). Link: https://lore.kernel.org/r/20211117133040.20272-1-tiwai@suse.deSigned-off-by:
-
- 16 Nov, 2021 8 commits
-
-
Takashi Iwai authored
This is a second attempt to unify the x86-specific SG-buffer handling code with the new standard non-contiguous page handler. The first try (in commit 2d9ea399) failed due to the wrong page and address calculations, hence reverted. (And the second try failed due to a copy&paste error.) Now it's corrected with the previous fix for noncontig pages, and the proper sg page iteration by this patch. After the migration, SNDRV_DMA_TYPE_DMA_SG becomes identical with SNDRV_DMA_TYPE_NONCONTIG on x86, while others still fall back to SNDRV_DMA_TYPE_DEV. Tested-by:
Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Tested-by:
Harald Arnesen <harald@skogtun.org> Link: https://lore.kernel.org/r/20211017074859.24112-4-tiwai@suse.de Link: https://lore.kernel.org/r/20211109062235.22310-1-tiwai@suse.de Link: https://lore.kernel.org/r/20211116073358.19741-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
When a codec is unbound dynamically via sysfs while its stream is in use, we may face a potential deadlock at the proc remove or a UAF. This happens since the hda_pcm is managed by a linked list, as it handles the hda_pcm object release via kref. When a PCM is opened at the unbinding time, the release of hda_pcm gets delayed and it ends up with the close of the PCM stream releasing the associated hda_pcm object of its own. The hda_pcm destructor contains the PCM device release that includes the removal of procfs entries. And, this removal has the sync of the close of all in-use files -- which would never finish because it's called from the PCM file descriptor itself, i.e. it's trying to shoot its foot. For addressing the deadlock above, this patch changes the way to manage and release the hda_pcm object. The kref of hda_pcm is dropped, and instead a simple refcount is introduced in hda_codec for keeping the track of the active PCM streams, and at each PCM open and close, this refcount is adjusted accordingly. At unbinding, the driver calls snd_device_disconnect() for each PCM stream, then synchronizes with the refcount finish, and finally releases the object resources. Fixes: bbbc7e85 ("ALSA: hda - Allocate hda_pcm objects dynamically") Link: https://lore.kernel.org/r/20211116072459.18930-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it. Fixes: d13bd412 ("ALSA: hda - Manage kcontrol lists") Link: https://lore.kernel.org/r/20211116071314.15065-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it. Fixes: a8ff48cb ("ALSA: pcm: Free chmap at PCM free callback, too") Link: https://lore.kernel.org/r/20211116071314.15065-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it. Fixes: 9058cbe1 ("ALSA: jack: implement kctl creating for jack devices") Link: https://lore.kernel.org/r/20211116071314.15065-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Bose Revolve+ SoundLink (0a57:40fa) advertises invalid dB level for the speaker volume. This patch provides the correction in the mixer map quirk table entry. Note that this requires the prerequisite change to add min_mute flag to the dB map table. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1192375 Link: https://lore.kernel.org/r/20211116065415.11159-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Some devices do mute the volume at the minimal volume, and for such devices, we need to set SNDRV_CTL_TLVT_DB_MINMAX_MUTE to the TLV information. It corresponds to setting usb_mixer_elem_info.min_mute flag in the USB-audio driver. This patch adds a new field min_mute in usbmix_dB_map so that the mixer map entry can pass the flag. Link: https://lore.kernel.org/r/20211116065415.11159-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The values in usbmix_dB_map should be rather signed while we're using u32. As the copied target (usb_mixer_elem_info.dBmin and dBmax) is int, let's make them also int. Link: https://lore.kernel.org/r/20211116065415.11159-2-tiwai@suse.deSigned-off-by:
-
