December 2023 - Alsa-devel - mailman.alsa-project.org

No sound from frontal case jack AUX [MSI MAG Z690 Tomahawk Wifi]
by GitHub issues - edited 07 Dec '23

07 Dec '23

alsa-project/alsa-ucm-conf issue #371 was edited from ricciolino: I posted [this](https://ubuntuforums.org/showthread.php?t=2486774) some weeks ago and I thought I had been able to solve the issue. Unfortunately, it does not seem like so. **Summary of the issue**: attaching my headphone to the rear jack, sound is emitted correctly, whilst frontal AUX jack it just looks dead (headphone device is correctly recognized in sound system settings but no sound is emitted). Summary of steps that brought me to the initial solution. Check the sound card USB device with: ``` > lsusb | grep -i audio Bus 001 Device 003: ID 0db0:b202 Micro Star International USB Audio ``` Execute the following commands in sequence: ``` sudo mv /usr/share/alsa/ucm /usr/share/alsa/ucm.bak sudo mv /usr/share/alsa/ucm2 /usr/share/alsa/ucm2.bak curl -L -o alsa-ucm-conf.tar.gz https://github.com/alsa-project/alsa-ucm-conf/archive/refs/heads/master.tar… sudo tar xvzf alsa-ucm-conf.tar.gz -C /usr/share/alsa --strip-components=1 --wildcards "*/ucm" "*/ucm2" rm alsa-ucm-conf.tar.gz ``` Reboot... than check: ``` > cat /usr/share/alsa/ucm2/USB-Audio/USB-Audio.conf | grep 0db0:b202 # 0db0:b202 MSI MAG Z690 Tomahawk Wifi ``` Attaching the headphone now sound is emitted correctly from frontal AUX jack. After a few weeks I returned to the initial situation, the front AUX jack does not emit any sound. I checked USB-Audio.conf file for being sure still MSI MAG Z690 Tomahawk Wifi MoBo is supported and output is confirmed. ``` > cat /usr/share/alsa/ucm2/USB-Audio/USB-Audio.conf | grep 0db0:b202 # 0db0:b202 MSI MAG Z690 Tomahawk Wifi ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/371 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

No sound from frontal case jack AUX [MSI MAG Z690 Tomahawk Wifi]
by GitHub issues - edited 07 Dec '23

07 Dec '23

alsa-project/alsa-ucm-conf issue #371 was edited from ricciolino: I posted [this](https://ubuntuforums.org/showthread.php?t=2486774) some weeks ago and I thought I had been able to solve the issue. Unfortunately, it does not seem like so. **Summary of the issue**: attaching my headphone to the rear jack, sound is emitted correctly, whilst frontal AUX jack it just looks dead (headphone device is correctly recognized in sound system settings but no sound is emitted). Summary of steps that brought me to the initial solution. Check the sound card USB device with: ``` > lsusb | grep -i audio Bus 001 Device 003: ID 0db0:b202 Micro Star International USB Audio ``` Execute the following commands in sequence: ``` sudo mv /usr/share/alsa/ucm /usr/share/alsa/ucm.bak sudo mv /usr/share/alsa/ucm2 /usr/share/alsa/ucm2.bak curl -L -o alsa-ucm-conf.tar.gz https://github.com/alsa-project/alsa-ucm-conf/archive/refs/heads/master.tar… sudo tar xvzf alsa-ucm-conf.tar.gz -C /usr/share/alsa --strip-components=1 --wildcards "*/ucm" "*/ucm2" rm alsa-ucm-conf.tar.gz ``` Reboot... than check: ``` > cat /usr/share/alsa/ucm2/USB-Audio/USB-Audio.conf | grep 0db0:b202 # 0db0:b202 MSI MAG Z690 Tomahawk Wifi ``` Attaching the headphone now sound is emitted correctly from frontal AUX jack. After a few weeks I returned to the initial situation, the front AUX jack does not emit any sound. After a few weeks I returned to the initial situation, the front AUX jack does not emit any sound. I checked USB-Audio.conf file for being sure still MSI MAG Z690 Tomahawk Wifi MoBo is supported and output is confirmed. ``` > cat /usr/share/alsa/ucm2/USB-Audio/USB-Audio.conf | grep 0db0:b202 # 0db0:b202 MSI MAG Z690 Tomahawk Wifi ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/371 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

