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

[PATCH] dt-bindings: mfd: Fix pinctrl node name warnings
by Rob Herring 04 Mar '22

04 Mar '22

The recent addition pinctrl.yaml in commit c09acbc499e8 ("dt-bindings: pinctrl: use pinctrl.yaml") resulted in some node name warnings: Documentation/devicetree/bindings/mfd/cirrus,lochnagar.example.dt.yaml: \ lochnagar-pinctrl: $nodename:0: 'lochnagar-pinctrl' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$' Documentation/devicetree/bindings/mfd/cirrus,madera.example.dt.yaml: \ codec@1a: $nodename:0: 'codec@1a' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$' Documentation/devicetree/bindings/mfd/brcm,cru.example.dt.yaml: \ pin-controller@1c0: $nodename:0: 'pin-controller@1c0' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$' Fix the node names to the preferred 'pinctrl'. For cirrus,madera, nothing from pinctrl.yaml schema is used, so just drop the reference. Fixes: c09acbc499e8 ("dt-bindings: pinctrl: use pinctrl.yaml") Cc: Rafał Miłecki <rafal(a)milecki.pl> Signed-off-by: Rob Herring <robh(a)kernel.org> --- Documentation/devicetree/bindings/mfd/brcm,cru.yaml | 4 ++-- Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml | 2 +- Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml | 3 --- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml index be4a2df71c25..b85819fbb07c 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml @@ -39,7 +39,7 @@ patternProperties: '^phy@[a-f0-9]+$': $ref: ../phy/bcm-ns-usb2-phy.yaml - '^pin-controller@[a-f0-9]+$': + '^pinctrl@[a-f0-9]+$': $ref: ../pinctrl/brcm,ns-pinmux.yaml '^syscon@[a-f0-9]+$': @@ -94,7 +94,7 @@ examples: reg = <0x180 0x4>; }; - pin-controller@1c0 { + pinctrl@1c0 { compatible = "brcm,bcm4708-pinmux"; reg = <0x1c0 0x24>; reg-names = "cru_gpio_control"; diff --git a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml index c00ad3e21c21..975a46f3c46f 100644 --- a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml +++ b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml @@ -126,7 +126,7 @@ properties: clock-frequency: const: 12288000 - lochnagar-pinctrl: + pinctrl: type: object $ref: /schemas/pinctrl/cirrus,lochnagar.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml index c85f759ae5a3..8a90d8273767 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml @@ -107,9 +107,6 @@ properties: additionalProperties: false -allOf: - - $ref: "pinctrl.yaml#" - required: - pinctrl-0 - pinctrl-names -- 2.32.0

2 2

[PATCH] ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction
by Takashi Sakamoto 04 Mar '22

04 Mar '22

AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA: firewire-lib: Add support for deferred transaction") while 'deferrable' flag can be uninitialized for non-control/notify AV/C transactions. UBSAN reports it: kernel: ================================================================================ kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9 kernel: load of value 158 is not a valid value for type '_Bool' kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019 kernel: Call Trace: kernel: <IRQ> kernel: show_stack+0x52/0x58 kernel: dump_stack_lvl+0x4a/0x5f kernel: dump_stack+0x10/0x12 kernel: ubsan_epilogue+0x9/0x45 kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49 kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib] kernel: fcp_response+0x28/0x30 [snd_firewire_lib] kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core] kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core] kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci] kernel: tasklet_action_common.constprop.0+0xea/0xf0 kernel: tasklet_action+0x22/0x30 kernel: __do_softirq+0xd9/0x2e3 kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0 kernel: do_softirq+0x75/0xa0 kernel: </IRQ> kernel: <TASK> kernel: __local_bh_enable_ip+0x50/0x60 kernel: irq_forced_thread_fn+0x7e/0x90 kernel: irq_thread+0xba/0x190 kernel: ? irq_thread_fn+0x60/0x60 kernel: kthread+0x11e/0x140 kernel: ? irq_thread_check_affinity+0xf0/0xf0 kernel: ? set_kthread_struct+0x50/0x50 kernel: ret_from_fork+0x22/0x30 kernel: </TASK> kernel: ================================================================================ This commit fixes the bug. The bug has no disadvantage for the non- control/notify AV/C transactions since the flag has an effect for AV/C response with INTERIM (0x0f) status which is not used for the transactions in AV/C general specification. Fixes: 00a7bb81c20f ("ALSA: firewire-lib: Add support for deferred transaction") Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/fcp.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/firewire/fcp.c b/sound/firewire/fcp.c index bbfbebf4affb..564607e083ca 100644 --- a/sound/firewire/fcp.c +++ b/sound/firewire/fcp.c @@ -240,9 +240,7 @@ int fcp_avc_transaction(struct fw_unit *unit, t.response_match_bytes = response_match_bytes; t.state = STATE_PENDING; init_waitqueue_head(&t.wait); - - if (*(const u8 *)command == 0x00 || *(const u8 *)command == 0x03) - t.deferrable = true; + t.deferrable = !!(*(const u8 *)command == 0x00 || *(const u8 *)command == 0x03); spin_lock_irq(&transactions_lock); list_add_tail(&t.list, &transactions); -- 2.34.1

