March 2022 - Alsa-devel - mailman.alsa-project.org

[PATCH] mediatek: mt8195: fix a missing check on list iterator
by Xiaomeng Tong 29 Mar '22

29 Mar '22

The bug is here: mt8195_etdm_hw_params_fixup(runtime, params); For the for_each_card_rtds(), just like list_for_each_entry(), the list iterator 'runtime' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to a invalid memory access. To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'runtime' as a dedicated pointer to point to the found element. Cc: stable(a)vger.kernel.org Fixes: 3d00d2c07f04f ("ASoC: mediatek: mt8195: add sof support on mt8195-mt6359-rt1019-rt5682") Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com> --- .../mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c b/sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c index 29c2d3407cc7..dc91877e4c3c 100644 --- a/sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c +++ b/sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c @@ -814,7 +814,7 @@ static int mt8195_dai_link_fixup(struct snd_soc_pcm_runtime *rtd, { struct snd_soc_card *card = rtd->card; struct snd_soc_dai_link *sof_dai_link = NULL; - struct snd_soc_pcm_runtime *runtime; + struct snd_soc_pcm_runtime *runtime = NULL, *iter; struct snd_soc_dai *cpu_dai; int i, j, ret = 0; @@ -824,16 +824,17 @@ static int mt8195_dai_link_fixup(struct snd_soc_pcm_runtime *rtd, if (strcmp(rtd->dai_link->name, conn->normal_link)) continue; - for_each_card_rtds(card, runtime) { - if (strcmp(runtime->dai_link->name, conn->sof_link)) + for_each_card_rtds(card, iter) { + if (strcmp(iter->dai_link->name, conn->sof_link)) continue; - for_each_rtd_cpu_dais(runtime, j, cpu_dai) { + for_each_rtd_cpu_dais(iter, j, cpu_dai) { if (cpu_dai->stream_active[conn->stream_dir] > 0) { - sof_dai_link = runtime->dai_link; + sof_dai_link = iter->dai_link; break; } } + runtime = iter; break; } @@ -845,7 +846,8 @@ static int mt8195_dai_link_fixup(struct snd_soc_pcm_runtime *rtd, if (!strcmp(rtd->dai_link->name, "ETDM2_IN_BE") || !strcmp(rtd->dai_link->name, "ETDM1_OUT_BE")) { - mt8195_etdm_hw_params_fixup(runtime, params); + if (runtime) + mt8195_etdm_hw_params_fixup(runtime, params); } return ret; -- 2.17.1

2 1

[PATCH] soc: soc-dapm: fix two incorrect uses of list iterator
by Xiaomeng Tong 29 Mar '22

29 Mar '22

These two bug are here: list_for_each_entry_safe_continue(w, n, list, power_list); list_for_each_entry_safe_continue(w, n, list, power_list); After the list_for_each_entry_safe_continue() exits, the list iterator will always be a bogus pointer which point to an invalid struct objdect containing HEAD member. The funciton poniter 'w->event' will be a invalid value which can lead to a control-flow hijack if the 'w' can be controlled. The original intention was to break the outer list_for_each_entry_safe() loop if w->event is NULL, but forgot to *break* switch statement first. So just add a break to fix the bug. Cc: stable(a)vger.kernel.org Fixes: 163cac061c973 ("ASoC: Factor out DAPM sequence execution") Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com> --- sound/soc/soc-dapm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index b06c5682445c..2a5a64d21856 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -1686,9 +1686,11 @@ static void dapm_seq_run(struct snd_soc_card *card, switch (w->id) { case snd_soc_dapm_pre: - if (!w->event) + if (!w->event) { list_for_each_entry_safe_continue(w, n, list, power_list); + break; + } if (event == SND_SOC_DAPM_STREAM_START) ret = w->event(w, @@ -1699,9 +1701,11 @@ static void dapm_seq_run(struct snd_soc_card *card, break; case snd_soc_dapm_post: - if (!w->event) + if (!w->event) { list_for_each_entry_safe_continue(w, n, list, power_list); + break; + } if (event == SND_SOC_DAPM_STREAM_START) ret = w->event(w, -- 2.17.1

2 2

[PATCH 00/14] ASoC: Intel: avs: Topology and path management
by Cezary Rojewski 28 Mar '22

28 Mar '22

A continuation of avs-driver initial series [1]. This chapter covers path management and topology parsing part which was ealier path of the main series. The two patches that represented these two subjects in the initial series, have been split into many to allow for easier review and discussion. AVS topology is split into two major parts: dictionaries - found within ASoC topology manifest - and path templates. Dictionaries job is to reduce the total amount of memory occupied by topology elements. Rather than having every pipeline and module carry its own information, each refers to specific entry in specific dictionary by provided (from topology file) indexes. In consequence, most struct avs_tplg_xxx are made out of pointers. Path templates are similar to path descriptions found in skylake-driver and they describe how given path shall look like in runtime - number of modules and pipelines that shape it and how they are laid out. A single path template is tied either to FE or BE and thus at most to a single, user-visible endpoint when speaking of FE. Path is a software representation of its ADSP firmware equivalent. It's a logical container for pipelines which are themselves containers - this time for modules i.e. processing units. Depending on the number of audio formats supported, each path template may carry one or more descriptions of given path. During runtime, when audio format is known, description matching said format is selected and used when instantiating path on ADSP firmware side through IPCs. Changes RFC -> v1: - Plenty of rewordings and spelling fixes as requested by Pierre - any sysfs-functionality-related left in RFC dropped, will be part of separate subject in the future - separated parsing of formatted strings into: "Support link_mask formatted string" patch, increasing series size to 14 patches [1]: https://lore.kernel.org/alsa-devel/20220207122108.3780926-1-cezary.rojewski… Cezary Rojewski (14): ASoC: Intel: avs: Declare vendor tokens ASoC: Intel: avs: Add topology parsing infrastructure ASoC: Intel: avs: Parse module-extension tuples ASoC: Intel: avs: Parse pplcfg and binding tuples ASoC: Intel: avs: Parse pipeline and module tuples ASoC: Intel: avs: Parse path and path templates tuples ASoC: Intel: avs: Add topology loading operations ASoC: Intel: avs: Support link_mask formatted string ASoC: Intel: avs: Declare path and its components ASoC: Intel: avs: Path creation and freeing ASoC: Intel: avs: Path state management ASoC: Intel: avs: Arm paths after creating them ASoC: Intel: avs: Prepare modules before bindings them ASoC: Intel: avs: Configure modules according to their type include/uapi/sound/intel/avs/tokens.h | 126 ++ sound/soc/intel/Kconfig | 2 + sound/soc/intel/avs/Makefile | 3 +- sound/soc/intel/avs/avs.h | 23 + sound/soc/intel/avs/path.c | 1008 ++++++++++++++++ sound/soc/intel/avs/path.h | 72 ++ sound/soc/intel/avs/topology.c | 1600 +++++++++++++++++++++++++ sound/soc/intel/avs/topology.h | 194 +++ 8 files changed, 3027 insertions(+), 1 deletion(-) create mode 100644 include/uapi/sound/intel/avs/tokens.h create mode 100644 sound/soc/intel/avs/path.c create mode 100644 sound/soc/intel/avs/path.h create mode 100644 sound/soc/intel/avs/topology.c create mode 100644 sound/soc/intel/avs/topology.h -- 2.25.1

2 15

[PATCH] ALSA: hda: Avoid unsol event during RPM suspending
by Mohan Kumar 28 Mar '22

28 Mar '22

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(a)nvidia.com> --- sound/pci/hda/patch_hdmi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index c85ed7bc121e..67870c8d84a5 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1625,6 +1625,7 @@ static void hdmi_present_sense_via_verbs(struct hdmi_spec_per_pin *per_pin, struct hda_codec *codec = per_pin->codec; struct hdmi_spec *spec = codec->spec; struct hdmi_eld *eld = &spec->temp_eld; + struct device *dev = hda_codec_dev(codec); hda_nid_t pin_nid = per_pin->pin_nid; int dev_id = per_pin->dev_id; /* @@ -1639,7 +1640,8 @@ static void hdmi_present_sense_via_verbs(struct hdmi_spec_per_pin *per_pin, int ret; ret = snd_hda_power_up_pm(codec); - if (ret < 0 && pm_runtime_suspended(hda_codec_dev(codec))) + if ((ret < 0 && pm_runtime_suspended(dev)) || + (dev->power.runtime_status == RPM_SUSPENDING)) goto out; present = snd_hda_jack_pin_sense(codec, pin_nid, dev_id); -- 2.17.1

4 8

[PATCH 0/6] Add new HW variants and fix few minor issues
by Vitaly Rodionov 28 Mar '22

28 Mar '22

This series adds new HW variants for Dell's Dolphin and Warlock, and also fixies few very minor issues. Stefan Binding (5): ALSA: hda/cs8409: Fix Warlock to use mono mic configuration ALSA: hda/cs8409: Re-order quirk table into ascending order ALSA: hda/cs8409: Fix Full Scale Volume setting for all variants ALSA: hda/cs8409: Support new Warlock MLK Variants ALSA: hda/cs8409: Disable HSBIAS_SENSE_EN for Cyborg Vitaly Rodionov (1): ALSA: hda/cs8409: Add new Dolphin HW variants sound/pci/hda/patch_cs8409-tables.c | 68 +++++++++++++++++++++-------- sound/pci/hda/patch_cs8409.c | 47 +++++++++++--------- sound/pci/hda/patch_cs8409.h | 5 +++ 3 files changed, 83 insertions(+), 37 deletions(-) -- 2.25.1

2 7

[V3 1/2] ASoC: max98390: Add reset gpio control
by Steve Lee 28 Mar '22

28 Mar '22

Add reset gpio control to support RESET PIN connected to gpio. Signed-off-by: Steve Lee <steve.lee.analog(a)gmail.com> --- sound/soc/codecs/max98390.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/soc/codecs/max98390.c b/sound/soc/codecs/max98390.c index 40fd6f363f35..05df9b85d9b0 100644 --- a/sound/soc/codecs/max98390.c +++ b/sound/soc/codecs/max98390.c @@ -1022,6 +1022,7 @@ static int max98390_i2c_probe(struct i2c_client *i2c, struct max98390_priv *max98390 = NULL; struct i2c_adapter *adapter = i2c->adapter; + struct gpio_desc *reset_gpio; ret = i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE @@ -1073,6 +1074,17 @@ static int max98390_i2c_probe(struct i2c_client *i2c, return ret; } + reset_gpio = devm_gpiod_get_optional(&i2c->dev, + "reset", GPIOD_OUT_LOW); + + /* Power on device */ + if (reset_gpio) { + usleep_range(1000, 2000); + /* bring out of reset */ + gpiod_set_value_cansleep(reset_gpio, 1); + usleep_range(1000, 2000); + } + /* Check Revision ID */ ret = regmap_read(max98390->regmap, MAX98390_R24FF_REV_ID, &reg); -- 2.17.1

3 5

Bug 215711 - snd_hda_intel not binding to codec
by Thorsten Leemhuis 28 Mar '22

28 Mar '22

Hi, this is your Linux kernel regression tracker. I noticed a regression report in bugzilla.kernel.org that afaics nobody acted upon since it was reported about a week ago, that's why I decided to forward it to the lists and the maintainers. To quote from https://bugzilla.kernel.org/show_bug.cgi?id=215711: > Created attachment 300588 [details] > SND_HDA_* excrept from kernel config > > On PCI device discovery the Intel HDA codec doesn't bind to appropriate codec (if that is the correct term). The device codec (Conexant) is loaded, but sound doesn't work. Reloading the main module (snd_hda_intel) fixes the issue: > > $ echo 1 > /sys/bus/pci/devices/0000:00:1b.0/remove > > $ lsmod | sort > Module Size Used by > configs 45056 0 > e1000e 225280 0 > grace 16384 1 lockd > irqbypass 16384 1 kvm > iwlwifi 274432 0 > kvm 569344 1 kvm_intel > kvm_intel 229376 0 > lockd 98304 1 nfs > mei 90112 1 mei_me > mei_me 28672 0 > nfs 184320 3 nfsv4 > nfsv4 380928 2 > sunrpc 274432 9 nfsv4,lockd,nfs > uvcvideo 110592 0 > videobuf2_common 45056 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops > videobuf2_memops 16384 1 videobuf2_vmalloc > videobuf2_v4l2 24576 1 uvcvideo > videobuf2_vmalloc 16384 1 uvcvideo > > $ echo 1 > /sys/bus/pci/rescan > # dmesg output > [ 9218.563134] pci 0000:00:1b.0: [8086:3b56] type 00 class 0x040300 > [ 9218.563178] pci 0000:00:1b.0: reg 0x10: [mem 0xc0004000-0xc0007fff 64bit] > [ 9218.563344] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold > [ 9218.563818] pci 0000:00:1b.0: BAR 0: assigned [mem 0xc0004000-0xc0007fff 64bit] > [ 9218.563846] pci 0000:00:1e.0: PCI bridge to [bus 0e] > [ 9218.598927] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops 0xffffffff824a44e0) > [ 9218.609798] snd_hda_intel 0000:00:1b.0: Cannot probe codecs, giving up > > $ lsmod | sort > Module Size Used by > configs 45056 0 > e1000e 225280 0 > grace 16384 1 lockd > irqbypass 16384 1 kvm > iwlwifi 274432 0 > kvm 569344 1 kvm_intel > kvm_intel 229376 0 > lockd 98304 1 nfs > mei 90112 1 mei_me > mei_me 28672 0 > nfs 184320 3 nfsv4 > nfsv4 380928 2 > snd 77824 7 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm > snd_hda_codec 118784 3 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_intel > snd_hda_codec_conexant 20480 0 > snd_hda_codec_generic 77824 1 snd_hda_codec_conexant > snd_hda_core 65536 4 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec > snd_hda_intel 36864 0 > snd_hwdep 16384 1 snd_hda_codec > snd_intel_dspcfg 16384 1 snd_hda_intel > snd_pcm 110592 3 snd_hda_intel,snd_hda_codec,snd_hda_core > snd_timer 32768 1 snd_pcm > soundcore 16384 1 snd > sunrpc 274432 9 nfsv4,lockd,nfs > uvcvideo 110592 0 > videobuf2_common 45056 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops > videobuf2_memops 16384 1 videobuf2_vmalloc > videobuf2_v4l2 24576 1 uvcvideo > videobuf2_vmalloc 16384 1 uvcvideo > > $ modprobe -rv snd_hda_intel; modprobe -v snd_hda_intel > # dmesg output > [ 9230.886362] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops 0xffffffff824a44e0) > [ 9230.895721] snd_hda_codec_conexant hdaudioC0D0: CX20585: BIOS auto-probing. > [ 9230.896677] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20585: line_outs=1 (0x1f/0x0/0x0/0x0/0x0) type:speaker > [ 9230.896691] snd_hda_codec_conexant hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) > [ 9230.896700] snd_hda_codec_conexant hdaudioC0D0: hp_outs=2 (0x1c/0x19/0x0/0x0/0x0) > [ 9230.896707] snd_hda_codec_conexant hdaudioC0D0: mono: mono_out=0x0 > [ 9230.896713] snd_hda_codec_conexant hdaudioC0D0: inputs: > [ 9230.896718] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x23 > [ 9230.896724] snd_hda_codec_conexant hdaudioC0D0: Mic=0x1b > [ 9230.896729] snd_hda_codec_conexant hdaudioC0D0: Dock Mic=0x1a > [ 9230.908437] snd_hda_codec_generic hdaudioC0D3: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line > [ 9230.908454] snd_hda_codec_generic hdaudioC0D3: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) > [ 9230.908461] snd_hda_codec_generic hdaudioC0D3: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) > [ 9230.908468] snd_hda_codec_generic hdaudioC0D3: mono: mono_out=0x0 > [ 9230.908473] snd_hda_codec_generic hdaudioC0D3: dig-out=0x5/0x0 > [ 9230.908477] snd_hda_codec_generic hdaudioC0D3: inputs: > [ 9230.916063] input: HDA Intel MID Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input52 > [ 9230.916216] input: HDA Intel MID Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input53 > [ 9230.916353] input: HDA Intel MID Dock Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input54 > [ 9230.919563] input: HDA Intel MID Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input55 > [ 9230.919727] input: HDA Intel MID HDMI as /devices/pci0000:00/0000:00:1b.0/sound/card0/input56 > > $ lsmod | sort > Module Size Used by > configs 45056 0 > e1000e 225280 0 > grace 16384 1 lockd > irqbypass 16384 1 kvm > iwlwifi 274432 0 > kvm 569344 1 kvm_intel > kvm_intel 229376 0 > lockd 98304 1 nfs > mei 90112 1 mei_me > mei_me 28672 0 > nfs 184320 3 nfsv4 > nfsv4 380928 2 > snd 77824 7 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm > snd_hda_codec 118784 3 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_intel > snd_hda_codec_conexant 20480 1 > snd_hda_codec_generic 77824 2 snd_hda_codec_conexant > snd_hda_core 65536 4 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec > snd_hda_intel 36864 0 > snd_hwdep 16384 1 snd_hda_codec > snd_intel_dspcfg 16384 1 snd_hda_intel > snd_pcm 110592 3 snd_hda_intel,snd_hda_codec,snd_hda_core > snd_timer 32768 1 snd_pcm > soundcore 16384 1 snd > sunrpc 274432 9 nfsv4,lockd,nfs > uvcvideo 110592 0 > videobuf2_common 45056 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops > videobuf2_memops 16384 1 videobuf2_vmalloc > videobuf2_v4l2 24576 1 uvcvideo > videobuf2_vmalloc 16384 1 uvcvideo > > > 5.15.29, have observed it already at least on 5.10.27, HW is ThinkPad x201 (x220 as well). I'm marking it as regression, since it used to work in the distant past (5.4-ish at least iirc) Could somebody take a look into this? Or was this discussed somewhere else already? Or even fixed? Anyway, to get this tracked: #regzbot introduced: v5.4..v5.10 #regzbot from: Petr Cerny <bugzilla(a)black-net.org> #regzbot title: snd: snd_hda_intel not binding to codec #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215711 Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. -- Additional information about regzbot: If you want to know more about regzbot, check out its web-interface, the getting start guide, and the references documentation: https://linux-regtracking.leemhuis.info/regzbot/ https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md The last two documents will explain how you can interact with regzbot yourself if your want to. Hint for reporters: when reporting a regression it's in your interest to CC the regression list and tell regzbot about the issue, as that ensures the regression makes it onto the radar of the Linux kernel's regression tracker -- that's in your interest, as it ensures your report won't fall through the cracks unnoticed. Hint for developers: you normally don't need to care about regzbot once it's involved. Fix the issue as you normally would, just remember to include 'Link:' tag in the patch descriptions pointing to all reports about the issue. This has been expected from developers even before regzbot showed up for reasons explained in 'Documentation/process/submitting-patches.rst' and 'Documentation/process/5.Posting.rst'.

1 0

[PATCH v2 1/2] ASoC: cs35l41: Add one more variable in the debug log
by Hui Wang 28 Mar '22

28 Mar '22

otp_map[].size is a key variable to compute the value of otp_val and to update the bit_offset, it is helpful to debug if could put it in the debug log. Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/soc/codecs/cs35l41-lib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cs35l41-lib.c b/sound/soc/codecs/cs35l41-lib.c index e5a56bcbb223..d0a480c40231 100644 --- a/sound/soc/codecs/cs35l41-lib.c +++ b/sound/soc/codecs/cs35l41-lib.c @@ -822,8 +822,8 @@ int cs35l41_otp_unpack(struct device *dev, struct regmap *regmap) word_offset = otp_map_match->word_offset; for (i = 0; i < otp_map_match->num_elements; i++) { - dev_dbg(dev, "bitoffset= %d, word_offset=%d, bit_sum mod 32=%d\n", - bit_offset, word_offset, bit_sum % 32); + dev_dbg(dev, "bitoffset= %d, word_offset=%d, bit_sum mod 32=%d otp_map[i].size = %d\n", + bit_offset, word_offset, bit_sum % 32, otp_map[i].size); if (bit_offset + otp_map[i].size - 1 >= 32) { otp_val = (otp_mem[word_offset] & GENMASK(31, bit_offset)) >> bit_offset; -- 2.25.1

3 5

[PATCH v1 0/3] Exynos Usb Audio Offloading Support
by Oh Eomji 28 Mar '22

28 Mar '22

Exynos uses the usb audio offloading functions to save power consumption in the usb audio device. The audio control interface is processed in the existing usb path, and the audio stream interface is processed in the audio path. Through communication between AP usb and audio usb f/w, usb audio device connection information, xhci memory information, etc. are notified to usb audio f/w so that the abox directly controls xhci transmission. Vendor's hooking interface is required for this functions. Throught this interface, information such as usb audio device connection information, pcm interface information, sample rate setting, xhci memory, full descriptor of connected device, and setting point can be transmitted to usb audio f/w. the usb audio f/w can set up and interface, transmit audio data, etc. through the received information. This patchset includes the following for using usb audio offloading: - vendor's hooking interface - vendor's hooking interface calling point - user using vendor's hooking interface Oh Eomji (3): sound: usb: Add vendor's hooking interface sound: usb: Calling vendor's call-back function within usb audio operation. sound: usb: Exynos usb audio offloading driver sound/usb/Kconfig | 9 + sound/usb/Makefile | 2 + sound/usb/card.c | 119 +++++++++ sound/usb/card.h | 20 ++ sound/usb/exynos_usb_audio.c | 560 +++++++++++++++++++++++++++++++++++++++++++ sound/usb/exynos_usb_audio.h | 150 ++++++++++++ sound/usb/pcm.c | 37 +++ sound/usb/stream.c | 2 + sound/usb/usbaudio.h | 45 ++++ 9 files changed, 944 insertions(+) create mode 100644 sound/usb/exynos_usb_audio.c create mode 100644 sound/usb/exynos_usb_audio.h -- 2.7.4

4 16

[PATCH] soc: soc-core: fix a missing check on list iterator
by Xiaomeng Tong 28 Mar '22

28 Mar '22

The bug is here: *dai_name = dai->driver->name; For for_each_component_dais, just like list_for_each_entry, the list iterator 'dai' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to a invalid memory access. To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'dai' as a dedicated pointer to point to the found element. Cc: stable(a)vger.kernel.org Fixes: 58bf4179000a3 ("ASoC: soc-core: remove dai_drv from snd_soc_component") Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com> --- sound/soc/soc-core.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 434e61b46983..064fc0347868 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -3238,7 +3238,7 @@ int snd_soc_get_dai_name(const struct of_phandle_args *args, ret = snd_soc_component_of_xlate_dai_name(pos, args, dai_name); if (ret == -ENOTSUPP) { - struct snd_soc_dai *dai; + struct snd_soc_dai *dai = NULL, *iter; int id = -1; switch (args->args_count) { @@ -3261,12 +3261,19 @@ int snd_soc_get_dai_name(const struct of_phandle_args *args, ret = 0; /* find target DAI */ - for_each_component_dais(pos, dai) { - if (id == 0) + for_each_component_dais(pos, iter) { + if (id == 0) { + dai = iter; break; + } id--; } + if (!dai) { + ret = -EINVAL; + continue; + } + *dai_name = dai->driver->name; if (!*dai_name) *dai_name = pos->name; -- 2.17.1

2 1