No sound from frontal case jack AUX [MSI MAG Z690 Tomahawk Wifi]
by GitHub issues - opened 07 Dec '23

07 Dec '23

alsa-project/alsa-ucm-conf issue #371 was opened from ricciolino: I posted [this](https://ubuntuforums.org/showthread.php?t=2486774) some weeks ago and I thought I had been able to solve the issue. Unfortunately, it does not seem like so. Summary of the issue**: attaching my headphone to the rear jack, sound is emitted correctly, whilst frontal AUX jack it just looks dead (headphone device is correctly recognized in sound system settings but no sound is emitted). Summary of steps that brought me to the initial solution. Check the sound card USB device with: ``` > lsusb | grep -i audio Bus 001 Device 003: ID 0db0:b202 Micro Star International USB Audio ``` Execute the following commands in sequence: ``` sudo mv /usr/share/alsa/ucm /usr/share/alsa/ucm.bak sudo mv /usr/share/alsa/ucm2 /usr/share/alsa/ucm2.bak curl -L -o alsa-ucm-conf.tar.gz https://github.com/alsa-project/alsa-ucm-conf/archive/refs/heads/master.tar… sudo tar xvzf alsa-ucm-conf.tar.gz -C /usr/share/alsa --strip-components=1 --wildcards "*/ucm" "*/ucm2" rm alsa-ucm-conf.tar.gz ``` Reboot... than check: ``` > cat /usr/share/alsa/ucm2/USB-Audio/USB-Audio.conf | grep 0db0:b202 # 0db0:b202 MSI MAG Z690 Tomahawk Wifi ``` Attaching the headphone now sound is emitted correctly from frontal AUX jack. After a few weeks I returned to the initial situation, the front AUX jack does not emit any sound. After a few weeks I returned to the initial situation, the front AUX jack does not emit any sound. I checked USB-Audio.conf file for being sure still MSI MAG Z690 Tomahawk Wifi MoBo is supported and output is confirmed. ``` > cat /usr/share/alsa/ucm2/USB-Audio/USB-Audio.conf | grep 0db0:b202 # 0db0:b202 MSI MAG Z690 Tomahawk Wifi ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/371 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH 1/7] ASoC: amd: Add new dmi entries for acp5x platform
by Venkata Prasad Potturu 07 Dec '23

07 Dec '23

Add sys_vendor and product_name dmi entries for acp5x platform. Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu(a)amd.com> --- sound/soc/amd/acp-config.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/sound/soc/amd/acp-config.c b/sound/soc/amd/acp-config.c index 20cee7104c2b..19a30f145143 100644 --- a/sound/soc/amd/acp-config.c +++ b/sound/soc/amd/acp-config.c @@ -3,7 +3,7 @@ // This file is provided under a dual BSD/GPLv2 license. When using or // redistributing this file, you may do so under either license. // -// Copyright(c) 2021 Advanced Micro Devices, Inc. +// Copyright(c) 2021, 2023 Advanced Micro Devices, Inc. // // Authors: Ajit Kumar Pandey <AjitKumar.Pandey(a)amd.com> // @@ -47,6 +47,19 @@ static const struct config_entry config_table[] = { {} }, }, + { + .flags = FLAG_AMD_LEGACY, + .device = ACP_PCI_DEV_ID, + .dmi_table = (const struct dmi_system_id []) { + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Valve"), + DMI_MATCH(DMI_PRODUCT_NAME, "Jupiter"), + }, + }, + {} + }, + }, { .flags = FLAG_AMD_SOF, .device = ACP_PCI_DEV_ID, -- 2.25.1

2 8

[PATCH v2 00/35] bitops: add atomic find_bit() operations
by Yury Norov 07 Dec '23

07 Dec '23

