1. 25 Feb, 2024 1 commit
  2. 23 Feb, 2024 2 commits
  3. 21 Feb, 2024 2 commits
  4. 20 Feb, 2024 1 commit
  5. 19 Feb, 2024 3 commits
  6. 15 Feb, 2024 3 commits
  7. 14 Feb, 2024 3 commits
  8. 13 Feb, 2024 8 commits
  9. 12 Feb, 2024 4 commits
  10. 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
  11. 09 Feb, 2024 2 commits
  12. 08 Feb, 2024 2 commits
  13. 07 Feb, 2024 3 commits
  14. 06 Feb, 2024 1 commit
  15. 05 Feb, 2024 1 commit