2 1

[PATCH] ALSA: lola: add a check for the return of vmalloc()
by xkernel.wang＠foxmail.com 04 Mar '22

04 Mar '22

From: Xiaoke Wang <xkernel.wang(a)foxmail.com> vmalloc() is a memory allocation function which can return NULL when some internal memory errors happen. So it is better to check the return of it to catch the error in time. Signed-off-by: Xiaoke Wang <xkernel.wang(a)foxmail.com> --- sound/pci/lola/lola_mixer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/lola/lola_mixer.c b/sound/pci/lola/lola_mixer.c index e2c8f14..6b16248 100644 --- a/sound/pci/lola/lola_mixer.c +++ b/sound/pci/lola/lola_mixer.c @@ -121,6 +121,8 @@ int lola_init_mixer_widget(struct lola *chip, int nid) /* reserve memory to copy mixer data for sleep mode transitions */ chip->mixer.array_saved = vmalloc(sizeof(struct lola_mixer_array)); + if (!chip->mixer.array_saved) + return -ENOMEM; /* mixer matrix sources are physical input data and play streams */ chip->mixer.src_stream_outs = chip->pcm[PLAY].num_streams; --

2 1

[PATCH] ALSA: echoaudio: remove redundant assignment to variable bytes
by Colin Ian King 04 Mar '22

04 Mar '22