Add helpers around test_and_{set,clear}_bit() that allow to search for clear or set bits and flip them atomically. The target patterns may look like this: for (idx = 0; idx < nbits; idx++) if (test_and_clear_bit(idx, bitmap)) do_something(idx); Or like this: do { bit = find_first_bit(bitmap, nbits); if (bit >= nbits) return nbits; } while (!test_and_clear_bit(bit, bitmap)); return bit; In both cases, the opencoded loop may be converted to a single function or iterator call. Correspondingly: for_each_test_and_clear_bit(idx, bitmap, nbits) do_something(idx); Or: return find_and_clear_bit(bitmap, nbits); Obviously, the less routine code people have to write themself, the less probability to make a mistake. Those are not only handy helpers but also resolve a non-trivial issue of using non-atomic find_bit() together with atomic test_and_{set,clear)_bit(). The trick is that find_bit() implies that the bitmap is a regular non-volatile piece of memory, and compiler is allowed to use such optimization techniques like re-fetching memory instead of caching it. For example, find_first_bit() is implemented like this: for (idx = 0; idx * BITS_PER_LONG < sz; idx++) { val = addr[idx]; if (val) { sz = min(idx * BITS_PER_LONG + __ffs(val), sz); break; } } On register-memory architectures, like x86, compiler may decide to access memory twice - first time to compare against 0, and second time to fetch its value to pass it to __ffs(). When running find_first_bit() on volatile memory, the memory may get changed in-between, and for instance, it may lead to passing 0 to __ffs(), which is undefined. This is a potentially dangerous call. find_and_clear_bit() as a wrapper around test_and_clear_bit() naturally treats underlying bitmap as a volatile memory and prevents compiler from such optimizations. Now that KCSAN is catching exactly this type of situations and warns on undercover memory modifications. We can use it to reveal improper usage of find_bit(), and convert it to atomic find_and_*_bit() as appropriate. The 1st patch of the series adds the following atomic primitives: find_and_set_bit(addr, nbits); find_and_set_next_bit(addr, nbits, start); ... Here find_and_{set,clear} part refers to the corresponding test_and_{set,clear}_bit function. Suffixes like _wrap or _lock derive their semantics from corresponding find() or test() functions. For brevity, the naming omits the fact that we search for zero bit in find_and_set, and correspondingly search for set bit in find_and_clear functions. The patch also adds iterators with atomic semantics, like for_each_test_and_set_bit(). Here, the naming rule is to simply prefix corresponding atomic operation with 'for_each'. This series is a result of discussion [1]. All find_bit() functions imply exclusive access to the bitmaps. However, KCSAN reports quite a number of warnings related to find_bit() API. Some of them are not pointing to real bugs because in many situations people intentionally allow concurrent bitmap operations. If so, find_bit() can be annotated such that KCSAN will ignore it: bit = data_race(find_first_bit(bitmap, nbits)); This series addresses the other important case where people really need atomic find ops. As the following patches show, the resulting code looks safer and more verbose comparing to opencoded loops followed by atomic bit flips. In [1] Mirsad reported 2% slowdown in a single-thread search test when switching find_bit() function to treat bitmaps as volatile arrays. On the other hand, kernel robot in the same thread reported +3.7% to the performance of will-it-scale.per_thread_ops test. Assuming that our compilers are sane and generate better code against properly annotated data, the above discrepancy doesn't look weird. When running on non-volatile bitmaps, plain find_bit() outperforms atomic find_and_bit(), and vice-versa. So, all users of find_bit() API, where heavy concurrency is expected, are encouraged to switch to atomic find_and_bit() as appropriate. The 1st patch of this series adds atomic find_and_bit() API, 2nd adds a basic test for new API, and all the following patches spread it over the kernel. They can be applied separately from each other on per-subsystems basis, or I can pull them in bitmap tree, as appropriate. [1] https://lore.kernel.org/lkml/634f5fdf-e236-42cf-be8d-48a581c21660@alu.unizg… --- v1: https://lore.kernel.org/netdev/20231118155105.25678-29-yury.norov@gmail.com… v2: - Add a basic test for the new API # Bart Van Assche; - Add collected reviewers' tags. Thank you guys! - Fix typos where found/pointed by; - Drop erroneous patch #v1-31 ("drivers/perf: optimize m1_pmu_get_event_idx()...") @ Marc Zyngier; - Drop unneeded patch #v1-12 ("wifi: intel: use atomic find_bit() API...") @ Johannes Berg; - Patch #v1-15: split SCSI changes per subsystems @ Bart Van Assche; - Patch #5: keep changes inside __mm_cid_try_get() @ Mathieu Desnoyers; - Patch #8: use find_and_set_next_bit() @ Will Deacon; - Patch #13: keep test against stimer->config.enable @ Vitaly Kuznetsov; - Patch #15: use find_and_set_next_bit @ Bart Van Assche; - Patch #31: edit commit message @ Tony Lu, Alexandra Winter; - Patch #35: edit tag @ John Paul Adrian Glaubitz; Yury Norov (35): lib/find: add atomic find_bit() primitives lib/find: add test for atomic find_bit() ops lib/sbitmap; make __sbitmap_get_word() using find_and_set_bit() watch_queue: use atomic find_bit() in post_one_notification() sched: add cpumask_find_and_set() and use it in __mm_cid_get() mips: sgi-ip30: rework heart_alloc_int() sparc: fix opencoded find_and_set_bit() in alloc_msi() perf/arm: optimize opencoded atomic find_bit() API drivers/perf: optimize ali_drw_get_counter_idx() by using find_bit() dmaengine: idxd: optimize perfmon_assign_event() ath10k: optimize ath10k_snoc_napi_poll() by using find_bit() wifi: rtw88: optimize rtw_pci_tx_kick_off() by using find_bit() KVM: x86: hyper-v: optimize and cleanup kvm_hv_process_stimers() PCI: hv: switch hv_get_dom_num() to use atomic find_bit() scsi: core: use atomic find_bit() API where appropriate scsi: mpi3mr: switch to using atomic find_and_set_bit() scsi: qedi: rework qedi_get_task_idx() powerpc: use atomic find_bit() API where appropriate iommu: use atomic find_bit() API where appropriate media: radio-shark: use atomic find_bit() API where appropriate sfc: switch to using atomic find_bit() API where appropriate tty: nozomi: optimize interrupt_handler() usb: cdc-acm: optimize acm_softint() block: null_blk: fix opencoded find_and_set_bit() in get_tag() RDMA/rtrs: fix opencoded find_and_set_bit_lock() in __rtrs_get_permit() mISDN: optimize get_free_devid() media: em28xx: cx231xx: fix opencoded find_and_set_bit() ethernet: rocker: optimize ofdpa_port_internal_vlan_id_get() serial: sc12is7xx: optimize sc16is7xx_alloc_line() bluetooth: optimize cmtp_alloc_block_id() net: smc: use find_and_set_bit() in smc_wr_tx_get_free_slot_index() ALSA: use atomic find_bit() functions where applicable m68k: rework get_mmu_context() microblaze: rework get_mmu_context() sh: mach-x3proto: rework ilsel_enable() arch/m68k/include/asm/mmu_context.h | 11 +- arch/microblaze/include/asm/mmu_context_mm.h | 11 +- arch/mips/sgi-ip30/ip30-irq.c | 12 +- arch/powerpc/mm/book3s32/mmu_context.c | 10 +- arch/powerpc/platforms/pasemi/dma_lib.c | 45 +-- arch/powerpc/platforms/powernv/pci-sriov.c | 12 +- arch/sh/boards/mach-x3proto/ilsel.c | 4 +- arch/sparc/kernel/pci_msi.c | 9 +- arch/x86/kvm/hyperv.c | 39 ++- drivers/block/null_blk/main.c | 41 +-- drivers/dma/idxd/perfmon.c | 8 +- drivers/infiniband/ulp/rtrs/rtrs-clt.c | 15 +- drivers/iommu/arm/arm-smmu/arm-smmu.h | 10 +- drivers/iommu/msm_iommu.c | 18 +- drivers/isdn/mISDN/core.c | 9 +- drivers/media/radio/radio-shark.c | 5 +- drivers/media/radio/radio-shark2.c | 5 +- drivers/media/usb/cx231xx/cx231xx-cards.c | 16 +- drivers/media/usb/em28xx/em28xx-cards.c | 37 +-- drivers/net/ethernet/rocker/rocker_ofdpa.c | 11 +- drivers/net/ethernet/sfc/rx_common.c | 4 +- drivers/net/ethernet/sfc/siena/rx_common.c | 4 +- drivers/net/ethernet/sfc/siena/siena_sriov.c | 14 +- drivers/net/wireless/ath/ath10k/snoc.c | 9 +- drivers/net/wireless/realtek/rtw88/pci.c | 5 +- drivers/net/wireless/realtek/rtw89/pci.c | 5 +- drivers/pci/controller/pci-hyperv.c | 7 +- drivers/perf/alibaba_uncore_drw_pmu.c | 10 +- drivers/perf/arm-cci.c | 24 +- drivers/perf/arm-ccn.c | 10 +- drivers/perf/arm_dmc620_pmu.c | 9 +- drivers/perf/arm_pmuv3.c | 8 +- drivers/scsi/mpi3mr/mpi3mr_os.c | 21 +- drivers/scsi/qedi/qedi_main.c | 9 +- drivers/scsi/scsi_lib.c | 7 +- drivers/tty/nozomi.c | 5 +- drivers/tty/serial/sc16is7xx.c | 8 +- drivers/usb/class/cdc-acm.c | 5 +- include/linux/cpumask.h | 12 + include/linux/find.h | 293 +++++++++++++++++++ kernel/sched/sched.h | 14 +- kernel/watch_queue.c | 6 +- lib/find_bit.c | 85 ++++++ lib/sbitmap.c | 46 +-- lib/test_bitmap.c | 61 ++++ net/bluetooth/cmtp/core.c | 10 +- net/smc/smc_wr.c | 10 +- sound/pci/hda/hda_codec.c | 7 +- sound/usb/caiaq/audio.c | 13 +- 49 files changed, 629 insertions(+), 420 deletions(-) -- 2.40.1

