summaryrefslogtreecommitdiff
path: root/sound
AgeCommit message (Collapse)AuthorFilesLines
2021-10-12ALSA: usb-audio: Add quirk for VF0770Jonas Hahnfeld1-0/+42
The device advertises 8 formats, but only a rate of 48kHz is honored by the hardware and 24 bits give chopped audio, so only report the one working combination. This fixes out-of-the-box audio experience with PipeWire which otherwise attempts to choose S24_3LE (while PulseAudio defaulted to S16_LE). Signed-off-by: Jonas Hahnfeld <hahnjo@hahnjo.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-12ALSA: hda: avoid write to STATESTS if controller is in resetKai Vehmanen1-2/+3
The snd_hdac_bus_reset_link() contains logic to clear STATESTS register before performing controller reset. This code dates back to an old bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio codec probing robustness"). Originally the code was added to azx_reset(). The code was moved around in commit a41d122449be ("ALSA: hda - Embed bus into controller object") and ended up to snd_hdac_bus_reset_link() and called primarily via snd_hdac_bus_init_chip(). The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is called when controller is not in reset. In this case, STATESTS can be cleared. This can be useful e.g. when forcing a controller reset to retry codec probe. A normal non-power-on reset will not clear the bits. However, this old logic is problematic when controller is already in reset. The HDA specification states that controller must be taken out of reset before writing to registers other than GCTL.CRST (1.0a spec, 3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost if the controller is already in reset per the HDA specification mentioned. This has been harmless on older hardware. On newer generation of Intel PCIe based HDA controllers, if configured to report issues, this write will emit an unsupported request error. If ACPI Platform Error Interface (APEI) is enabled in kernel, this will end up to kernel log. Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if the function is called when controller is not in reset. Otherwise clearing the bits is not possible and should be skipped. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211012142935.3731820-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-12ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JWHui Wang1-0/+27
We need to define the codec pin 0x1b to be the mic, but somehow the mic doesn't support hot plugging detection, and Windows also has this issue, so we set it to phantom headset-mic. Also the determine_headset_type() often returns the omtp type by a mistake when we plug a ctia headset, this makes the mic can't record sound at all. Because most of the headset are ctia type nowadays and some machines have the fixed ctia type audio jack, it is possible this machine has the fixed ctia jack too. Here we set this mic jack to fixed ctia type, this could avoid the mic type detection mistake and make the ctia headset work stable. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214537 Reported-and-tested-by: msd <msd.mmq@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20211012114748.5238-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-11ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctlTakashi Iwai1-1/+71
Michael Forney reported an incorrect padding type that was defined in the commit 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") for PCM control mmap data. His analysis is correct, and this caused the misplacements of PCM control data on 32bit arch and 32bit compat mode. The bug is that the __pad2 definition in __snd_pcm_mmap_control64 struct was wrongly with __pad_before_uframe, which should have been __pad_after_uframe instead. This struct is used in SYNC_PTR ioctl and control mmap. Basically this bug leads to two problems: - The offset of avail_min field becomes wrong, it's placed right after appl_ptr without padding on little-endian - When appl_ptr and avail_min are read as 64bit values in kernel side, the values become either zero or corrupted (mixed up) One good news is that, because both user-space and kernel misunderstand the wrong offset, at least, 32bit application running on 32bit kernel works as is. Also, 64bit applications are unaffected because the padding size is zero. The remaining problem is the 32bit compat mode; as mentioned in the above, avail_min is placed right after appl_ptr on little-endian archs, 64bit kernel reads bogus values for appl_ptr updates, which may lead to streaming bugs like jumping, XRUN or whatever unexpected. (However, we haven't heard any serious bug reports due to this over years, so practically seen, it's fairly safe to assume that the impact by this bug is limited.) Ideally speaking, we should correct the wrong mmap status control definition. But this would cause again incompatibility with the existing binaries, and fixing it (e.g. by renumbering ioctls) would be really messy. So, as of this patch, we only correct the behavior of 32bit compat mode and keep the rest as is. Namely, the SYNC_PTR ioctl is now handled differently in compat mode to read/write the 32bit values at the right offsets. The control mmap of 32bit apps on 64bit kernels has been already disabled (which is likely rather an overlook, but this worked fine at this time :), so covering SYNC_PTR ioctl should suffice as a fallback. Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") Reported-by: Michael Forney <mforney@mforney.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Cc: <stable@vger.kernel.org> Cc: Rich Felker <dalias@libc.org> Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-11ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2Cameron Berkenpas1-1/+1
The previous patch's HDA verb initialization for the Lenovo 13s sequence was slightly off. This updated verb sequence has been tested and confirmed working. Fixes: ad7cc2d41b7a ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555 Cc: <stable@vger.kernel.org> Signed-off-by: Cameron Berkenpas <cam@neo-zeon.de> Link: https://lore.kernel.org/r/20211010225410.23423-1-cam@neo-zeon.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-07ALSA: hda: intel: Allow repeatedly probing on codec configuration errorsTakashi Iwai6-25/+55
It seems that a few recent AMD systems show the codec configuration errors at the early boot, while loading the driver at a later stage works magically. Although the root cause of the error isn't clear, it's certainly not bad to allow retrying the codec probe in such a case if that helps. This patch adds the capability for retrying the probe upon codec probe errors on the certain AMD platforms. The probe_work is changed to a delayed work, and at the secondary call, it'll jump to the codec probing. Note that, not only adding the re-probing, this includes the behavior changes in the codec configuration function. Namely, snd_hda_codec_configure() won't unregister the codec at errors any longer. Instead, its caller, azx_codec_configure() unregisters the codecs with the probe failures *if* any codec has been successfully configured. If all codec probe failed, it doesn't unregister but let it re-probed -- which is the most case we're seeing and this patch tries to improve. Even if the driver doesn't re-probe or give up, it will go to the "free-all" error path, hence the leftover codecs shall be disabled / deleted in anyway. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190801 Link: https://lore.kernel.org/r/20211006141940.2897-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-06ALSA: hda/realtek: Add quirk for TongFang PHxTxX1Werner Sembach1-1/+25
This applies a SND_PCI_QUIRK(...) to the TongFang PHxTxX1 barebone. This fixes the issue of the internal Microphone not working after booting another OS. When booting a certain another OS this barebone keeps some coeff settings even after a cold shutdown. These coeffs prevent the microphone detection from working in Linux, making the Laptop think that there is always an external microphone plugged-in and therefore preventing the use of the internal one. The relevant indexes and values where gathered by naively diff-ing and reading a working and a non-working coeff dump. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211006130415.538243-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-05ALSA: hda/realtek - ALC236 headset MIC recording issueKailang Yang1-1/+4
In power save mode, the recording voice from headset mic will 2s more delay. Add this patch will solve this issue. [ minor coding style fix by tiwai ] Signed-off-by: Kailang Yang <kailang@realtek.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/ccb0cdd5bbd7486eabbd8d987d384cb0@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-05ALSA: usb-audio: Enable rate validation for Scarlett devicesTakashi Iwai1-0/+2
The Scarlett device series from Focusrite Novation seem requiring the sample rate validations as we've done for MOTU devices; otherwise the driver probes invalid audioformat entries that contain the sample rates that actually don't work, and this may result in an incomplete setup as reported recently. This patch adds the needed quirk flag for enabling the sample rate validation for Focusrite Novation devices. Fixes: fe773b8711e3 ("ALSA: usb-audio: workaround for iface reset issue") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214493 Link: https://lore.kernel.org/r/20211004074050.28241-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-04ALSA: hda/realtek: Add quirk for Clevo X170KM-GWerner Sembach1-0/+1
This applies a SND_PCI_QUIRK(...) to the Clevo X170KM-G barebone. This fixes the issue of the devices internal Speaker not working. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211001133111.428249-3-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-04ALSA: hda/realtek: Complete partial device name to avoid ambiguityWerner Sembach1-1/+1
The string "Clevo X170" is not enough to unambiguously identify the correct device. Fixing it so another Clevo barebone name starting with "X170" can be added without causing confusion. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211001133111.428249-2-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-01ALSA: hda - Enable headphone mic on Dell Latitude laptops with ALC3254Chris Chiu1-0/+2
The headphone mic is not working on Dell Latitude laptops with ALC3254. The codec vendor id is 0x10ec0295 and share the same pincfg as defined in ALC295_STANDARD_PINS. So the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE will be applied per alc269_pin_fixup_tbl[] but actually the headphone mic is using NID 0x1b instead of 0x1a. The ALC269_FIXUP_DELL4_MIC_NO_PRESENCE need to be applied instead. Use ALC269_FIXUP_DELL4_MIC_NO_PRESENCE for particular models before a generic fixup comes out. Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211001062856.1037901-1-chris.chiu@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-30ALSA: seq: Fix a potential UAF by wrong private_free call orderTakashi Iwai1-5/+3
John Keeping reported and posted a patch for a potential UAF in rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be called after the associated rawmidi object got already freed. After a deeper look, it turned out that the bug is rather the incorrect private_free call order for a snd_seq_device. The snd_seq_device private_free gets called at the release callback of the sequencer device object, while this was rather expected to be executed at the snd_device call chains that runs at the beginning of the whole card-free procedure. It's been broken since the rewrite of sequencer-device binding (although it hasn't surfaced because the sequencer device release happens usually right along with the card device release). This patch corrects the private_free call to be done in the right place, at snd_seq_device_dev_free(). Fixes: 7c37ae5c625a ("ALSA: seq: Rewrite sequencer device binding with standard bus") Reported-and-tested-by: John Keeping <john@metanate.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-30ALSA: hda/realtek: Enable 4-speaker output for Dell Precision 5560 laptopJohn Liu1-0/+1
The Dell Precision 5560 laptop appears to use the 4-speakers-on-ALC289 audio just like its sibling product XPS 9510, so it requires the same quirk to enable woofer output. Tested on my Dell Precision 5560. Signed-off-by: John Liu <johnliu55tw@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210930115316.659-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-30ALSA: usb-audio: Fix a missing error check in scarlett gen2 mixerTakashi Iwai1-0/+2
The check of the returned error code is missing in scarlett2_update_monitor_other(). Let's fix it. Fixes: d5bda7e03982 ("ALSA: usb-audio: scarlett2: Add support for the talkback feature") Reported-by: kernel test robot <lkp@intel.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/202109131831.9IodEzRx-lkp@intel.com Link: https://lore.kernel.org/r/20210929073540.9611-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-28ALSA: pcsp: Make hrtimer forwarding more robustThomas Gleixner1-1/+1
The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: alsa-devel@alsa-project.org Cc: Takashi Iwai <tiwai@suse.com> Cc: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-23ALSA: rawmidi: introduce SNDRV_RAWMIDI_IOCTL_USER_PVERSIONJaroslav Kysela1-0/+9
The new framing mode causes the user space regression, because the alsa-lib code does not initialize the reserved space in the params structure when the device is opened. This change adds SNDRV_RAWMIDI_IOCTL_USER_PVERSION like we do for the PCM interface for the protocol acknowledgment. Cc: David Henningsson <coding@diwic.se> Cc: <stable@vger.kernel.org> Fixes: 08fdced60ca0 ("ALSA: rawmidi: Add framing mode") BugLink: https://github.com/alsa-project/alsa-lib/issues/178 Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20210920171850.154186-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-21ALSA: firewire-motu: fix truncated bytes in message tracepointsTakashi Sakamoto1-3/+4
In MOTU protocol v2/v3, first two data chunks across 2nd and 3rd data channels includes message bytes from device. The total size of message is 48 bits per data block. The 'data_block_message' tracepoints event produced by ALSA firewire-motu driver exposes the sequence of messages to userspace in 64 bit storage, however lower 32 bits are actually available since current implementation truncates 16 bits in upper of the message as a result of bit shift operation within 32 bit storage. This commit fixes the bug by perform the bit shift in 64 bit storage. Fixes: c6b0b9e65f09 ("ALSA: firewire-motu: add tracepoints for messages for unique protocol") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210920110734.27161-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-21Merge tag 'asoc-fix-v5.15-rc2' of ↵Takashi Iwai15-49/+94
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.15 A crop of mostly device specific fixes that have been applied since the merge window, nothing particularly standout here.
2021-09-17ASoC: SOF: trace: Omit error print when waking up trace sleepersPeter Ujfalusi1-1/+0
Do not print error message from snd_sof_trace_notify_for_error() when possible sleeping trace work is woken up to flush the remaining debug information. This action by itself is not an error, it is just an action we take when an error occurs to make sure that all information have been fed to the userspace (if we have trace in use). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210917085108.25532-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-17ASoC: mediatek: mt8195: remove wrong fixup assignment on HDMITXTrevor Wu1-4/+3
S24_LE params fixup is only required for DPTX. Remove fixup ops assignment for HDMITX. Fixes: 40d605df0a7b ("ASoC: mediatek: mt8195: add machine driver with mt6359, rt1019 and rt5682") Signed-off-by: Trevor Wu <trevor.wu@mediatek.com> Link: https://lore.kernel.org/r/20210917082805.30898-1-trevor.wu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-16ASoC: SOF: loader: Re-phrase the missing firmware error to avoid duplicationPeter Ujfalusi1-3/+3
In case the firmware is missing we will have the following in the kernel log: 1 | Direct firmware load for intel/sof/sof-tgl-h.ri failed with error -2 2 | error: request firmware intel/sof/sof-tgl-h.ri failed err: -2 3 | you may need to download the firmware from https://github.com/thesofproject/sof-bin/ 4 | error: failed to load DSP firmware -2 5 | error: sof_probe_work failed err: -2 The first line is the standard, request_firmware() warning. The second and third line is printed in snd_sof_load_firmware_raw() Note that the first and second line is mostly identical. With this patch the log will be changed to: 1 | Direct firmware load for intel/sof/sof-tgl-h.ri failed with error -2 2 | error: sof firmware file is missing, you might need to 3 | download it from https://github.com/thesofproject/sof-bin/ 4 | error: failed to load DSP firmware -2 5 | error: sof_probe_work failed err: -2 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210916085342.29993-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-16ASoC: SOF: loader: release_firmware() on load failure to avoid batchingMarc Herbert2-3/+3
Invoke release_firmware() when the firmware fails to boot in sof_probe_continue(). The request_firmware() framework must be informed of failures in sof_probe_continue() otherwise its internal "batching" feature (different from caching) cached the firmware image forever. Attempts to correct the file in /lib/firmware/ were then silently and confusingly ignored until the next reboot. Unloading the drivers did not help because from their disconnected perspective the firmware had failed so there was nothing to release. Also leverage the new snd_sof_fw_unload() function to simplify the snd_sof_device_remove() function. Signed-off-by: Marc Herbert <marc.herbert@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20210916085008.28929-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-16ALSA: hda/cs8409: Setup Dolphin Headset Mic as Phantom JackStefan Binding1-0/+3
Dell's requirement to have headset mic as phantom jack on this specific dolphin hardware platform. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210916095646.7631-1-vitalyr@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-16ALSA: pcxhr: "fix" PCXHR_REG_TO_PORT definitionAlexey Dobriyan1-1/+1
The following preprocessor directive is non-compliant: #undef PCXHR_REG_TO_PORT(x) gcc warns about extra tokens but nobody sees them as they are under if branch which is never parsed. Make it an #error, it is not clear to me what the author meant. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Link: https://lore.kernel.org/r/YUCCv47sm4zf9OVO@localhost.localdomain Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-15ASoC: SOF: imx: imx8m: Bar index is only valid for IRAM and SRAM typesPeter Ujfalusi1-1/+8
i.MX8 only uses SOF_FW_BLK_TYPE_IRAM (1) and SOF_FW_BLK_TYPE_SRAM (3) bars, everything else is left as 0 in sdev->bar[] array. If a broken or purposefully crafted firmware image is loaded with other types of FW_BLK_TYPE then a kernel crash can be triggered. Make sure that only IRAM/SRAM type is converted to bar index. Fixes: afb93d716533d ("ASoC: SOF: imx: Add i.MX8M HW support") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20210915122116.18317-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-15ASoC: SOF: imx: imx8: Bar index is only valid for IRAM and SRAM typesPeter Ujfalusi1-1/+8
i.MX8 only uses SOF_FW_BLK_TYPE_IRAM (1) and SOF_FW_BLK_TYPE_SRAM (3) bars, everything else is left as 0 in sdev->bar[] array. If a broken or purposefully crafted firmware image is loaded with other types of FW_BLK_TYPE then a kernel crash can be triggered. Make sure that only IRAM/SRAM type is converted to bar index. Fixes: 202acc565a1f0 ("ASoC: SOF: imx: Add i.MX8 HW support") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20210915122116.18317-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-15ASoC: SOF: Fix DSP oops stack dump output contentsYong Zhi1-2/+2
Fix @buf arg given to hex_dump_to_buffer() and stack address used in dump error output. Fixes: e657c18a01c8 ('ASoC: SOF: Add xtensa support') Signed-off-by: Yong Zhi <yong.zhi@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20210915063230.29711-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-14ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i ↵Cameron Berkenpas1-0/+129
15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops. This patch initializes and enables speaker output on the Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 series of laptops using the HDA verb sequence specific to each model. Speaker automute is suppressed for the Lenovo Legion 7i 15IMHG05 to avoid breaking speaker output on resume and when devices are unplugged from its headphone jack. Thanks to: Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle and all others that helped. [ minor coding style fixes by tiwai ] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555 Signed-off-by: Cameron Berkenpas <cam@neo-zeon.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210913212627.339362-1-cam@neo-zeon.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-13ALSA: usb-audio: Unify mixer resume and reset_resume procedureTakashi Iwai4-39/+10
USB-audio driver assumes that the normal resume would preserve the device configuration while reset_resume wouldn't, and tries to restore the mixer elements only at reset_resume callback. However, this seems too naive, and some devices do behave differently, resetting the volume at the normal resume; this resulted in the inconsistent volume that surprised users. This patch changes the mixer resume code to handle both the normal and reset resume in the same way, always restoring the original mixer element values. This allows us to unify the both callbacks as well as dropping the no longer used reset_resume field, which ends up with a good code reduction. A slight behavior change by this patch is that now we assign restore_mixer_value() as the default resume callback, and the function is no longer called at reset-resume when the resume callback is overridden by the quirk function. That is, if needed, the quirk resume function would have to handle similarly as restore_mixer_value() by itself. Reported-by: En-Shuo Hsu <enshuo@chromium.org> Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org> Link: https://lore.kernel.org/r/CADDZ45UPsbpAAqP6=ZkTT8BE-yLii4Y7xSDnjK550G2DhQsMew@mail.gmail.com Link: https://lore.kernel.org/r/20210910105155.12862-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-13Revert "ALSA: hda: Drop workaround for a hang at shutdown again"Takashi Iwai1-3/+9
This reverts commit 8fc8e903156f42c66245838441d03607e9067381. It was expected that the fixes in HD-audio codec side would make the workaround redundant, but unfortunately it doesn't seem sufficing. Resurrect the workaround for now. Fixes: 8fc8e903156f ("ALSA: hda: Drop workaround for a hang at shutdown again") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214045 Link: https://lore.kernel.org/r/20210913124330.24530-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-13ALSA: oxfw: fix transmission method for Loud models based on OXFW971Takashi Sakamoto1-5/+8
Loud Technologies Mackie Onyx 1640i (former model) is identified as the model which uses OXFW971. The analysis of packet dump shows that it transfers events in blocking method of IEC 61883-6, however the default behaviour of ALSA oxfw driver is for non-blocking method. This commit adds code to detect it assuming that all of loud models based on OXFW971 have such quirk. It brings no functional change except for alignment rule of PCM buffer. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20210913021042.10085-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-10Merge series "ASoC: fsl: register platform component before registering cpu ↵Mark Brown5-26/+48
dai" from Shengjiu Wang <shengjiu.wang@nxp.com>: There is no defer probe when adding platform component to snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime() snd_soc_register_card() -> snd_soc_bind_card() -> snd_soc_add_pcm_runtime() -> adding cpu dai -> adding codec dai -> adding platform component. So if the platform component is not ready at that time, then the sound card still registered successfully, but platform component is empty, the sound card can't be used. As there is defer probe checking for cpu dai component, then register platform component before cpu dai to avoid such issue. This patch set is to fix this issue for SAI, ESAI, MICFIL, SPDIF, XCVR drivers. Shengjiu Wang (5): ASoC: fsl_sai: register platform component before registering cpu dai ASoC: fsl_esai: register platform component before registering cpu dai ASoC: fsl_micfil: register platform component before registering cpu dai ASoC: fsl_spdif: register platform component before registering cpu dai ASoC: fsl_xcvr: register platform component before registering cpu dai sound/soc/fsl/fsl_esai.c | 16 ++++++++++------ sound/soc/fsl/fsl_micfil.c | 15 ++++++++++----- sound/soc/fsl/fsl_sai.c | 14 +++++++++----- sound/soc/fsl/fsl_spdif.c | 14 +++++++++----- sound/soc/fsl/fsl_xcvr.c | 15 ++++++++++----- 5 files changed, 48 insertions(+), 26 deletions(-) -- 2.17.1
2021-09-10ASoC: mediatek: common: handle NULL case in suspend/resume functionTrevor Wu1-8/+11
When memory allocation for afe->reg_back_up fails, reg_back_up can't be used. Keep the suspend/resume flow but skip register backup when afe->reg_back_up is NULL, in case illegal memory access happens. Fixes: 283b612429a2 ("ASoC: mediatek: implement mediatek common structure") Signed-off-by: Trevor Wu <trevor.wu@mediatek.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210910092613.30188-1-trevor.wu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-10ASoC: fsl_xcvr: register platform component before registering cpu daiShengjiu Wang1-5/+10
There is no defer probe when adding platform component to snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime() snd_soc_register_card() -> snd_soc_bind_card() -> snd_soc_add_pcm_runtime() -> adding cpu dai -> adding codec dai -> adding platform component. So if the platform component is not ready at that time, then the sound card still registered successfully, but platform component is empty, the sound card can't be used. As there is defer probe checking for cpu dai component, then register platform component before cpu dai to avoid such issue. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1630665006-31437-6-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-10ASoC: fsl_spdif: register platform component before registering cpu daiShengjiu Wang1-5/+9
There is no defer probe when adding platform component to snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime() snd_soc_register_card() -> snd_soc_bind_card() -> snd_soc_add_pcm_runtime() -> adding cpu dai -> adding codec dai -> adding platform component. So if the platform component is not ready at that time, then the sound card still registered successfully, but platform component is empty, the sound card can't be used. As there is defer probe checking for cpu dai component, then register platform component before cpu dai to avoid such issue. Fixes: a2388a498ad2 ("ASoC: fsl: Add S/PDIF CPU DAI driver") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1630665006-31437-5-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-10ASoC: fsl_micfil: register platform component before registering cpu daiShengjiu Wang1-5/+10
There is no defer probe when adding platform component to snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime() snd_soc_register_card() -> snd_soc_bind_card() -> snd_soc_add_pcm_runtime() -> adding cpu dai -> adding codec dai -> adding platform component. So if the platform component is not ready at that time, then the sound card still registered successfully, but platform component is empty, the sound card can't be used. As there is defer probe checking for cpu dai component, then register platform component before cpu dai to avoid such issue. Fixes: 47a70e6fc9a8 ("ASoC: Add MICFIL SoC Digital Audio Interface driver.") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1630665006-31437-4-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-10ASoC: fsl_esai: register platform component before registering cpu daiShengjiu Wang1-6/+10
There is no defer probe when adding platform component to snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime() snd_soc_register_card() -> snd_soc_bind_card() -> snd_soc_add_pcm_runtime() -> adding cpu dai -> adding codec dai -> adding platform component. So if the platform component is not ready at that time, then the sound card still registered successfully, but platform component is empty, the sound card can't be used. As there is defer probe checking for cpu dai component, then register platform component before cpu dai to avoid such issue. Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1630665006-31437-3-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-10ASoC: fsl_sai: register platform component before registering cpu daiShengjiu Wang1-5/+9
There is no defer probe when adding platform component to snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime() snd_soc_register_card() -> snd_soc_bind_card() -> snd_soc_add_pcm_runtime() -> adding cpu dai -> adding codec dai -> adding platform component. So if the platform component is not ready at that time, then the sound card still registered successfully, but platform component is empty, the sound card can't be used. As there is defer probe checking for cpu dai component, then register platform component before cpu dai to avoid such issue. Fixes: 435508214942 ("ASoC: Add SAI SoC Digital Audio Interface driver") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1630665006-31437-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-09Merge tag 'sound-fix-5.15-rc1' of ↵Linus Torvalds11-61/+91
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes that have been gathered before rc1, including a few regression fixes for the problem in the previous pull request" * tag 'sound-fix-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: gus: Fix repeated probe for ISA interwave card ALSA: gus: Fix repeated probes of snd_gus_create() ALSA: vx222: fix null-ptr-deref ASoC: rockchip: i2s: Fix concurrency between tx/rx ASoC: mt8195: correct the dts parsing logic about DPTX and HDMITX ASoC: Intel: boards: Fix CONFIG_SND_SOC_SDW_MOCKUP select ASoC: dt-bindings: fsl_rpmsg: Add compatible string for i.MX8ULP ALSA: usb-audio: Add registration quirk for JBL Quantum 800 ASoC: rt5682: fix headset background noise when S3 state ASoC: dt-bindings: mt8195: remove dependent headers in the example ASoC: mediatek: SND_SOC_MT8195 should depend on ARCH_MEDIATEK ASoC: samsung: s3c24xx_simtec: fix spelling mistake "devicec" -> "device" ASoC: audio-graph: respawn Platform Support ASoC: mediatek: mt8195: add MTK_PMIC_WRAP dependency
2021-09-09ASoC: mediatek: add required config dependencyTrevor Wu1-0/+3
Because SND_SOC_MT8195 depends on COMPILE_TEST, it's possible to build MT8195 driver in many different config combinations. Add all dependent config for SND_SOC_MT8195 in case some errors happen when COMPILE_TEST is enabled. Signed-off-by: Trevor Wu <trevor.wu@mediatek.com> Reported-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20210909065533.2114-1-trevor.wu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-09ASoC: Intel: sof_sdw: tag SoundWire BEs as non-atomicPierre-Louis Bossart1-0/+5
The SoundWire BEs make use of 'stream' functions for .prepare and .trigger. These functions will in turn force a Bank Switch, which implies a wait operation. Mark SoundWire BEs as nonatomic for consistency, but keep all other types of BEs as is. The initialization of .nonatomic is done outside of the create_sdw_dailink helper to avoid adding more parameters to deal with a single exception to the rule that BEs are atomic. Suggested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <bard.liao@intel.com> Link: https://lore.kernel.org/r/20210907184436.33152-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-08Merge tag 'asoc-fix-v5.15-rc1' of ↵Takashi Iwai7-18/+27
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.15 A collection of fixes that came in during the merge window, nothing too remarkable but a reasonably large number of fixes.
2021-09-07ALSA: gus: Fix repeated probe for ISA interwave cardTakashi Iwai1-30/+31
The legacy ISA probe tries to probe the card repeatedly, and this would conflict with the refactoring using devres. Put the card creation out of the loop and only probe GUS object repeatedly. Fixes: 5b88da3c800f ("ALSA: gus: Allocate resources with device-managed APIs") Link: https://lore.kernel.org/r/20210907093930.29009-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-07ALSA: gus: Fix repeated probes of snd_gus_create()Takashi Iwai1-13/+31
GUS card object may be repeatedly probed for the legacy ISA devices, and the behavior doesn't fit with the devres resource management. Revert partially back to the classical way for the snd_gus_card object, so that the repeated calls of snd_gus_create() are allowed. Fixes: 5b88da3c800f ("ALSA: gus: Allocate resources with device-managed APIs") Reported-by: kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/r/20210907093930.29009-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-07ALSA: vx222: fix null-ptr-derefTong Zhang1-0/+1
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 <ztong0001@gmail.com> Link: https://lore.kernel.org/r/20210907014746.1445278-1-ztong0001@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-03Merge tag 'kbuild-v5.15' of ↵Linus Torvalds3-3/+0
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Add -s option (strict mode) to merge_config.sh to make it fail when any symbol is redefined. - Show a warning if a different compiler is used for building external modules. - Infer --target from ARCH for CC=clang to let you cross-compile the kernel without CROSS_COMPILE. - Make the integrated assembler default (LLVM_IAS=1) for CC=clang. - Add <linux/stdarg.h> to the kernel source instead of borrowing <stdarg.h> from the compiler. - Add Nick Desaulniers as a Kbuild reviewer. - Drop stale cc-option tests. - Fix the combination of CONFIG_TRIM_UNUSED_KSYMS and CONFIG_LTO_CLANG to handle symbols in inline assembly. - Show a warning if 'FORCE' is missing for if_changed rules. - Various cleanups * tag 'kbuild-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (39 commits) kbuild: redo fake deps at include/ksym/*.h kbuild: clean up objtool_args slightly modpost: get the *.mod file path more simply checkkconfigsymbols.py: Fix the '--ignore' option kbuild: merge vmlinux_link() between ARCH=um and other architectures kbuild: do not remove 'linux' link in scripts/link-vmlinux.sh kbuild: merge vmlinux_link() between the ordinary link and Clang LTO kbuild: remove stale *.symversions kbuild: remove unused quiet_cmd_update_lto_symversions gen_compile_commands: extract compiler command from a series of commands x86: remove cc-option-yn test for -mtune= arc: replace cc-option-yn uses with cc-option s390: replace cc-option-yn uses with cc-option ia64: move core-y in arch/ia64/Makefile to arch/ia64/Kbuild sparc: move the install rule to arch/sparc/Makefile security: remove unneeded subdir-$(CONFIG_...) kbuild: sh: remove unused install script kbuild: Fix 'no symbols' warning when CONFIG_TRIM_UNUSD_KSYMS=y kbuild: Switch to 'f' variants of integrated assembler flag kbuild: Shuffle blank line to improve comment meaning ...
2021-09-03ASoC: rockchip: i2s: Fix concurrency between tx/rxSugar Zhang1-0/+7
This patch adds lock to fix comcurrency between tx/rx to fix 'rockchip-i2s ff070000.i2s; fail to clear' Considering the situation; tx stream rx stream | | | disable enable | | reset After this patch: lock | tx stream | enable | unlock -------- --------- lock | rx stream | disable | reset | unlock Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com> Link: https://lore.kernel.org/r/1630674434-650-1-git-send-email-sugar.zhang@rock-chips.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-03ASoC: mt8195: correct the dts parsing logic about DPTX and HDMITXTrevor Wu1-12/+10
According to the description in dt-bindings, phandle assignment of HDMI TX and DP TX are not required properties, but driver regards them as required properties. In real use case, it's expected that DP TX and HDMI TX are optional features, so correct the behavior in driver. Fixes: 40d605df0a7b ("ASoC: mediatek: mt8195: add machine driver with mt6359, rt1019 and rt5682") Signed-off-by: Trevor Wu <trevor.wu@mediatek.com> Link: https://lore.kernel.org/r/20210903060049.20764-1-trevor.wu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-03ASoC: Intel: boards: Fix CONFIG_SND_SOC_SDW_MOCKUP selectNathan Chancellor1-1/+1
When CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is enabled without CONFIG_EXPERT, there is a Kconfig warning about unmet dependencies: WARNING: unmet direct dependencies detected for SND_SOC_SDW_MOCKUP Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && EXPERT [=n] && SOUNDWIRE [=y] Selected by [y]: - SND_SOC_INTEL_SOUNDWIRE_SOF_MACH [=y] && ... Selecting a symbol does not account for dependencies. There are three ways to resolve this: 1. Make CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH select CONFIG_SND_SOC_SDW_MOCKUP only if CONFIG_EXPERT is set. 2. Make CONFIG_SND_SOC_SDW_MOCKUP's prompt depend on CONFIG_EXPERT so that it can be selected by options that only depend on CONFIG_SOUNDWIRE but still appear as a prompt to the user when CONFIG_EXPERT is set. 3. Make CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH imply CONFIG_SND_SOC_SDW_MOCKUP, which will select CONFIG_SND_SOC_SDW_MOCKUP when its dependencies are enabled but still allow the user to disable it. Go with the third option as it gives the most flexibility while retaining the original intent of the select. Fixes: 0ccac3bcf356 ("ASoC: Intel: boards: sof_sdw: add SoundWire mockup codecs for tests") Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210902181217.2958966-1-nathan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 21:21:09 +0000