- 04 Mar, 2024 1 commit
-
-
Kenny Levinsen authored
When building feature controls from a unit without a name, we try to derive a name first from the feature unit's input, then fall back to the output terminal. If a feature unit connects directly to a "USB Streaming" input terminal rather than a mixer or other virtual type, the control receives the somewhat meaningless name "PCM", even if the output had a descriptive type such as "Headset" or "Speaker". Here is an example of such AudioControl descriptor from a USB headset which ends up named "PCM Playback" and is therefore not recognized as headphones by userspace: AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 4 wTerminalType 0x0101 USB Streaming bAssocTerminal 5 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 5 wTerminalType 0x0402 Headset bAssocTerminal 4 bSourceID 6 iTerminal 0 AudioControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 6 bSourceID 4 bControlSize 2 bmaControls(0) 0x0002 Volume Control bmaControls(1) 0x0000 bmaControls(2) 0x0000 iFeature 0 Other headsets and DACs I tried that used their output terminal for naming only did so due to their input being an unnamed sidetone mixer. Instead of always starting with the input terminal, check the type of it first. If it seems uninteresting, invert the order and use the output terminal first for naming. This makes userspace recognize headsets with simple controls as headphones, and leads to more consistent naming of playback devices based on their outputs irrespective of sidetone mixers. Signed-off-by:Kenny Levinsen <kl@kl.wtf> Link: https://lore.kernel.org/r/20240301231107.42679-1-kl@kl.wtfSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 01 Mar, 2024 1 commit
-
-
Nathan Chancellor authored
Clang prior to 17.0.0 has a bug in its asm goto jump scope analysis to determine that no variables with the cleanup attribute are skipped by an indirect jump. Instead of only checking the scope of each label that is a possible target of each asm goto statement, it checks the scope of every label, which can cause an error when a variable with the cleanup attribute is used between two asm goto statements with different scopes, even if they have completely different label targets: sound/core/hwdep.c:273:8: error: cannot jump from this asm goto statement to one of its possible targets if (get_user(device, (int __user *)arg)) ^ arch/powerpc/include/asm/uaccess.h:295:5: note: expanded from macro 'get_user' __get_user(x, _gu_addr) : \ ^ arch/powerpc/include/asm/uaccess.h:283:2: note: expanded from macro '__get_user' __get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \ ^ arch/powerpc/include/asm/uaccess.h:199:3: note: expanded from macro '__get_user_size_allowed' __get_user_size_goto(x, ptr, size, __gus_failed); \ ^ arch/powerpc/include/asm/uaccess.h:187:10: note: expanded from macro '__get_user_size_goto' case 1: __get_user_asm_goto(x, (u8 __user *)ptr, label, "lbz"); break; \ ^ arch/powerpc/include/asm/uaccess.h:158:2: note: expanded from macro '__get_user_asm_goto' asm_volatile_goto( \ ^ include/linux/compiler_types.h:366:33: note: expanded from macro 'asm_volatile_goto' #define asm_volatile_goto(x...) asm goto(x) ^ sound/core/hwdep.c:291:9: note: possible target of asm goto statement if (put_user(device, (int __user *)arg)) ^ arch/powerpc/include/asm/uaccess.h:66:5: note: expanded from macro 'put_user' __put_user(x, _pu_addr) : -EFAULT; \ ^ arch/powerpc/include/asm/uaccess.h:52:9: note: expanded from macro '__put_user' \ ^ sound/core/hwdep.c:276:4: note: jump bypasses initialization of variable with __attribute__((cleanup)) scoped_guard(mutex, ®ister_mutex) { ^ include/linux/cleanup.h:169:20: note: expanded from macro 'scoped_guard' for (CLASS(_name, scope)(args), \ To avoid this issue, move the put_user() call out of the scoped_guard() scope, which allows the asm goto scope analysis to see that the variable with the cleanup attribute will never be skipped by the asm goto statements. There should be no functional change because prior to the refactoring, put_user() was not called under register_mutex, so this call does not even need to be in the scoped_guard() in the first place. Fixes: e6684d08 ("ALSA: hwdep: Use guard() for locking") Closes: https://github.com/ClangBuiltLinux/linux/issues/2003Signed-off-by:Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20240301-fix-snd-hwdep-guard-v1-1-6aab033f3f83@kernel.orgSigned-off-by:
-
- 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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:
-
- 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 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 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 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 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 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 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 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 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 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 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 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:
-
- 22 Feb, 2024 1 commit
-
-
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:
-