3 7

[PATCH] ALSA: hda/realtek: Add Framework laptop 16 to quirks
by Mario Limonciello 07 Dec '23

07 Dec '23

The Framework 16" laptop has the same controller as other Framework models. Apply the presence detection quirk. Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 59f2578839ed..50141795aed9 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10271,6 +10271,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10), SND_PCI_QUIRK(0x8086, 0x3038, "Intel NUC 13", ALC295_FIXUP_CHROME_BOOK), SND_PCI_QUIRK(0xf111, 0x0001, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0xf111, 0x0005, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE), SND_PCI_QUIRK(0xf111, 0x0006, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE), #if 0 -- 2.34.1

2 1

[PATCH 00/16] ALSA: hda/tas2781: Add tas2563 support
by Gergo Koteles 07 Dec '23

07 Dec '23

The tas2781-hda driver can be modified to support tas2563 as well. Before knowing this information, I created another series for a new driver. https://lore.kernel.org/lkml/cover.1701733441.git.soyer@irl.hu/ This series now extends tas2781-hda, addresses differences and fixes various bugs. The tas2563 is a smart amplifier. Similar to tas2562 but with DSP. Some Lenovo laptops have it to drive the bass speakers. By default, it is in software shutdown state. To make the DSP work it needs a firmware and some calibration data. The latter can be read from the EFI in Lenovo laptops. For the correct configuration it needs additional register data. It captured after running the Windows driver. The firmware can be extracted as TAS2563Firmware.bin from the Windows driver with innoextract. https://download.lenovo.com/consumer/mobiles/h5yd037fbfyy7kd0.exe The driver will search for it as TAS2XXX3870.bin with the 14ARB7. The captured registers extracted with TI's regtool: https://github.com/soyersoyer/tas2563rca/raw/main/INT8866RCA2.bin Gergo Koteles (16): ASoC: tas2781: add support for fw version 0x0503 ALSA: hda/tas2781: leave hda_component in usable state ASoC: tas2781: disable regmap regcache ALSA: hda/tas2781: handle missing calibration data ALSA: hda/tas2781: fix typos in comment ASoC: tas2781: add ptrs to calibration functions ALSA: hda/tas2781: load_calibration just load ASoC: tas2781: add configurable global_addr ALSA: hda/tas2781: add TAS2563 support for 14ARB7 ASoC: tas2781: check negative indexes ASoC: tas2781: use 0 as default prog/conf index ASoC: tas2781: move set_drv_data outside tasdevice_init ALSA: hda/tas2781: remove sound controls in unbind ALSA: hda/tas2781: call cleaner functions only once ALSA: hda/tas2781: reset the amp before component_add ALSA: hda/tas2781: configure the amp after firmware load include/sound/tas2781.h | 8 + sound/pci/hda/tas2781_hda_i2c.c | 364 +++++++++++++++++++----------- sound/soc/codecs/tas2781-comlib.c | 23 +- sound/soc/codecs/tas2781-fmwlib.c | 11 +- sound/soc/codecs/tas2781-i2c.c | 2 + 5 files changed, 270 insertions(+), 138 deletions(-) base-commit: ffc253263a1375a65fa6c9f62a893e9767fbebfa -- 2.43.0

