- 07 Apr, 2024 20 commits
-
-
Takashi Iwai authored
Pull emu10k1 fix patch series Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Both drivers provide both sample_new and sample_free, and it makes no sense to pretend that they could not. In fact, load_data() would already crash if sample_new was null. So remove the remaining null checks. Contrary to that, the emu10k1 driver actually has a null sample_reset, though I'm not convinced that this inconsistency is justified. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-18-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
There is no need for it to be 32 samples - 3 will do just fine (which is the interpolator's epsilon). The old size was presumably meant to compensate for the cache's presence, but we're now handling that properly. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-17-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Compensate for the cache lag of 64 frames, and actually populate the cache. Without these, the playback would start with garbage (which would be (mostly?) masqueraded by the note's attack phase). Note that we set the starting address only 61 frames ahead, to compensate for the interpolator's epsilon. Unlike for PCM playback, we don't even need to manually silence-fill the first frames in the cache, because we insert some silence in front of each sample anyway. A challenge are extremely short samples with a loop end below the cache size, because a) we'd have to wrap the current address to be within the loop and b) automatic pre-filling of the cache with the right data does not work in this case. We could pre-fill the cache manually, but that's slow, requires additional code for each sample width, and is made even more complex by the driver's virtual address space having no contiguous mapping for the CPU. We could have the engine fill the cache piece-wise (which is really what happens when playback is running), but that would also be complex, and we'd need to wait for the engine to handle each piece, so it wouldn't be that much faster than the manual fill. For the case of requiring only one loop iteration prior to reaching the cache size, we could leverage the engine's looping mechanism around CCR_CACHELOOPFLAG, but this special case doesn't seem worth the complexity. So we just unroll the loop as far as necessary to be able to play back the sample without any fiddling. Pedantically, this would be incorrect for loop-until-release samples with a low loop end which are released very quickly, but that would be relatively harmless, is not a plausible use case in the first place, and SoundFont sample mode 3 isn't actually implemented anyway (it's conflated with mode 1, infinite looping). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-16-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Resulting from more reverse engineering in the course of debugging. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-15-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Instead of repeatedly checking the sample width, assign a size shift centrally. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-14-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The offsets are counted in samples, not in bytes. While the code block is being rewritten, also move it up a bit, to avoid churn in a subsequent patch. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-13-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
This de-duplicates the code slightly. But the real reason is that it moves the code up, which the next patch will depend on. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-12-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Samples are byte-sized in this mode, and thus the offset calculation needs no shifting. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-11-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The hardware supports S16LE and U8 samples, while U16LE and S8 (which the driver implicitly claims to support) require sign flipping. Note that this matters only for the GUS patch loader, as the implemented SoundFont v2.01 spec is limited to S16LE. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-10-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Convert some checks in snd_emu10k1_sample_new() back into assertions (as they were prior to da3cec35 (ALSA: Kill snd_assert() in sound/pci/*, 2008-08-08)), and move them into the low-level memory access functions they protect. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-9-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-8-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
This does several closely related things: - Move the code from the drivers into the SoundFont loader, which de-duplicates it. - Sort of explain the weird "recalculate address offset" feature. Note that I don't think it actually makes any sense - the calling user space code should do that. The background is certainly that the source data (the SoundFont format) uses pointers into a single wave block (and the API allows doing the same for on-board ROM), but the API expects the wave data from user space to be pre-chopped into individual patches anyway. - Make sure that the specified offsets actually lie within the supplied wave data. Note that we don't validate ROM offsets, so one can play back anything within the sound card's address space. - In load_guspatch(), don't call the sample_new callback anymore when the patch size is zero, as was already the case in load_data(). The callbacks would instantly return in that case anyway; these checks are now removed. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-7-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
This is required only to implement WAVE_BIDIR_LOOP and WAVE_LOOP_BACK in the GUS patch loader. It has not worked on emu10k1 since before ALSA hit mainline, yet nobody appears to have complained. And as it isn't super easy to implement, just admit defeat and clean up the code. If somebody wanted to resurrect the feature, the emu8k driver could serve as a template, but the code would be quite different. But arguably, this should be done in user space in the first place, as this doesn't represent a hardware feature (somewhat ironically, the actual GUS driver has no synth support, and therefore no GUS patch loader). Note that instead of properly rejecting affected samples, we continue to just pretend that the feature wasn't requested. This is extremely questionable behavior, but avoids that possibly unused instruments suddenly prevent loading the entire file, which would break backwards compatibility. But at least we log a warning now. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-6-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The field is explicitly documented to be initialized by the driver (which it actually is). Also, using patch_info.size would be actually wrong for 16-bit data, as one field counts samples, while the other counts bytes. load_guspatch() already did it right. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-5-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
Both bounds had off-by-one errors. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-4-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
The `client` parameter was not used, so eliminate it from the call chain. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-3-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
We forgot to remember the wavetable /proc entry, so we'd fail to free it at module unload. This matters only when only the synth module is unloaded, as unloading the card driver would tear down the sub-entry anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-2-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Shenghao Ding authored
Calibrated data was written into an incorrect register, which cause speaker protection sometimes malfuctions Fixes: 5be27f1e ("ALSA: hda/tas2781: Add tas2781 HDA driver") Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Cc: <stable@vger.kernel.org> Message-ID: <20240406132010.341-1-shenghao-ding@ti.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Vitaly Rodionov authored
Add support for HP SnowWhite laptops with CS35L51 amplifiers on I2C bus connected to Realtek codec. Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Message-ID: <20240405210635.22193-1-vitalyr@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 05 Apr, 2024 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v6.9-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.9 A relatively large set of fixes here, the biggest piece of it is a series correcting some problems with the delay reporting for Intel SOF cards but there's a bunch of other things. Everything here is driver specific except for a fix in the core for an issue with sign extension handling volume controls.
-
- 04 Apr, 2024 2 commits
-
-
Chaitanya Kumar Borah authored
In cases where the sof driver is unable to find the firmware and/or topology file [1], it exits without releasing the i915 runtime pm wakeref [2]. This results in dmesg warnings[3] during suspend/resume or driver unbind. Add remove_late() to the failure path of sof_init_environment so that i915 wakeref is released appropriately [1] [ 8.990366] sof-audio-pci-intel-mtl 0000:00:1f.3: SOF firmware and/or topology file not found. [ 8.990396] sof-audio-pci-intel-mtl 0000:00:1f.3: Supported default profiles [ 8.990398] sof-audio-pci-intel-mtl 0000:00:1f.3: - ipc type 1 (Requested): [ 8.990399] sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware file: intel/sof-ipc4/mtl/sof-mtl.ri [ 8.990401] sof-audio-pci-intel-mtl 0000:00:1f.3: Topology file: intel/sof-ace-tplg/sof-mtl-rt711-2ch.tplg [ 8.990402] sof-audio-pci-intel-mtl 0000:00:1f.3: Check if you have 'sof-firmware' package installed. [ 8.990403] sof-audio-pci-intel-mtl 0000:00:1f.3: Optionally it can be manually downloaded from: [ 8.990404] sof-audio-pci-intel-mtl 0000:00:1f.3: https://github.com/thesofproject/sof-bin/ [ 8.999088] sof-audio-pci-intel-mtl 0000:00:1f.3: error: sof_probe_work failed err: -2 [2] ref_tracker: 0000:00:02.0@ffff9b8511b6a378 has 1/5 users at track_intel_runtime_pm_wakeref.part.0+0x36/0x70 [i915] __intel_runtime_pm_get+0x51/0xb0 [i915] intel_runtime_pm_get+0x17/0x20 [i915] intel_display_power_get+0x2f/0x70 [i915] i915_audio_component_get_power+0x23/0x120 [i915] snd_hdac_display_power+0x89/0x130 [snd_hda_core] hda_codec_i915_init+0x3f/0x50 [snd_sof_intel_hda] hda_dsp_probe_early+0x170/0x250 [snd_sof_intel_hda_common] snd_sof_device_probe+0x224/0x320 [snd_sof] sof_pci_probe+0x15b/0x220 [snd_sof_pci] hda_pci_intel_probe+0x30/0x70 [snd_sof_intel_hda_common] local_pci_probe+0x4c/0xb0 pci_device_probe+0xcc/0x250 really_probe+0x18e/0x420 __driver_probe_device+0x7e/0x170 driver_probe_device+0x23/0xa0 [3] [ 484.105070] ------------[ cut here ]------------ [ 484.108238] thunderbolt 0000:00:0d.2: PM: pci_pm_suspend_late+0x0/0x50 returned 0 after 0 usecs [ 484.117106] i915 0000:00:02.0: i915 raw-wakerefs=1 wakelocks=1 on cleanup [ 484.792005] WARNING: CPU: 2 PID: 2405 at drivers/gpu/drm/i915/intel_runtime_pm.c:444 intel_runtime_pm_driver_release+0x6c/0x80 Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://github.com/thesofproject/linux/pull/4878Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://msgid.link/r/20240404184813.134566-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Vijendar Mukunda authored
Before ACP firmware loading, DSP interrupts are not expected. Sometimes after reboot, it's observed that before ACP firmware is loaded false DSP interrupt is reported. Registering the interrupt handler before acp initialization causing false interrupts sometimes on reboot as ACP reset is not applied. Correct the sequence by invoking acp initialization sequence prior to registering interrupt handler. Fixes: 738a2b5e ("ASoC: SOF: amd: Add IPC support for ACP IP block") Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240404041717.430545-1-Vijendar.Mukunda@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 03 Apr, 2024 2 commits
-
-
Peter Ujfalusi authored
During probe the DMIC/SSP offload is enabled and it is not reversed on remove. Add a remove wrapper for LNL to disable the offload for DMIC and SSP similarly to what is done during probe. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://msgid.link/r/20240403111839.27259-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
This v6.8 change didn't make it into the release, send it as a fix for v6.9.
-
- 02 Apr, 2024 11 commits
-
-
Mark Brown authored
Merge series from Zhang Yi <zhangyi@everest-semi.com>: We solved some issues related to headphone detection.And for using the same configuration in different power conditions,we modified the clock table
-
Amadeusz Sławiński authored
Modpost warns about missing module description, add it. Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240402130640.3310999-1-amadeuszx.slawinski@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Zhang Yi authored
We removed the configuration of ES8326_ADC_SCALE in es8326_jack_detect_handler because user changed the configuration by snd_controls Signed-off-by: Zhang Yi <zhangyi@everest-semi.com> Link: https://msgid.link/r/20240402062043.20608-5-zhangyi@everest-semi.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Zhang Yi authored
We got a headphone detection issue after suspend and resume. And we fixed it by modifying the configuration at es8326_suspend and invoke es8326_irq at es8326_resume. Signed-off-by: Zhang Yi <zhangyi@everest-semi.com> Link: https://msgid.link/r/20240402062043.20608-4-zhangyi@everest-semi.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Zhang Yi authored
We got a digital microphone feature issue. And we fixed it by modifying the clock table. Also, we changed the marco ES8326_CLK_ON declaration Signed-off-by: Zhang Yi <zhangyi@everest-semi.com> Link: https://msgid.link/r/20240402062043.20608-3-zhangyi@everest-semi.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Zhang Yi authored
We got an error report about headphone type detection and button detection. We fixed the headphone type detection error by adjusting the debounce timer configuration. And we fixed the button detection error by disabling the button detection feature when the headphone are unplugged and enabling it when headphone are plugged in. Signed-off-by: Zhang Yi <zhangyi@everest-semi.com> Link: https://msgid.link/r/20240402062043.20608-2-zhangyi@everest-semi.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Takashi Iwai authored
For shutting up spurious KMSAN uninit-value warnings, just replace kmalloc() calls with kzalloc() for the buffers used for communications. There should be no real issue with the original code, but it's still better to cover. Reported-by: syzbot+7fb05ccf7b3d2f9617b3@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/00000000000084b18706150bcca5@google.com Message-ID: <20240402063628.26609-1-tiwai@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Luke D. Jones authored
Fixes the realtek quirk to initialise the Cirrus amp correctly and adds related quirk for missing DSD properties. This model laptop has slightly updated internals compared to the previous version with Realtek Codec ID of 0x1caf. Signed-off-by: Luke D. Jones <luke@ljones.dev> Cc: <stable@vger.kernel.org> Message-ID: <20240402015126.21115-1-luke@ljones.dev> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
I Gede Agastya Darma Laksana authored
This patch addresses an issue with the Panasonic CF-SZ6's existing quirk, specifically its headset microphone functionality. Previously, the quirk used ALC269_FIXUP_HEADSET_MODE, which does not support the CF-SZ6's design of a single 3.5mm jack for both mic and audio output effectively. The device uses pin 0x19 for the headset mic without jack detection. Following verification on the CF-SZ6 and discussions with the original patch author, i determined that the update to ALC269_FIXUP_ASPIRE_HEADSET_MIC is the appropriate solution. This change is custom-designed for the CF-SZ6's unique hardware setup, which includes a single 3.5mm jack for both mic and audio output, connecting the headset microphone to pin 0x19 without the use of jack detection. Fixes: 0fca97a2 ("ALSA: hda/realtek - Add Panasonic CF-SZ6 headset jack quirk") Signed-off-by: I Gede Agastya Darma Laksana <gedeagas22@gmail.com> Cc: <stable@vger.kernel.org> Message-ID: <20240401174602.14133-1-gedeagas22@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Christian Bendiksen authored
This fixes the sound not working from internal speakers on Lenovo Legion Slim 7 16ARHA7 models. The correct subsystem ID have been added to cs35l41_hda_property.c and patch_realtek.c. Signed-off-by: Christian Bendiksen <christian@bendiksen.me> Cc: <stable@vger.kernel.org> Message-ID: <20240401122603.6634-1-christian@bendiksen.me> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
As already anticipated in the original commit, playback was broken for very short samples. I just didn't expect it to be an actual problem, because we're talking about less than 1.5 milliseconds here. But clearly such wavetable samples do actually exist. The problem was that for such short samples we'd set the current position beyond the end of the loop, so we'd run off the end of the sample and play garbage. This is a bigger (more audible) problem than the original one, which was that we'd start playback with garbage (whatever was still in the cache), which would be mostly masked by the note's attack phase. So revert to the old behavior for now. We'll subsequently fix it properly with a bigger patch series. Note that this isn't a full revert - the dead code is not re-introduced, because that would be silly. Fixes: df335e9a ("ALSA: emu10k1: fix synthesizer sample playback position and caching") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218625Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240401145805.528794-1-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 01 Apr, 2024 1 commit
-
-
Uwe Kleine-König authored
As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent the following section mismatch warning WARNING: modpost: sound/oss/dmasound/dmasound_paula: section mismatch in reference: amiga_audio_driver+0x8 (section: .data) -> amiga_audio_remove (section: .exit.text) that triggers on an allmodconfig W=1 build. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Message-ID: <c216a129aa88f3af5c56fe6612a472f7a882f048.1711748999.git.u.kleine-koenig@pengutronix.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 30 Mar, 2024 1 commit
-
-
Simon Trimmer authored
These ASUS laptops use the Realtek HDA codec combined with a number of CS35L56 amplifiers. The SSID of the GA403U matches a previous ASUS laptop - we can tell them apart because they use different codecs. Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Message-ID: <20240329112803.23897-1-simont@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 29 Mar, 2024 2 commits
-
-
Vijendar Mukunda authored
If acp_init() fails, acp pci driver probe should return error. Add acp_init() function return value check logic. Fixes: e61b4155 ("ASoC: amd: acp: refactor the acp init and de-init sequence") Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20240329053815.2373979-1-Vijendar.Mukunda@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Gergo Koteles authored
Since we put dvc_tlv static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it. Fix this W=1 build warning: include/sound/tas2781-tlv.h:18:35: warning: 'dvc_tlv' defined but not used [-Wunused-const-variable=] Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202403290354.v0StnRpc-lkp@intel.com/ Fixes: ae065d0c ("ALSA: hda/tas2781: remove digital gain kcontrol") Signed-off-by: Gergo Koteles <soyer@irl.hu> Message-ID: <0e461545a2a6e9b6152985143e50526322e5f76b.1711665731.git.soyer@irl.hu> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-