- 28 Feb, 2024 25 commits
-
-
Takashi Iwai authored
We can simplify the code gracefully with new guard() macro and co for automatic cleanup of locks. A couple of functions that use snd_card_ref() and *_unref() are also cleaned up with a defined class, too. Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-25-tiwai@suse.de
-
Takashi Iwai authored
The setup_mutex in PCM oss code can be simplified with guard(). (params_lock is tough and not trivial to covert, though.) Only the code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-24-tiwai@suse.de
-
Takashi Iwai authored
Define guard() usage for PCM stream locking and use it in appropriate places. The pair of snd_pcm_stream_lock() and snd_pcm_stream_unlock() can be presented with guard(pcm_stream_lock) now. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240227085306.9764-23-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-22-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-21-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-20-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-19-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-18-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-17-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-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>
-