1 0

alsactl: fix potential buffer overwrite
by GitHub pull_request - opened 06 Dec '23

06 Dec '23

alsa-project/alsa-utils pull request #247 was opened from szsam: The 'call to sprintf' operation on line 413 requires 21 bytes but the destination is only 16 bytes. Request URL : https://github.com/alsa-project/alsa-utils/pull/247 Patch URL : https://github.com/alsa-project/alsa-utils/pull/247.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

aplay: fix buffer overflow and tainted format string
by GitHub pull_request - opened 06 Dec '23

06 Dec '23

alsa-project/alsa-utils pull request #246 was opened from szsam: Prior this commit, memcpy from names[0] to format[] will overwrite if strlen(names[0]) is greater than 1024. Also, the length of malloc()ed names[channel] is insufficient, leading to another buffer overwriting when calling sprintf(). Moreover, the format string of sprintf() can be controlled by user input. An attacker can exploit this weakness to crash the program, disclose information or even execute arbitrary code. Fix by allocating enough space for arrays and using constant expressions as the format strings. Request URL : https://github.com/alsa-project/alsa-utils/pull/246 Patch URL : https://github.com/alsa-project/alsa-utils/pull/246.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH] ASoC: SOF: mediatek: mt8186: Revert Add Google Steelix topology compatible
by cujomalainey＠chromium.org 06 Dec '23

06 Dec '23

From: Curtis Malainey <cujomalainey(a)chromium.org> This reverts commit 505c83212da5bfca95109421b8f5d9f8c6cdfef2. This is not an official topology from the SOF project. Topologies are named based on the card configuration and are NOT board specific. Signed-off-by: Curtis Malainey <cujomalainey(a)chromium.org> --- sound/soc/sof/mediatek/mt8186/mt8186.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/soc/sof/mediatek/mt8186/mt8186.c b/sound/soc/sof/mediatek/mt8186/mt8186.c index 1d37c9767986f..0d2d7d697de02 100644 --- a/sound/soc/sof/mediatek/mt8186/mt8186.c +++ b/sound/soc/sof/mediatek/mt8186/mt8186.c @@ -548,9 +548,6 @@ static struct snd_sof_dsp_ops sof_mt8186_ops = { static struct snd_sof_of_mach sof_mt8186_machs[] = { { - .compatible = "google,steelix", - .sof_tplg_filename = "sof-mt8186-google-steelix.tplg" - }, { .compatible = "mediatek,mt8186", .sof_tplg_filename = "sof-mt8186.tplg", }, -- 2.43.0.rc2.451.g8631bc7472-goog

4 5