- 08 Aug, 2024 13 commits
-
-
Takashi Iwai authored
Use pr_*() macro instead of open-coded printk() just for code simplification. Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-14-tiwai@suse.de
-
Takashi Iwai authored
Use pr_err() instead of open-coded printk() just for code simplification. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. The commented old debug prints are dropped, too. Reviewed-by:
-
Takashi Iwai authored
The vx_core.dev field has never been set but referred incorrectly at firmware loading. Pass the proper device pointer from card->dev at request_firmware(), and drop the unused dev field from vx_core, too. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Some debug prints are cleaned up with a macro, too. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. The commented-out debug prints got removed, too. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. The assignment of mpu->rmidi was moved to an earlier place, so that dev_*() can access to the proper device pointer. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
Takashi Iwai authored
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by:
-
- 07 Aug, 2024 6 commits
-
-
Takashi Iwai authored
The recent extension added a new ALSA sequencer port info flag bit SNDRV_SEQ_PORT_FLG_IS_MIDI1, but it's not reported back when inquired. Fix it to report properly. Fixes: 0079c9d1 ("ALSA: ump: Handle MIDI 1.0 Function Block in MIDI 2.0 protocol") Signed-off-by:
-
Takashi Iwai authored
When a sequencer port assigned to a UMP Group that is specific to MIDI 1.0 among MIDI 2.0 client, mark it explicitly in the proc output, so that user can see it easily. This is an exceptional case where the message isn't converted to MIDI 1.0 even if the client is running in MIDI 2.0 mode. Signed-off-by:
-
Takashi Iwai authored
When a FB is created from a GTB instead of UMP FB Info inquiry, we missed the update of the corresponding UMP Group attributes. Export the call of updater and let it be called from the USB driver. Fixes: 0642a3c5 ("ALSA: ump: Update substream name from assigned FB names") Signed-off-by:
-
Takashi Iwai authored
When a MIDI 1.0 protocol is specified in a GTB entry while others are set in MIDI 2.0, it should be seen as a legacy MIDI 1.0 port. Since recently we allow drivers to set a flag SNDRV_UMP_BLOCK_IS_MIDI1 to a FB for that purpose. This patch tries to set that flag when the device shows such a configuration. Signed-off-by:
-
Takashi Iwai authored
It's valid to give different protocols via multiple GTBs; e.g. a MIDI 1.0 port is embedded in a MIDI 2.0 device that talks with MIDI 2.0 protocol. However, the current driver implementation assumes only a single protocol over the whole Endpoint, and it can't handle such a scenario. This patch changes the driver's behavior to parse GTBs to accept multiple protocols. Instead of switching to the last given protocol, it adds the protocol capability bits now. Meanwhile, the default protocol is chosen by the first given protocol in GTBs. Practically seen, this should be a minor issue, as new devices should specify the protocols properly via UMP Endpoint Info messages, so this is rather just covering a corner case. Signed-off-by:
-
Takashi Iwai authored
When the protocol capability bits are changed via Endpoint Info update notification, we should check the validity of the current protocol and reset it if needed, too. Signed-off-by:
-
- 06 Aug, 2024 2 commits
-
-
Takashi Iwai authored
For an invalid input value that is out of the given range, currently USB-audio driver corrects the value silently and accepts without errors. This is no wrong behavior, per se, but the recent kselftest rather wants to have an error in such a case, hence a different behavior is expected now. This patch adds a sanity check at each control put for the standard mixer types and returns an error if an invalid value is given. Note that this covers only the standard mixer types. The mixer quirks that have own control callbacks would need different coverage. Link: https://patch.msgid.link/20240806124651.28203-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The UMP v1.1 spec says in the section 6.2.1: "If a UMP Endpoint declares MIDI 2.0 Protocol but a Function Block represents a MIDI 1.0 connection, then may optionally be used for messages to/from that Function Block." It implies that the driver can (and should) keep MIDI 1.0 CVM exceptionally for those FBs even if UMP Endpoint is running in MIDI 2.0 protocol, and the current driver lacks of it. This patch extends the sequencer port info to indicate a MIDI 1.0 port, and tries to send/receive MIDI 1.0 CVM as is when this port is the source or sink. The sequencer port flag is set by the driver at parsing FBs and GTBs although application can set it to its own user-space clients, too. Link: https://patch.msgid.link/20240806070024.14301-1-tiwai@suse.deSigned-off-by:
-
- 01 Aug, 2024 8 commits
-
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87plqvk51y.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
-
Kuninori Morimoto authored
We already have snd_pcm_direction_name(). Let's use it. Signed-off-by:
-
Takashi Iwai authored
The recent changes in IOMMU made the non-contiguous page allocations as default, hence we can simply use the standard DMA allocation for the S/G pages as well. In this patch, we simplify the code by trying the standard DMA allocation at first, instead of dma_alloc_noncontiguous(). For the case without IOMMU, we still need to manage the S/G pages manually, so we keep the same fallback routines like before. The fallback types (SNDRV_DMA_TYPE_DEV_SG_FALLBACK & co) are dropped / folded into SNDRV_DMA_TYPE_DEV_SG and co now. The allocation via the standard DMA call overrides the type accordingly, hence we don't have to have extra fallback types any longer. OTOH, SNDRV_DMA_TYPE_DEV_SG is no longer an alias but became its own type back again. Note that this patch requires another prerequisite fix for memmalloc helper to use the DMA API for WC pages on x86. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219087 Link: https://patch.msgid.link/20240801064808.31205-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The memalloc helper used a house-made code for allocation of WC pages on x86, since the standard DMA API doesn't cover it well. Meanwhile, the manually allocated pages won't work together with IOMMU, resulting in faults, so we should switch to the DMA API in that case, instead. This patch tries to switch back to DMA API for WC pages on x86, but with some additional tweaks that are missing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219087 Link: https://patch.msgid.link/20240801064808.31205-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
One snd_power_unref() was forgotten and left at __snd_ctl_elem_info() in the previous change for reorganizing the locking order. Fixes: fcc62b19 ("ALSA: control: Take power_ref lock primarily") Link: https://github.com/thesofproject/linux/pull/5127 Link: https://patch.msgid.link/20240801064203.30284-1-tiwai@suse.deSigned-off-by:
-
- 30 Jul, 2024 6 commits
-
-
Takashi Iwai authored
The code path for kcontrol accesses have often nested locks of both card's controls_rwsem and power_ref, and applies in that order. However, what could take much longer is the latter, power_ref; it waits for the power state of the device, and it pretty much depends on the user's action. This patch swaps the locking order of those locks to a more natural way, namely, power_ref -> controls_rwsem, in order to shorten the time of possible nested locks. For consistency, power_ref is taken always in the top-level caller side (that is, *_user() functions and the ioctl handler itself). Link: https://patch.msgid.link/20240729160659.4516-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We want sometimes to keep the runtime PM disabled persistently just like we did for the PM deny-list in the previous change, e.g. for testing some buggy device. This patch enhances the existing pm_blacklist option for achieving it easily. The default behavior doesn't change -- the driver looks up the deny list and disables the runtime PM if matches. However, when pm_blacklist=1 option is set, now the driver disables the runtime PM completely, just like the deny-list does. Update the documentation for this option, too. Link: https://patch.msgid.link/20240729141519.18398-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We have a runtime PM deny-list for the devices that show the problems (typically click noises) at runtime suspend/resume, and when it matches, the driver disables the default runtime PM. However, we still allow the runtime PM changed via power_save module option dynamically, and the desktop system often tweaks it. This ended up with a re-enablement of the runtime PM that surprises users, suddenly suffering from the noises. This patch changes the driver behavior slightly: when the device is listed in the deny-list, ignore the power_save option change and keep the original (that is, off) runtime PM state. Link: https://patch.msgid.link/20240729141519.18398-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We had a nice name scheme in ALSA sequencer UMP binding for each sequencer port referring to each assigned Function Block name, while the legacy rawmidi refers only to the UMP Endpoint name. It's better to align both. This patch moves the UMP Group attribute update functions into the core UMP code from the sequencer binding code, and improve the substream name of the legacy rawmidi. Link: https://patch.msgid.link/20240729141315.18253-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
struct snd_kcontrol contains a flex array of snd_kcontrol_volatile objects at its end, and the array size is stored in count field. This can be annotated gracefully with __counted_by() for catching possible array overflows. One additional change is the order of the count field initialization; The assignment of the count field is moved before assignment of vd[] elements for avoiding false-positive warnings from compilers. Link: https://patch.msgid.link/20240726152840.8629-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Pull 6.11-devel branch for further development. Signed-off-by:
-
- 29 Jul, 2024 1 commit
-
-
Mavroudis Chatzilazaridis authored
ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST fixes combo jack detection and limits the internal microphone boost that causes clipping on this model. Signed-off-by:
Mavroudis Chatzilazaridis <mavchatz@protonmail.com> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20240728123601.144017-1-mavchatz@protonmail.comSigned-off-by:
-
- 28 Jul, 2024 4 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix RPM package build error caused by an incorrect locale setup - Mark modules.weakdep as ghost in RPM package - Fix the odd combination of -S and -c in stack protector scripts, which is an error with the latest Clang * tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: Fix '-S -c' in x86 stack protector scripts kbuild: rpm-pkg: ghost modules.weakdep file kbuild: rpm-pkg: Fix C locale setup
-
Linus Torvalds authored
This simplifies the min_t() and max_t() macros by no longer making them work in the context of a C constant expression. That means that you can no longer use them for static initializers or for array sizes in type definitions, but there were only a couple of such uses, and all of them were converted (famous last words) to use MIN_T/MAX_T instead. Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Commit 3a7e02c0 ("minmax: avoid overly complicated constant expressions in VM code") added the simpler MIN_T/MAX_T macros in order to avoid some excessive expansion from the rather complicated regular min/max macros. The complexity of those macros stems from two issues: (a) trying to use them in situations that require a C constant expression (in static initializers and for array sizes) (b) the type sanity checking and MIN_T/MAX_T avoids both of these issues. Now, in the whole (long) discussion about all this, it was pointed out that the whole type sanity checking is entirely unnecessary for min_t/max_t which get a fixed type that the comparison is done in. But that still leaves min_t/max_t unnecessarily complicated due to worries about the C constant expression case. However, it turns out that there really aren't very many cases that use min_t/max_t for this, and we can just force-convert those. This does exactly that. Which in turn will then allow for much simpler implementations of min_t()/max_t(). All the usual "macros in all upper case will evaluate the arguments multiple times" rules apply. We should do all the same things for the regular min/max() vs MIN/MAX() cases, but that has the added complexity of various drivers defining their own local versions of MIN/MAX, so that needs another level of fixes first. Link: https://lore.kernel.org/all/b47fad1d0cf8449886ad148f8c013dae@AcuMS.aculab.com/ Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by:
-
