1. 13 Feb, 2024 2 commits
    • Peter Ujfalusi's avatar
      ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend · c40aad7c
      Peter Ujfalusi authored
      When the system is suspended while audio is active, the
      sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during
      suspend the DSP is turned off, streams will be re-started after resume.
      
      If the firmware crashes during while audio is running (or when we reset
      the stream before suspend) then the sof_ipc4_set_multi_pipeline_state()
      will fail with IPC error and the state change is interrupted.
      This will cause misalignment between the kernel and firmware state on next
      DSP boot resulting errors returned by firmware for IPC messages, eventually
      failing the audio resume.
      On stream close the errors are ignored so the kernel state will be
      corrected on the next DSP boot, so the second boot after the DSP panic.
      
      If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then
      state parameter is SOF_IPC4_PIPE_RESET and only in this case.
      
      Treat a forced pipeline reset similarly to how we treat a pcm_free by
      ignoring error on state sending to allow the kernel's state to be
      consistent with the state the firmware will have after the next boot.
      
      Link: https://github.com/thesofproject/sof/issues/8721Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@linux.intel.com>
      Reviewed-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Reviewed-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Reviewed-by: default avatarBard Liao <yung-chuan.liao@linux.intel.com>
      Link: https://msgid.link/r/20240213115233.15716-1-peter.ujfalusi@linux.intel.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c40aad7c
    • Arnd Bergmann's avatar
      ASoC: q6dsp: fix event handler prototype · 5b5089e2
      Arnd Bergmann authored
      clang-16 points out a mismatch in function types that was hidden
      by a typecast:
      
      sound/soc/qcom/qdsp6/q6apm-dai.c:355:38: error: cast from 'void (*)(uint32_t, uint32_t, uint32_t *, void *)' (aka 'void (*)(unsigned int, unsigned int, unsigned int *, void *)') to 'q6apm_cb' (aka 'void (*)(unsigned int, unsigned int, void *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
        355 |         prtd->graph = q6apm_graph_open(dev, (q6apm_cb)event_handler, prtd, graph_id);
      sound/soc/qcom/qdsp6/q6apm-dai.c:499:38: error: cast from 'void (*)(uint32_t, uint32_t, uint32_t *, void *)' (aka 'void (*)(unsigned int, unsigned int, unsigned int *, void *)') to 'q6apm_cb' (aka 'void (*)(unsigned int, unsigned int, void *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
        499 |         prtd->graph = q6apm_graph_open(dev, (q6apm_cb)event_handler_compr, prtd, graph_id);
      
      The only difference here is the 'payload' argument, which is not even
      used in this function, so just fix its type and remove the cast.
      
      Fixes: 88b60bf0 ("ASoC: q6dsp: q6apm-dai: Add open/free compress DAI callbacks")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://msgid.link/r/20240213101105.459402-1-arnd@kernel.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      5b5089e2
  2. 12 Feb, 2024 4 commits
  3. 11 Feb, 2024 4 commits
    • Cristian Ciocaltea's avatar
      ASoC: SOF: amd: Fix locking in ACP IRQ handler · c4b603c6
      Cristian Ciocaltea authored
      A recent change in acp_irq_thread() was meant to address a potential race
      condition while trying to acquire the hardware semaphore responsible for
      the synchronization between firmware and host IPC interrupts.
      
      This resulted in an improper use of the IPC spinlock, causing normal
      kernel memory allocations (which may sleep) inside atomic contexts:
      
      1707255557.133976 kernel: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:315
      
      ...
      
      1707255557.134757 kernel:  sof_ipc3_rx_msg+0x70/0x130 [snd_sof]
      1707255557.134793 kernel:  acp_sof_ipc_irq_thread+0x1e0/0x550 [snd_sof_amd_acp]
      1707255557.134855 kernel:  acp_irq_thread+0xa3/0x130 [snd_sof_amd_acp]
      1707255557.134904 kernel:  ? irq_thread+0xb5/0x1e0
      1707255557.134947 kernel:  ? __pfx_irq_thread_fn+0x10/0x10
      1707255557.134985 kernel:  irq_thread_fn+0x23/0x60
      
      Moreover, there are attempts to lock a mutex from the same atomic
      context:
      
      1707255557.136357 kernel: =============================
      1707255557.136393 kernel: [ BUG: Invalid wait context ]
      1707255557.136413 kernel: 6.8.0-rc3-next-20240206-audio-next #9 Tainted: G        W
      1707255557.136432 kernel: -----------------------------
      1707255557.136451 kernel: irq/66-AudioDSP/502 is trying to lock:
      1707255557.136470 kernel: ffff965152f26af8 (&sb->s_type->i_mutex_key#2){+.+.}-{3:3}, at: start_creating.part.0+0x5f/0x180
      
      ...
      
      1707255557.137429 kernel:  start_creating.part.0+0x5f/0x180
      1707255557.137457 kernel:  __debugfs_create_file+0x61/0x210
      1707255557.137475 kernel:  snd_sof_debugfs_io_item+0x75/0xc0 [snd_sof]
      1707255557.137494 kernel:  sof_ipc3_do_rx_work+0x7cf/0x9f0 [snd_sof]
      1707255557.137513 kernel:  sof_ipc3_rx_msg+0xb3/0x130 [snd_sof]
      1707255557.137532 kernel:  acp_sof_ipc_irq_thread+0x1e0/0x550 [snd_sof_amd_acp]
      1707255557.137551 kernel:  acp_irq_thread+0xa3/0x130 [snd_sof_amd_acp]
      
      Fix the issues by reducing the lock scope in acp_irq_thread(), so that
      it guards only the hardware semaphore acquiring attempt.  Additionally,
      restore the initial locking in acp_sof_ipc_irq_thread() to synchronize
      the handling of immediate replies from DSP core.
      
      Fixes: 802134c8 ("ASoC: SOF: amd: Refactor spinlock_irq(&sdev->ipc_lock) sequence in irq_handler")
      Signed-off-by: default avatarCristian Ciocaltea <cristian.ciocaltea@collabora.com>
      Link: https://lore.kernel.org/r/20240208234315.2182048-1-cristian.ciocaltea@collabora.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c4b603c6
    • Alexey Khoroshilov's avatar
      ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() · 6ef5d5b9
      Alexey Khoroshilov authored
      There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex
      is left locked forever. That may lead to deadlock
      when rt5645_jack_detect_work() is called for the second time.
      
      Found by Linux Verification Center (linuxtesting.org) with SVACE.
      
      Fixes: cdba4301 ("ASoC: rt5650: add mutex to avoid the jack detection failure")
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Link: https://lore.kernel.org/r/1707645514-21196-1-git-send-email-khoroshilov@ispras.ruSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      6ef5d5b9
    • Hans de Goede's avatar
      ASoC: Intel: cht_bsw_rt5645: Cleanup codec_name handling · 930375d3
      Hans de Goede authored
      4 fixes / cleanups to the rt5645 mc driver's codec_name handling:
      
      1. In the for loop looking for the dai_index for the codec, replace
      card->dai_link[i] with cht_dailink[i]. The for loop already uses
      ARRAY_SIZE(cht_dailink) as bound and card->dai_link is just a pointer to
      cht_dailink using card->dai_link only obfuscates that cht_dailink is being
      modified directly rather then say a copy of cht_dailink. Using
      cht_dailink[i] also makes the code consistent with other machine drivers.
      
      2. Don't set cht_dailink[dai_index].codecs->name in the for loop,
      this immediately gets overridden using acpi_dev_name(adev) directly
      below the loop.
      
      3. Add a missing break to the loop.
      
      4. Remove the now no longer used (only set, never read) codec_name field
      from struct cht_mc_private.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20240210134400.24913-3-hdegoede@redhat.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      930375d3
    • Hans de Goede's avatar
      ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards · 7d99a70b
      Hans de Goede authored
      Since commit 13f58267 ("ASoC: soc.h: don't create dummy Component
      via COMP_DUMMY()") dummy snd_soc_dai_link.codecs entries no longer
      have a name set.
      
      This means that when looking for the codec dai_link the machine
      driver can no longer unconditionally run strcmp() on
      snd_soc_dai_link.codecs[0].name since this may now be NULL.
      
      Add a check for snd_soc_dai_link.codecs[0].name being NULL to all
      BYT/CHT machine drivers to avoid NULL pointer dereferences in
      their probe() methods.
      
      Fixes: 13f58267 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()")
      Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20240210134400.24913-2-hdegoede@redhat.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      7d99a70b
  4. 09 Feb, 2024 1 commit
  5. 08 Feb, 2024 2 commits
  6. 07 Feb, 2024 3 commits
  7. 06 Feb, 2024 1 commit
  8. 05 Feb, 2024 4 commits
  9. 01 Feb, 2024 19 commits