lwn.git/sound/pci/vx222, branch docs-fixes

ALSA: vx222: Use guard() for mutex locks

2025-09-01T11:52:43+00:00

Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250829144342.4290-61-tiwai@suse.de

ALSA: vx222: Use pure devres PCI

2025-04-24T07:21:34+00:00

pci_request_regions() is a hybrid function which becomes managed if pcim_enable_device() was called before. This hybrid nature is deprecated and should not be used anymore. Replace pci_request_regions() with the always-managed function pcim_request_all_regions(). Pass the driver's name as the name parameter of pcim_request_all_regions(). Signed-off-by: Philipp Stanner Reviewed-by: Andy Shevchenko Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250423075346.45907-16-phasta@kernel.org

ALSA: vx222: Convert to DEFINE_SIMPLE_DEV_PM_OPS()

2025-03-14T10:07:13+00:00

Use the newer DEFINE_SIMPLE_DEV_PM_OPS() macro instead of SIMPLE_DEV_PM_OPS() together with pm_ptr(), which makes CONFIG_PM_SLEEP ifdefs superfluous. Merely a cleanup, there should be no actual code change. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250313170731.26943-9-tiwai@suse.de

ALSA: pci: Use -y instead of -objs in Makefile

2024-05-08T16:17:37+00:00

*-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 Reviewed-by: Andy Shevchenko Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20240507135513.14919-3-tiwai@suse.de

ALSA: vx222: fix null-ptr-deref

2021-09-07T05:13:19+00:00

a recent refactor created a null pointer vx in snd_vx222_probe(). The vx pointer should have been populated in snd_vx222_create() as suggested in earlier version, otherwise vx->core.ibl.size will throw an error. [ 1.298398] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [ 1.316799] RIP: 0010:snd_vx222_probe+0x155/0x290 [snd_vx222] Fixes: 3bde3359aa16 ("ALSA: vx222: Allocate resources with device-managed APIs") Signed-off-by: Tong Zhang Link: https://lore.kernel.org/r/20210907014746.1445278-1-ztong0001@gmail.com Signed-off-by: Takashi Iwai

ALSA: vx222: Allocate resources with device-managed APIs

2021-07-19T14:17:10+00:00

This patch converts the resource management in PCI vx222 driver with devres as a clean up. Each manual resource management is converted with the corresponding devres helper, and the card object release is managed now via card->private_free instead of a lowlevel snd_device. This should give no user-visible functional changes. Link: https://lore.kernel.org/r/20210715075941.23332-51-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: vx: Manage vx_core object with devres

2021-07-19T14:17:09+00:00

The firmware data are also released automatically. Link: https://lore.kernel.org/r/20210715075941.23332-50-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: vx222: Fix assignment in if condition

2021-06-09T15:30:21+00:00

PCI VX222 driver code contains lots of assignments in if condition, which is a bad coding style that may confuse readers and occasionally lead to bugs. This patch is merely for coding-style fixes, no functional changes. Link: https://lore.kernel.org/r/20210608140540.17885-52-tiwai@suse.de Signed-off-by: Takashi Iwai

Merge tag 'tags/mute-led-rework' into for-next

2021-03-30T15:42:40+00:00

ALSA: control - add generic LED API This patchset tries to resolve the diversity in the audio LED control among the ALSA drivers. A new control layer registration is introduced which allows to run additional operations on top of the elementary ALSA sound controls. A new control access group (three bits in the access flags) was introduced to carry the LED group information for the sound controls. The low-level sound drivers can just mark those controls using this access group. This information is not exported to the user space, but user space can manage the LED sound control associations through sysfs (last patch) per Mark's request. It makes things fully configurable in the kernel and user space (UCM). The actual state ('route') evaluation is really easy (the minimal value check for all channels / controls / cards). If there's more complicated logic for a given hardware, the card driver may eventually export a new read-only sound control for the LED group and do the logic itself. The new LED trigger control code is completely separated and possibly optional (there's no symbol dependency). The full code separation allows eventually to move this LED trigger control to the user space in future. Actually it replaces the already present functionality in the kernel space (HDA drivers) and allows a quick adoption for the recent hardware (ASoC codecs including SoundWire). snd_ctl_led 24576 0 The sound driver implementation is really easy: 1) call snd_ctl_led_request() when control LED layer should be automatically activated / it calls module_request("snd-ctl-led") on demand / 2) mark all related kcontrols with SNDRV_CTL_ELEM_ACCESS_SPK_LED or SNDRV_CTL_ELEM_ACCESS_MIC_LED Link: https://lore.kernel.org/r/20210317172945.842280-1-perex@perex.cz Signed-off-by: Takashi Iwai

module: remove never implemented MODULE_SUPPORTED_DEVICE

2021-03-17T20:16:18+00:00

MODULE_SUPPORTED_DEVICE was added in pre-git era and never was implemented. We can safely remove it, because the kernel has grown to have many more reliable mechanisms to determine if device is supported or not. Signed-off-by: Leon Romanovsky Signed-off-by: Linus Torvalds