- 12 Apr, 2022 5 commits
-
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 567f5875 ("ALSA: ad1889: Allocate resources with device-managed APIs") Link: https://lore.kernel.org/r/20220412102636.16000-4-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 111601ff ("ALSA: sc6000: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 35a245ec ("ALSA: galaxy: Allocate resources with device-managed APIs") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412102636.16000-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 9c211bf3 ("ALSA: echoaudio: Allocate resources with device-managed APIs") Reported-and-tested-by:
Zheyu Ma <zheyuma97@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/CAMhUBjm2AdyEZ_-EgexdNDN7SvY4f89=4=FwAL+c0Mg0O+X50A@mail.gmail.com Link: https://lore.kernel.org/r/20220412093141.8008-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
This is a small helper function to handle the error path more easily when an error happens during the probe for the device with the device-managed card. Since devres releases in the reverser order of the creations, usually snd_card_free() gets called at the last in the probe error path unless it already reached snd_card_register() calls. Due to this nature, when a driver expects the resource releases in card->private_free, this might be called too lately. As a workaround, one should call the probe like: static int __some_probe(...) { // do real probe.... } static int some_probe(...) { return snd_card_free_on_error(dev, __some_probe(dev, ...)); } so that the snd_card_free() is called explicitly at the beginning of the error path from the probe. This function will be used in the upcoming fixes to address the regressions by devres usages. Fixes: e8ad415b ("ALSA: core: Add managed card creation") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220412093141.8008-2-tiwai@suse.deSigned-off-by:
-
- 11 Apr, 2022 2 commits
-
-
Tao Jin authored
For this specific device on Lenovo Thinkpad X12 tablet, the verbs were dumped by qemu running a guest OS that init this codec properly. After studying the dump, it turns out that the same quirk used by the other Lenovo devices can be reused. The patch was tested working against the mainline kernel. Cc: <stable@vger.kernel.org> Signed-off-by:
Tao Jin <tao-j@outlook.com> Link: https://lore.kernel.org/r/CO6PR03MB6241CD73310B37858FE64C85E1E89@CO6PR03MB6241.namprd03.prod.outlook.comSigned-off-by:
-
Fabio M. De Francesco authored
Syzbot reports "KASAN: null-ptr-deref Write in snd_pcm_format_set_silence".[1] It is due to missing validation of the "silence" field of struct "pcm_format_data" in "pcm_formats" array. Add a test for valid "pat" and, if it is not so, return -EINVAL. [1] https://lore.kernel.org/lkml/000000000000d188ef05dc2c7279@google.com/ Reported-and-tested-by: syzbot+205eb15961852c2c5974@syzkaller.appspotmail.com Signed-off-by:
Fabio M. De Francesco <fmdefrancesco@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220409012655.9399-1-fmdefrancesco@gmail.comSigned-off-by:
-
- 08 Apr, 2022 2 commits
-
-
Takashi Iwai authored
The current limit of max buffer size 1MB seems too small for modern devices with lots of channels and high sample rates. Let's make bigger, 4MB. Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220407212740.17920-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
In the implicit feedback mode, some parameters are tied between both playback and capture streams. One of the tied parameters is the period size, and this can be a problem if the device has different number of channels to both streams. Assume that an application opens a playback stream that has an implicit feedback from a capture stream, and it allocates up to the max period and buffer size as much as possible. When the capture device supports only more channels than the playback, the minimum period and buffer sizes become larger than the sizes the playback stream took. That is, the minimum size will be over the max size the driver limits, and PCM core sees as if no available configuration is found, returning -EINVAL mercilessly. For avoiding this problem, we have to look through the counter part of audioformat list for each sync ep, and checks the channels. If more channels are found there, we reduce the max period and buffer sizes accordingly. You may wonder that the patch adds only the evaluation of channels between streams, and what about other parameters? Both the format and the rate are tied in the implicit fb mode, hence they are always identical. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215792 Fixes: 5a6c3e11 ("ALSA: usb-audio: Add hw constraint for implicit fb sync") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220407211657.15087-1-tiwai@suse.deSigned-off-by:
-
- 07 Apr, 2022 3 commits
-
-
Pierre-Louis Bossart authored
Add missing AlderLake-PS and RaptorLake-S PCI IDs (already in HDaudio and SOF drivers), add comments and regroup by skew. Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220406190418.245044-1-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Randy Dunlap authored
When CONFIG_DMASOUND_ATARI=m and CONFIG_DMASOUND_Q40=y (or vice versa), dmasound_core.o can be built without dmasound_deinit() being defined, causing a build error: ERROR: modpost: "dmasound_deinit" [sound/oss/dmasound/dmasound_atari.ko] undefined! Modify dmasound_core.c and dmasound.h so that dmasound_deinit() is always available. The mixed modes (=y/=m) also mean that several variables and structs have to be declared in all cases. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202204032138.EFT9qGEd-lkp@intel.com Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Link: https://lore.kernel.org/r/20220405234118.24830-1-rdunlap@infradead.orgSigned-off-by:
-
Tim Crawford authored
Fixes speaker output and headset detection on Clevo PD50PNT. Signed-off-by:
Tim Crawford <tcrawford@system76.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220405182029.27431-1-tcrawford@system76.comSigned-off-by:
-
- 05 Apr, 2022 2 commits
-
-
Borislav Petkov authored
Fix: sound/usb/midi.c: In function ‘snd_usbmidi_out_endpoint_create’: sound/usb/midi.c:1389:2: error: case label does not reduce to an integer constant case USB_ID(0xfc08, 0x0101): /* Unknown vendor Cable */ ^~~~ See https://lore.kernel.org/r/YkwQ6%2BtIH8GQpuct@zn.tnic for the gory details as to why it triggers with older gccs only. [ A slight correction with parentheses around the argument by tiwai ] Signed-off-by:Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20220405151517.29753-3-bp@alien8.deSigned-off-by:
-
Kai Vehmanen authored
In systems with only a discrete i915 GPU, the acomp init will always timeout for the PCH HDA controller instance. Avoid the timeout by checking the PCI device hierarchy whether any display class PCI device can be found on the system, and at the same level as the HDA PCI device. If found, proceed with the acomp init, which will wait until i915 probe is complete and component binding can proceed. If no matching display device is found, the audio component bind can be safely skipped. The bind timeout will still be hit if the display is present in the system, but i915 driver does not bind to it by configuration choice or probe error. In this case the 60sec timeout will be hit. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20220405123622.2874457-1-kai.vehmanen@linux.intel.comSigned-off-by:
-
- 30 Mar, 2022 4 commits
-
-
Takashi Iwai authored
syzbot caught a potential deadlock between the PCM runtime->buffer_mutex and the mm->mmap_lock. It was brought by the recent fix to cover the racy read/write and other ioctls, and in that commit, I overlooked a (hopefully only) corner case that may take the revert lock, namely, the OSS mmap. The OSS mmap operation exceptionally allows to re-configure the parameters inside the OSS mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the copy_from/to_user calls at read/write operations also take the mm->mmap_lock internally, hence it may lead to a AB/BA deadlock. A similar problem was already seen in the past and we fixed it with a refcount (in commit b2483716). The former fix covered only the call paths with OSS read/write and OSS ioctls, while we need to cover the concurrent access via both ALSA and OSS APIs now. This patch addresses the problem above by replacing the buffer_mutex lock in the read/write operations with a refcount similar as we've used for OSS. The new field, runtime->buffer_accessing, keeps the number of concurrent read/write operations. Unlike the former buffer_mutex protection, this protects only around the copy_from/to_user() calls; the other codes are basically protected by the PCM stream lock. The refcount can be a negative, meaning blocked by the ioctls. If a negative value is seen, the read/write aborts with -EBUSY. In the ioctl side, OTOH, they check this refcount, too, and set to a negative value for blocking unless it's already being accessed. Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com Fixes: dca947d4 ("ALSA: pcm: Fix races among concurrent read/write and buffer changes") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.18' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.18 A few fixes that came in during the merge window, all fairly routine.
-
Mohan Kumar authored
There is a corner case with unsol event handling during codec runtime suspending state. When the codec runtime suspend call initiated, the codec->in_pm atomic variable would be 0, currently the codec runtime suspend function calls snd_hdac_enter_pm() which will just increments the codec->in_pm atomic variable. Consider unsol event happened just after this step and before snd_hdac_leave_pm() in the codec runtime suspend function. The snd_hdac_power_up_pm() in the unsol event flow in hdmi_present_sense_via_verbs() function would just increment the codec->in_pm atomic variable without calling pm_runtime_get_sync function. As codec runtime suspend flow is already in progress and in parallel unsol event is also accessing the codec verbs, as soon as codec suspend flow completes and clocks are switched off before completing the unsol event handling as both functions doesn't wait for each other. This will result in below errors [ 589.428020] tegra-hda 3510000.hda: azx_get_response timeout, switching to polling mode: last cmd=0x505f2f57 [ 589.428344] tegra-hda 3510000.hda: spurious response 0x80000074:0x5, last cmd=0x505f2f57 [ 589.428547] tegra-hda 3510000.hda: spurious response 0x80000065:0x5, last cmd=0x505f2f57 To avoid this, the unsol event flow should not perform any codec verb related operations during RPM_SUSPENDING state. Signed-off-by:
Mohan Kumar <mkumard@nvidia.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220329155940.26331-1-mkumard@nvidia.comSigned-off-by:
-
Kai-Heng Feng authored
Commit 5aec9891 ("ALSA: hda/realtek - ALC236 headset MIC recording issue") is to solve recording issue met on AL236, by matching codec variant ALC269_TYPE_ALC257 and ALC269_TYPE_ALC256. This match can be too broad and Mi Notebook Pro 2020 is broken by the patch. Instead, use codec ID to be narrow down the scope, in order to make ALC256 unaffected. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215484 Fixes: 5aec9891 ("ALSA: hda/realtek - ALC236 headset MIC recording issue") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20220330061335.1015533-1-kai.heng.feng@canonical.comSigned-off-by:
-
- 28 Mar, 2022 6 commits
-
-
Vitaly Rodionov authored
Add 5 new Dolphin Systems, same configuration as older systems. Signed-off-by:
Vitaly Rodionov <vitalyr@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220328115614.15761-7-vitalyr@opensource.cirrus.comSigned-off-by:
-
Stefan Binding authored
For ESD reasons, all variants should now set HSBIAS_SENSE_EN. Signed-off-by:
Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by:
-
Stefan Binding authored
Added 15 new laptops, with 2 variants: Warlock MLK and Warlock MLK with Dual Mic The only difference between the variants, is the the dual Mic variants use a stereo DMIC. These variants do no use reduce volume (Full Scale Volume) Signed-off-by:
-
Stefan Binding authored
All current variants (Bullseye/Warlock/Cyborg) should be using reduced volume (-6dB) for better speaker protection. Refactor to make more explicit the meaning and setting of Full Scale Volume setting to avoid future confusion. Signed-off-by:
-
Stefan Binding authored
To ensure consistency, the quirk table should be re-ordered in ascending order [ a typo fix in the patch description by tiwai ] Signed-off-by:
-
Stefan Binding authored
Warlock/Bullseye Laptops have a mono DMIC, Cyborg uses a stereo DMIC, and the configuration should reflect this. Signed-off-by:
-
- 27 Mar, 2022 2 commits
-
-
Xiaomeng Tong authored
The bug is here: err = snd_card_cs423x_pnp(dev, card->private_data, pdev, cdev); The list iterator value 'cdev' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'cdev' as a dedicated pointer to point to the found element. And snd_card_cs423x_pnp() itself has NULL check for cdev. Cc: stable@vger.kernel.org Fixes: c2b73d14 ("ALSA: cs4236: cs4232 and cs4236 driver merge to solve PnP BIOS detection") Signed-off-by:
Xiaomeng Tong <xiam0nd.tong@gmail.com> Link: https://lore.kernel.org/r/20220327060822.4735-1-xiam0nd.tong@gmail.comSigned-off-by:
-
Kai-Heng Feng authored
Lenovo P360 is another platform equipped with ALC897, and it needs ALC897_FIXUP_HEADSET_MIC_PIN quirk to make its headset mic work. Signed-off-by:
-
- 25 Mar, 2022 1 commit
-
-
Zheng Bin authored
If SND_SOC_SOF_PCI_DEV is n, bulding fails: sound/soc/sof/intel/pci-tng.o:(.data+0x1c0): undefined reference to `sof_pci_probe' sound/soc/sof/intel/pci-tng.o:(.data+0x1c8): undefined reference to `sof_pci_remove' sound/soc/sof/intel/pci-tng.o:(.data+0x1e0): undefined reference to `sof_pci_shutdown' sound/soc/sof/intel/pci-tng.o:(.data+0x290): undefined reference to `sof_pci_pm' Make SND_SOC_SOF_MERRIFIELD select SND_SOC_SOF_PCI_DEV to fix this. Fixes: 8d4ba1be ("ASoC: SOF: pci: split PCI into different drivers") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zheng Bin <zhengbin13@huawei.com> Acked-by:
Mark Brown <broonie@kernel.org>
-
- 24 Mar, 2022 1 commit
-
-
Kai-Heng Feng authored
Zbook Fury 17 G9 requires the same ALC285_FIXUP_HP_GPIO_LED quirk to make its audio LEDs work. So apply the quirk, and make it the last one since it's an LED quirk. Fixes: 07bcab93 ("ALSA: hda/realtek: Add support for HP Laptops") Signed-off-by:
-
- 23 Mar, 2022 1 commit
-
-
Meng Tang authored
SND_SOC_DAIFMT_DSP_A: PCM delay 1 bit mode, L data MSB after FRM LRC SND_SOC_DAIFMT_DSP_B: PCM no delay mode, L data MSB during FRM LRC Fixes: 081068fd (ASoC: rockchip: add support for i2s-tdm controller) Signed-off-by:
Meng Tang <tangmeng@uniontech.com> Link: https://lore.kernel.org/r/20220318100146.23991-1-tangmeng@uniontech.comSigned-off-by:
-
- 22 Mar, 2022 7 commits
-
-
Matt Kramer authored
This fixes the near-silence of the headphone jack on the ALC256-based Samsung Galaxy Book Flex Alpha (NP730QCJ). The magic verbs were found through trial and error, using known ALC298 hacks as inspiration. The fixup is auto-enabled only when the NP730QCJ is detected. It can be manually enabled using model=alc256-samsung-headphone. Signed-off-by:
Matt Kramer <mccleetus@gmail.com> Link: https://lore.kernel.org/r/3168355.aeNJFYEL58@linusSigned-off-by:
-
Giacomo Guiduzzi authored
Tests 72 and 78 for ALSA in kselftest fail due to reading inconsistent values from some devices on a VirtualBox Virtual Machine using the snd_intel8x0 driver for the AC'97 Audio Controller device. Taking for example test number 72, this is what the test reports: "Surround Playback Volume.0 expected 1 but read 0, is_volatile 0" "Surround Playback Volume.1 expected 0 but read 1, is_volatile 0" These errors repeat for each value from 0 to 31. Taking a look at these error messages it is possible to notice that the written values are read back swapped. When the write is performed, these values are initially stored in an array used to sanity-check them and write them in the pcmreg array. To write them, the two one-byte values are packed together in a two-byte variable through bitwise operations: the first value is shifted left by one byte and the second value is stored in the right byte through a bitwise OR. When reading the values back, right shifts are performed to retrieve the previously stored bytes. These shifts are executed in the wrong order, thus reporting the values swapped as shown above. This patch fixes this mistake by reversing the read operations' order. Signed-off-by:
Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com> Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220322200653.15862-1-guiduzzi.giacomo@gmail.comSigned-off-by:
-
Takashi Iwai authored
snd_pcm_reset() is a non-atomic operation, and it's allowed to run during the PCM stream running. It implies that the manipulation of hw_ptr and other parameters might be racy. This patch adds the PCM stream lock at appropriate places in snd_pcm_*_reset() actions for covering that. Cc: <stable@vger.kernel.org> Reviewed-by:
-
Takashi Iwai authored
We have no protection against concurrent PCM buffer preallocation changes via proc files, and it may potentially lead to UAF or some weird problem. This patch applies the PCM open_mutex to the proc write operation for avoiding the racy proc writes and the PCM stream open (and further operations). Cc: <stable@vger.kernel.org> Reviewed-by:
-
Takashi Iwai authored
Like the previous fixes to hw_params and hw_free ioctl races, we need to paper over the concurrent prepare ioctl calls against hw_params and hw_free, too. This patch implements the locking with the existing runtime->buffer_mutex for prepare ioctls. Unlike the previous case for snd_pcm_hw_hw_params() and snd_pcm_hw_free(), snd_pcm_prepare() is performed to the linked streams, hence the lock can't be applied simply on the top. For tracking the lock in each linked substream, we modify snd_pcm_action_group() slightly and apply the buffer_mutex for the case stream_lock=false (formerly there was no lock applied) there. Cc: <stable@vger.kernel.org> Reviewed-by:
-
Takashi Iwai authored
In the current PCM design, the read/write syscalls (as well as the equivalent ioctls) are allowed before the PCM stream is running, that is, at PCM PREPARED state. Meanwhile, we also allow to re-issue hw_params and hw_free ioctl calls at the PREPARED state that may change or free the buffers, too. The problem is that there is no protection against those mix-ups. This patch applies the previously introduced runtime->buffer_mutex to the read/write operations so that the concurrent hw_params or hw_free call can no longer interfere during the operation. The mutex is unlocked before scheduling, so we don't take it too long. Cc: <stable@vger.kernel.org> Reviewed-by:
-
Takashi Iwai authored
Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity. Reported-by:
Hu Jiahui <kirin.say@gmail.com> Cc: <stable@vger.kernel.org> Reviewed-by:
-
- 21 Mar, 2022 4 commits
-
-
Takashi Iwai authored
Merge tag 'asoc-v5.18' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v5.18 Quite a quiet release for ASoC, lots of work on drivers and platforms but nothing too groundbreaking but not much on the core itself: - Start of moving SoF to support multiple IPC mechanisms. - Use of NHLT ACPI table to reduce the amount of quirking required for Intel systems. - Some building blocks for use in forthcoming Intel AVS driver for legacy Intel DSP firmwares. - Support for AMD PDM, Atmel PDMC, Awinic AW8738, i.MX cards with TLV320AIC31xx, Intel machines with CS35L41 and ESSX8336, Mediatek MT8181 wideband bluetooth, nVidia Tegra234, Qualcomm SC7280, Renesas RZ/V2L, Texas Instruments TAS585M
-
Takashi Iwai authored
Pull 5.18 development branch Signed-off-by: -
Meng Tang authored
Today, hp_jack_event and mic_jack_event always return 0. However, snd_soc_dapm_disable_pin and snd_soc_dapm_enable_pin may return a non-zero value, this will cause the user who calling hp_jack_event and mic_jack_event don't know whether the operation was really successfully. Signed-off-by:
Shengjiu Wang <shengjiu.wang@gmail.com> Reviewed-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/20220321065754.18307-1-tangmeng@uniontech.comSigned-off-by:
-
Jiaxin Yu authored
Fixes the following build errors when mt6358 is configured as module: >> ERROR: modpost: "mt6358_set_mtkaif_protocol" >> [sound/soc/mediatek/mt8186/mt8186-mt6366-rt1019-rt5682s.ko] undefined! >> ERROR: modpost: "mt6358_set_mtkaif_protocol" >> [sound/soc/mediatek/mt8186/mt8186-mt6366-da7219-max98357.ko] undefined! Fixes: 6a8d4198 ("ASoC: mediatek: mt6358: add codec driver") Signed-off-by:
Jiaxin Yu <jiaxin.yu@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220319120325.11882-1-jiaxin.yu@mediatek.comSigned-off-by:
-
