summaryrefslogtreecommitdiff
path: root/sound/core
AgeCommit message (Collapse)Author
2024-05-22ALSA: core: Enable proc module when CONFIG_MODULES=yTakashi Iwai
We used '#ifdef MODULE' for judging whether the system supports the sound module or not, and /proc/asound/modules is created only when '#ifdef MODULE' is true. The check is not really appropriate, though, because the flag means only for the sound core and the drivers are still allowed to be built as modules even if 'MODULE' is not set in sound/core/init.c. For fixing the inconsistency, replace those ifdefs with 'ifdef CONFIG_MODULES'. One place for a NULL module check is rewritten with IS_MODULE(CONFIG_SND) to be more intuitive. It can't be changed to CONFIG_MODULES; otherwise it would hit a WARN_ON() incorrectly. This is a slight behavior change; the modules proc entry appears now no matter whether the sound core is built-in or not as long as modules are enabled on the kernel in general. This can't be avoided due to the nature of kernel builds. Link: https://lore.kernel.org/r/20240520170349.2417900-1-xu.yang_2@nxp.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20240522070442.17786-2-tiwai@suse.de
2024-05-22ALSA: core: Fix NULL module pointer assignment at card initTakashi Iwai
The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare. Fixes: 81033c6b584b ("ALSA: core: Warn on empty module") Reported-by: Xu Yang <xu.yang_2@nxp.com> Closes: https://lore.kernel.org/r/20240520170349.2417900-1-xu.yang_2@nxp.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20240522070442.17786-1-tiwai@suse.de
2024-05-16ALSA: timer: Set lower bound of start tick timeTakashi Iwai
Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow. Reported-by: syzbot+43120c2af6ca2938cc38@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-05-10ALSA: core: Remove superfluous CONFIG_PMTakashi Iwai
Since the recent code change, the conditional build with CONFIG_PM is calling only snd_power_sync_ref(). As a dummy function is provided for this function, we can get rid of CONFIG_PM gracefully now. Link: https://lore.kernel.org/r/20240510125128.6058-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-05-10Merge branch 'for-linus' into for-nextTakashi Iwai
Pull 6.9-rc devel branch for further updates. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-05-10ALSA: Fix deadlocks with kctl removals at disconnectionTakashi Iwai
In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218816 Cc: <stable@vger.kernel.org> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20240510101424.6279-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-05-09ALSA: kunit: Add missing module descriptionsTakashi Iwai
Now that make W=1 starts complaining the lack of MODULE_DESCRIPTION(), let's add the missing information. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Closes: https://lore.kernel.org/r/ZjpQm-hxLQtpgkUx@smile.fi.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20240508091128.25274-5-tiwai@suse.de
2024-05-09ALSA: pcm_dmaengine: Add missing module descriptionTakashi Iwai
Now that make W=1 starts complaining the lack of MODULE_DESCRIPTION(), let's add the missing information. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Closes: https://lore.kernel.org/r/ZjpQm-hxLQtpgkUx@smile.fi.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20240508091128.25274-4-tiwai@suse.de
2024-05-08ALSA: core: Use *-y instead of *-objs in MakefileTakashi Iwai
*-objs suffix is reserved rather for (user-space) host programs while usually *-y suffix is used for kernel drivers (although *-objs works for that purpose for now). Let's correct the old usages of *-objs in Makefiles. Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20240507135513.14919-2-tiwai@suse.de
2024-04-28Merge branch 'topic/emu10k1-fix' into for-nextTakashi Iwai
Pull emu10k1 fixes from Oswald Buddenhagen Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-04-28ALSA: kunit: use const qualifier for immutable dataTakashi Sakamoto
Some data for testing is immutable. In the case, the const qualifier is available for any loader to place it to read-only segment. Fixes: 3e39acf56ede ("ALSA: core: Add sound core KUnit test") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Ivan Orlov <ivan.orlov0322@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240425233653.218434-1-o-takashi@sakamocchi.jp>
2024-04-26ALSA: kunit: make read-only array buf_samples static constColin Ian King
Don't populate the read-only array buf_samples on the stack at run time, instead make it static const. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ivan Orlov <ivan.orlov0322@gmail.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240425160754.114716-1-colin.i.king@gmail.com>
2024-04-24ALSA: control: Use list_for_each_entry_safe()Andy Shevchenko
Instead of reiterating the list, use list_for_each_entry_safe() that allows to continue without starting over. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Message-ID: <20240424145020.1057216-1-andriy.shevchenko@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-04-19ALSA: seq: dummy: Allow UMP conversionTakashi Iwai
Although the purpose of dummy seq client is a direct pass-through, it's sometimes helpful for debugging if it can convert to a certain UMP MIDI version. This patch adds an option to specify the UMP event conversion. As default, it skips the conversion and does passthrough, while user can pass ump=1 or ump=2 to enforce the conversion to UMP MIDI1 or MIDI2 format. Message-ID: <20240419101105.15571-1-tiwai@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-04-19ALSA: seq: ump: Fix conversion from MIDI2 to MIDI1 UMP messagesTakashi Iwai
The conversion from MIDI2 to MIDI1 UMP messages had a leftover artifact (superfluous bit shift), and this resulted in the bogus type check, leading to empty outputs. Let's fix it. Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events") Cc: <stable@vger.kernel.org> Link: https://github.com/alsa-project/alsa-utils/issues/262 Message-ID: <20240419100442.14806-1-tiwai@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-04-18ALSA: pcm: add support for 705.6kHz and 768kHz sample ratesPavel Hofman
Many modern codecs support 705.6kHz and 768kHz sample rates. Current HW params fail to set 705.6kHz and 768kHz sample rates as these are not in the known-rates list. Add these new rates to the known-rates list to allow them. Also add defines in pcm.h so that drivers can use it. Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240416121726.628679-3-pavel.hofman@ivitera.com>
2024-03-28ALSA: control-led: Integrate mute led triggerHeiner Kallweit
This driver is the only one calling ledtrig_audio_set(), therefore the LED audio trigger isn't usable standalone. So it makes sense to fully integrate LED audio triger handling here. The module aliases ensure that the driver is auto-loaded (if built as module) if a LED device has one of the two audio triggers as default trigger. In addition disable building the old audio mute LED trigger. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/107634e6-d9ad-4a9f-881d-1eb72ea1a5a7@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-20ALSA: control: Fix unannotated kfree() cleanupTakashi Iwai
The recent conversion to the automatic kfree() forgot to mark a variable with __free(kfree), leading to memory leaks. Fix it. Fixes: 1052d9882269 ("ALSA: control: Use automatic cleanup of kfree()") Reported-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr> Closes: https://lore.kernel.org/r/c1e2ef3c-164f-4840-9b1c-f7ca07ca422a@alu.unizg.hr Message-ID: <20240320062722.31325-1-tiwai@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-03-17ALSA: core: add kunitconfigTakashi Sakamoto
It is helpful to add .kunitconfig if we work with the tools provided by KUnit project. The file describes the series of kernel configurations to satisfy the dependency to build the target test. For example: $ ./tools/testing/kunit/kunit.py run --arch=arm64 --cross_compile=aarch64-linux-gnu- --kunitconfig=sound/core/ [11:35:13] Configuring KUnit Kernel ... Regenerating .config ... Populating config with: $ make ARCH=arm64 O=.kunit olddefconfig CROSS_COMPILE=aarch64-linux-gnu- [11:35:19] Building KUnit Kernel ... Populating config with: $ make ARCH=arm64 O=.kunit olddefconfig CROSS_COMPILE=aarch64-linux-gnu- Building with: $ make ARCH=arm64 O=.kunit --jobs=8 CROSS_COMPILE=aarch64-linux-gnu- [11:37:35] Starting KUnit Kernel (1/1)... [11:37:35] ============================================================ Running tests with: $ qemu-system-aarch64 -nodefaults -m 1024 -kernel .kunit/arch/arm64/boot/Image.gz -append 'kunit.enable=1 console=ttyAMA0 kunit_shutdown=reboot' -no-reboot -nographic -serial stdio -machine virt -cpu max,pauth-impdef=on [11:37:35] ============== sound-core-test (10 subtests) =============== [11:37:35] [PASSED] test_phys_format_size [11:37:35] [PASSED] test_format_width [11:37:35] [PASSED] test_format_endianness [11:37:35] [PASSED] test_format_signed [11:37:35] [PASSED] test_format_fill_silence [11:37:35] [PASSED] test_playback_avail [11:37:35] [PASSED] test_capture_avail [11:37:35] [PASSED] test_card_set_id [11:37:35] [PASSED] test_pcm_format_name [11:37:35] [PASSED] test_card_add_component [11:37:35] ================= [PASSED] sound-core-test ================= [11:37:35] ============================================================ [11:37:35] Testing complete. Ran 10 tests: passed: 10 [11:37:35] Elapsed time: 142.333s total, 5.617s configuring, 136.047s building, 0.630s running Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Message-ID: <20240317024050.588370-1-o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-03-15ALSA: timer: Fix missing irq-disable at closingTakashi Iwai
The conversion to guard macro dropped the irq-disablement at closing mistakenly, which may lead to a race. Fix it. Fixes: beb45974dd49 ("ALSA: timer: Use guard() for locking") Reported-by: syzbot+28c1a5a5b041a754b947@syzkaller.appspotmail.com Closes: http://lore.kernel.org/r/0000000000000b9a510613b0145f@google.com Message-ID: <20240315101447.18395-1-tiwai@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-03-11Merge branch 'for-next' into for-linusTakashi Iwai
Prep for 6.9 merge. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-03-01ALSA: hwdep: Move put_user() call out of scoped_guard() in ↵Nathan Chancellor
snd_hwdep_control_ioctl() 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, &register_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: e6684d08cc19 ("ALSA: hwdep: Use guard() for locking") Closes: https://github.com/ClangBuiltLinux/linux/issues/2003 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20240301-fix-snd-hwdep-guard-v1-1-6aab033f3f83@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-02-28ALSA: control_led: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: pcm: oss: Use guard() for setupTakashi Iwai
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
2024-02-28ALSA: pcm: Use guard() for PCM stream locksTakashi Iwai
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
2024-02-28ALSA: pcm: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: prioq: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: virmidi: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: ump: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: midi: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: timer: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: queue: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: ports: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: memory: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: seq: fifo: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: core: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: jack: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: rawmidi: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: control: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: mixer_oss: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: info: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: hwdep: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: hrtimer: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: timer: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: compress_offload: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: ump: Use guard() for lockingTakashi Iwai
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
2024-02-28ALSA: kunit: Fix sparse warningsTakashi Iwai
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: 3e39acf56ede ("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.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-02-23ALSA: pcm_oss: ump: Use automatic cleanup of kfree()Takashi Iwai
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
2024-02-23ALSA: mixer_oss: ump: Use automatic cleanup of kfree()Takashi Iwai
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
2024-02-23ALSA: pcm: Use CLASS() for fdget()/fdput()Takashi Iwai
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