The variable bytes is being assigned a value that is never read, it is being re-assigned inside a following if block. The assignment is redundant and can be removed. Cleans up clang scan build warning: sound/pci/echoaudio/midi.c:211:9: warning: Although the value stored to 'bytes' is used in the enclosing expression, the value is never actually read from 'bytes' [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> --- sound/pci/echoaudio/midi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/echoaudio/midi.c b/sound/pci/echoaudio/midi.c index cb72d27e809e..7be5c3327b16 100644 --- a/sound/pci/echoaudio/midi.c +++ b/sound/pci/echoaudio/midi.c @@ -208,7 +208,7 @@ static void snd_echo_midi_output_write(struct timer_list *t) /* No interrupts are involved: we have to check at regular intervals if the card's output buffer has room for new data. */ - sent = bytes = 0; + sent = 0; spin_lock_irqsave(&chip->lock, flags); chip->midi_full = 0; if (!snd_rawmidi_transmit_empty(chip->midi_out)) { -- 2.34.1

2 1

Re: Issue in pcm_dsnoop.c in alsa-lib
by S.J. Wang 04 Mar '22

04 Mar '22

> > > > Hi Takashi Iwai, Jaroslav Kysela > > > > We encountered an issue in the pcm_dsnoop use case, could you > > please help to have a look? > > > > *Issue description:* > > With two instances for dsnoop type device running in parallel, > > after suspend/resume, one of the instances will be hung in memcpy > > because the very large copy size is obtained. > > > > #3 0x0000ffffa78d5098 in snd_pcm_dsnoop_sync_ptr > (pcm=0xaaab06563da0) > > at pcm_dsnoop.c:158 dsnoop = 0xaaab06563c20 slave_hw_ptr = 64 > > old_slave_hw_ptr = 533120 avail = *187651522444320* > > > > * Reason analysis: * > > The root cause that I analysis is that after suspend/resume, one > > instance will get the SND_PCM_STATE_SUSPENDED state from slave pcm > device, > > then it will do snd_pcm_prepare() and snd_pcm_start(), which will > > reset the dsnoop->slave_hw_ptr and the hw_ptr of slave pcm device, > > then the state of this instance is correct. But another instance may > > not get the SND_PCM_STATE_SUSPENDED state from slave pcm device > > because slave device may have been recovered by first instance, so > > the dsnoop->slave_hw_ptr is not reset. but because hw_ptr of slave > > pcm device has been reset, so there will be a very large "avail" size. > > > > *Solution:* > > I didn't come up with a fix for this issue, seems there is no easy > > way to let another instance know this case and reset the > > dsnoop->slave_hw_ptr, could you please help? > > Could you try topic/pcm-direct-resume branch on > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub > .com%2Ftiwai%2Falsa- > lib&data=04%7C01%7Cshengjiu.wang%40nxp.com%7C95f97de3f2c840d > 9853508d9fd2e79ea%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C > 637819198319430045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdat > a=WWX1ZlcQhJF3pHJdHPIH%2B0xG9o%2FjQnHG5fHDbKXwQwE%3D&r > eserved=0 > Thanks, I push my test result in https://github.com/alsa-project/alsa-lib/issues/213 Could you please review? Best regards Wang shengjiu

2 1

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
by Linus Torvalds 04 Mar '22

04 Mar '22

On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. Side note: we do need *some* way to do it. Because if we make that change, and only set it to another pointer when not the head, then we very much change the semantics of "list_for_each_head()". The "list was empty" case would now exit with 'pos' not set at all (or set to NULL if we add that). Or it would be set to the last entry. And regardless, that means that all the if (pos == head) kinds of checks after the loop would be fundamentally broken. Darn. I really hoped for (and naively expected) that we could actually have the compiler warn about the use-after-loop case. That whole "compiler will now complain about bad use" was integral to my clever plan to use the C99 feature of declaring the iterator inside the loop. But my "clever plan" was apparently some ACME-level Wile E. Coyote sh*t. Darn. Linus

11 34

[PATCH] ASoC: rt5665: Don't block workqueue if card is unbound
by Zhen Ni 04 Mar '22

04 Mar '22

The current rt5665_jack_detect_handler() assumes the component and card will always show up and implements an infinite usleep loop waiting for them to show up. This does not hold true if a codec interrupt (or other event) occurs when the card is unbound. The codec driver's remove or shutdown functions cannot cancel the workqueue due to the wait loop. As a result, code can either end up blocking the workqueue, or hit a kernel oops when the card is freed. Fix the issue by rescheduling the jack detect handler in case the card is not ready. In case card never shows up, the shutdown/remove/suspend calls can now cancel the detect task. Signed-off-by: Zhen Ni <nizhen(a)uniontech.com> --- sound/soc/codecs/rt5665.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/sound/soc/codecs/rt5665.c b/sound/soc/codecs/rt5665.c index 33e889802ff8..cdfd7085df2a 100644 --- a/sound/soc/codecs/rt5665.c +++ b/sound/soc/codecs/rt5665.c @@ -1293,19 +1293,13 @@ static void rt5665_jack_detect_handler(struct work_struct *work) container_of(work, struct rt5665_priv, jack_detect_work.work); int val, btn_type; - while (!rt5665->component) { - pr_debug("%s codec = null\n", __func__); - usleep_range(10000, 15000); - } - - while (!rt5665->component->card->instantiated) { - pr_debug("%s\n", __func__); - usleep_range(10000, 15000); - } - - while (!rt5665->calibration_done) { - pr_debug("%s calibration not ready\n", __func__); - usleep_range(10000, 15000); + if (!rt5665->component || !rt5665->component->card->instantiated || + !rt5665->calibration_done) { + pr_debug("%s card not yet ready\n", __func__); + /* try later */ + mod_delayed_work(system_power_efficient_wq, + &rt5665->jack_detect_work, msecs_to_jiffies(15)); + return; } mutex_lock(&rt5665->calibrate_mutex); -- 2.20.1

1 0

Re: Re: [PATCH] ASoC: wm8350: Handle error for wm8350_register_irq
by Jiasheng Jiang 04 Mar '22

04 Mar '22

On Thu, Mar 03, 2022 at 09:38:34PM +0800, Charles Keepax wrote: >> if (ret != 0) >> - return ret; >> + goto err; > > I would probably just leave this as a return, nothing is gained > changing it to a goto. > >> >> + ret = wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_JCK_DET_R, >> wm8350_hpr_jack_handler, 0, "Right jack detect", >> priv); >> - wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_MICSCD, >> + if (ret != 0) >> + goto free_JCK_DET_L; > > Probably better to use non-caps here, having caps in a label is a > little unusual. Thansk, I have submitted v2 to solve the problems. Jiang

1 0

Re: mmotm 2022-02-23-21-20 uploaded (Kconfig warning: SND_SOC_WCD938X)
by Randy Dunlap 03 Mar '22

03 Mar '22

On 2/23/22 21:21, Andrew Morton wrote: > The mm-of-the-moment snapshot 2022-02-23-21-20 has been uploaded to > > https://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > https://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. on x86_64: WARNING: unmet direct dependencies detected for SND_SOC_WCD938X Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=m] && SND_SOC_WCD938X_SDW [=n] && (SOUNDWIRE [=n] || !SOUNDWIRE [=n]) Selected by [m]: - SND_SOC_SC7280 [=m] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=m] && SND_SOC_QCOM [=m] && (I2C [=y] && SOUNDWIRE [=n] || COMPILE_TEST [=y]) Full randconfig file is attached. -- ~Randy

1 1

[PATCH] soundwire: qcom: fix build failures if CONFIG_PM=n
by Srinivas Kandagatla 03 Mar '22

03 Mar '22

Fix below build failure drivers/soundwire/qcom.c:1460:12: error: 'swrm_runtime_resume' defined but not used [-Werror=unused-function] by marking the resume swrm_runtime_resume() with __maybe_unused attribute. Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/soundwire/qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index e893aee1b057..6575695cd400 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1459,7 +1459,7 @@ static bool swrm_wait_for_frame_gen_enabled(struct qcom_swrm_ctrl *swrm) return false; } -static int swrm_runtime_resume(struct device *dev) +static int __maybe_unused swrm_runtime_resume(struct device *dev) { struct qcom_swrm_ctrl *ctrl = dev_get_drvdata(dev); int ret; -- 2.21.0

2 2