- 28 Feb, 2024 16 commits
-
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-16-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-15-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-14-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-13-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-12-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-11-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. There are a few remaining explicit mutex and spinlock calls, and those are the places where the temporary unlock/relocking happens -- which guard() doens't cover well yet. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-10-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. The lops calls under multiple rwsems are factored out as a simple macro, so that it can be called easily from snd_ctl_dev_register() and snd_ctl_dev_disconnect(). There are a few remaining explicit rwsem and spinlock calls, and those are the places where the lock downgrade happens or where the temporary unlock/relocking happens -- which guard() doens't cover well yet. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-9-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-8-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-7-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. There are still a few remaining explicit mutex_lock/unlock calls, and those are for the places where we do temporary unlock/relock, which doesn't fit well with the guard(), so far. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-6-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-5-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. For making changes easier, some functions widen the application of register_mutex, but those shouldn't influence on any actual performance. Also, one code block was factored out as a function so that guard() can be applied cleanly without much indentation. There are still a few remaining explicit spin_lock/unlock calls, and those are for the places where we do temporary unlock/relock, which doesn't fit well with the guard(), so far. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-4-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. The explicit mutex_lock/unlock are still seen only in snd_compress_wait_for_drain() which does temporary unlock/relocking. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-3-tiwai@suse.de
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-2-tiwai@suse.de
-
Takashi Iwai authored
There were a few sparse warnings about the cast of strong-typed snd_pcm_format_t. Fix them with cast with __force. For spreading the ugly mess, put them in the definitions WRONG_FORMAT_1 and WRONG_FORMAT_2 and use them in the callers. Fixes: 3e39acf5 ("ALSA: core: Add sound core KUnit test") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202402270303.PmvmQrJV-lkp@intel.com Link: https://lore.kernel.org/r/20240227104912.18921-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 23 Feb, 2024 12 commits
-
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240223084241.3361-5-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240223084241.3361-4-tiwai@suse.de
-
Takashi Iwai authored
Now we have a nice definition of CLASS(fd) that can be applied as a clean up for the fdget/fdput pairs in snd_pcm_link(). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240223084241.3361-2-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-10-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-9-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-8-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-7-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-6-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-5-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). A caveat is that some allocations are memdup_user() and they return an error pointer instead of NULL. Those need special cares and the value has to be cleared with no_free_ptr() at the allocation error path. Other than that, the conversions are straightforward. No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-4-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). A caveat is that some allocations are memdup_user() and they return an error pointer instead of NULL. Those need special cares and the value has to be cleared with no_free_ptr() at the allocation error path. Other than that, the conversions are straightforward. No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-3-tiwai@suse.de
-
Takashi Iwai authored
There are common patterns where a temporary buffer is allocated and freed at the exit, and those can be simplified with the recent cleanup mechanism via __free(kfree). A caveat is that some allocations are memdup_user() and they return an error pointer instead of NULL. Those need special cares and the value has to be cleared with no_free_ptr() at the allocation error path. Other than that, the conversions are straightforward. No functional changes, only code refactoring. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240222111509.28390-2-tiwai@suse.de
-
- 22 Feb, 2024 3 commits
-
-
Takashi Iwai authored
Both snd_seq_prioq_remove_events() and snd_seq_prioq_leave() have a very similar loop for removing events. Unify them with a callback for code simplification. Only the code refactoring, and no functional changes. Link: https://lore.kernel.org/r/20240222132152.29063-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The beep->mutex is no longer used since the drop of beep_mode=2. Let's get rid of it. Fixes: 0920c9b4 ("ALSA: hda - Remove beep_mode=2") Link: https://lore.kernel.org/r/20240222153148.19691-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Colin Ian King authored
The variable clock is being assigned a value that is never read, it is being re-assigned a new value in every case in the following switch statement. The assignment is redundant and can be removed. Cleans up clang scan build warning: sound/pci/echoaudio/echoaudio_3g.c:277:2: warning: Value stored to 'clock' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20240221113809.3410109-1-colin.i.king@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 21 Feb, 2024 5 commits
-
-
Takashi Iwai authored
Pull 6.8-rc devel branch. The trivial merge conflict got resolved. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Eniac Zhang authored
The HP mt440 Thin Client uses an ALC236 codec and needs the ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make the mute and micmute LEDs work. There are two variants of the USB-C PD chip on this device. Each uses a different BIOS and board ID, hence the two entries. Signed-off-by: Eniac Zhang <eniac-xw.zhang@hp.com> Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc@hp.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240220175812.782687-1-alexandru.gagniuc@hp.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
When BDL table entry overflow happens, the driver spews an error message explicitly. But basically this condition can be triggered easily by an application and it may flood of error logs unnecessarily. Downgrade the error message with dev_dbg() as a debug message instead. Link: https://lore.kernel.org/r/20240221100607.6565-2-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
So far the setup of BDL table is performed at the prepare stage, where all PCM parameters have been already set up. When something wrong happens at it, we return -EINVAL; it's supposed to be a rare case since the involved memory allocation is a small chunk of kmalloc for the table. However, when we receive too many small non-contiguous pages in highly fragmented memories, it may overflow the max table size, resulting in the same -EINVAL error from the prepare, too. A bad scenario is that user-space cannot know what went wrong (as it's an error from the prepare stage) and -EINVAL, hence it may retry with the same parameters, failing again repeatedly. In this patch, we try to set up the BDL table at hw_params right after the buffer allocation, and return -ENOMEM if it overflows. This allows user-space knowing that it should reduce the buffer size request accordingly and may retry with more fitting parameters. Link: https://lore.kernel.org/r/20240221100607.6565-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
We forgot to remove the line for snd-rtctimer from Makefile while dropping the functionality. Get rid of the stale line. Fixes: 34ce71a9 ("ALSA: timer: remove legacy rtctimer") Link: https://lore.kernel.org/r/20240221092156.28695-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 20 Feb, 2024 1 commit
-
-
Takashi Iwai authored
snd_ump_legacy_open() didn't return the error code properly even if it couldn't open. Fix it. Fixes: 0b5288f5 ("ALSA: ump: Add legacy raw MIDI support") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240220150843.28630-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 19 Feb, 2024 3 commits
-
-
Hans Peter authored
On my EliteBook 840 G8 Notebook PC (ProdId 5S7R6EC#ABD; built 2022 for german market) the Mute LED is always on. The mute button itself works as expected. alsa-info.sh shows a different subsystem-id 0x8ab9 for Realtek ALC285 Codec, thus the existing quirks for HP 840 G8 don't work. Therefore, add a new quirk for this type of EliteBook. Signed-off-by: Hans Peter <flurry123@gmx.ch> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240219164518.4099-1-flurry123@gmx.chSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Jay Ajit Mate authored
The Dell Inspiron 16 Plus 7630, similar to its predecessors (7620 models), experiences an issue with unconnected top speakers. Since the controller remains unchanged, this commit addresses the problem by correctly connecting the speakers on NID 0X17 to the DAC on NIC 0x03. Signed-off-by: Jay Ajit Mate <jay.mate15@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240219100404.9573-1-jay.mate15@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
The local helper function to compare the given pair of cycle count evaluates them. If the left value is less than the right value, the function returns negative value. If the safe cycle is less than the current cycle, it is the case of cycle lost. However, it is not currently handled properly. This commit fixes the bug. Cc: <stable@vger.kernel.org> Fixes: 705794c5 ("ALSA: firewire-lib: check cycle continuity") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20240218033026.72577-1-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>
-