1. 12 Apr, 2022 14 commits
  2. 11 Apr, 2022 2 commits
  3. 08 Apr, 2022 2 commits
  4. 07 Apr, 2022 3 commits
  5. 05 Apr, 2022 2 commits
  6. 30 Mar, 2022 4 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock · bc55cfd5
      Takashi Iwai authored
      syzbot caught a potential deadlock between the PCM
      runtime->buffer_mutex and the mm->mmap_lock.  It was brought by the
      recent fix to cover the racy read/write and other ioctls, and in that
      commit, I overlooked a (hopefully only) corner case that may take the
      revert lock, namely, the OSS mmap.  The OSS mmap operation
      exceptionally allows to re-configure the parameters inside the OSS
      mmap syscall, where mm->mmap_mutex is already held.  Meanwhile, the
      copy_from/to_user calls at read/write operations also take the
      mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.
      
      A similar problem was already seen in the past and we fixed it with a
      refcount (in commit b2483716).  The former fix covered only the
      call paths with OSS read/write and OSS ioctls, while we need to cover
      the concurrent access via both ALSA and OSS APIs now.
      
      This patch addresses the problem above by replacing the buffer_mutex
      lock in the read/write operations with a refcount similar as we've
      used for OSS.  The new field, runtime->buffer_accessing, keeps the
      number of concurrent read/write operations.  Unlike the former
      buffer_mutex protection, this protects only around the
      copy_from/to_user() calls; the other codes are basically protected by
      the PCM stream lock.  The refcount can be a negative, meaning blocked
      by the ioctls.  If a negative value is seen, the read/write aborts
      with -EBUSY.  In the ioctl side, OTOH, they check this refcount, too,
      and set to a negative value for blocking unless it's already being
      accessed.
      
      Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com
      Fixes: dca947d4 ("ALSA: pcm: Fix races among concurrent read/write and buffer changes")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com
      Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      bc55cfd5
    • Takashi Iwai's avatar
      Merge tag 'asoc-fix-v5.18' of... · 21b5954d
      Takashi Iwai authored
      Merge tag 'asoc-fix-v5.18' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v5.18
      
      A few fixes that came in during the merge window, all fairly routine.
      21b5954d
    • Mohan Kumar's avatar
      ALSA: hda: Avoid unsol event during RPM suspending · 6ddc2f74
      Mohan Kumar authored
      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: default avatarMohan Kumar <mkumard@nvidia.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20220329155940.26331-1-mkumard@nvidia.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6ddc2f74
    • Kai-Heng Feng's avatar
      ALSA: hda/realtek: Fix audio regression on Mi Notebook Pro 2020 · f30741cd
      Kai-Heng Feng authored
      Commit 5aec9891 ("ALSA: hda/realtek - ALC236 headset MIC recording
      issue") is to solve recording issue met on AL236, by matching codec
      variant ALC269_TYPE_ALC257 and ALC269_TYPE_ALC256.
      
      This match can be too broad and Mi Notebook Pro 2020 is broken by the
      patch.
      
      Instead, use codec ID to be narrow down the scope, in order to make
      ALC256 unaffected.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215484
      Fixes: 5aec9891 ("ALSA: hda/realtek - ALC236 headset MIC recording issue")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Link: https://lore.kernel.org/r/20220330061335.1015533-1-kai.heng.feng@canonical.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f30741cd
  7. 28 Mar, 2022 6 commits
  8. 27 Mar, 2022 2 commits
  9. 25 Mar, 2022 1 commit
  10. 24 Mar, 2022 1 commit
  11. 23 Mar, 2022 1 commit
  12. 22 Mar, 2022 2 commits
    • Matt Kramer's avatar
      ALSA: hda/realtek: Add alc256-samsung-headphone fixup · ef248d9b
      Matt Kramer authored
      This fixes the near-silence of the headphone jack on the ALC256-based
      Samsung Galaxy Book Flex Alpha (NP730QCJ). The magic verbs were found
      through trial and error, using known ALC298 hacks as inspiration. The
      fixup is auto-enabled only when the NP730QCJ is detected. It can be
      manually enabled using model=alc256-samsung-headphone.
      Signed-off-by: default avatarMatt Kramer <mccleetus@gmail.com>
      Link: https://lore.kernel.org/r/3168355.aeNJFYEL58@linusSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ef248d9b
    • Giacomo Guiduzzi's avatar
      ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec · 17aaf019
      Giacomo Guiduzzi authored
      Tests 72 and 78 for ALSA in kselftest fail due to reading
      inconsistent values from some devices on a VirtualBox
      Virtual Machine using the snd_intel8x0 driver for the AC'97
      Audio Controller device.
      Taking for example test number 72, this is what the test reports:
      "Surround Playback Volume.0 expected 1 but read 0, is_volatile 0"
      "Surround Playback Volume.1 expected 0 but read 1, is_volatile 0"
      These errors repeat for each value from 0 to 31.
      
      Taking a look at these error messages it is possible to notice
      that the written values are read back swapped.
      When the write is performed, these values are initially stored in
      an array used to sanity-check them and write them in the pcmreg
      array. To write them, the two one-byte values are packed together
      in a two-byte variable through bitwise operations: the first
      value is shifted left by one byte and the second value is stored in the
      right byte through a bitwise OR. When reading the values back,
      right shifts are performed to retrieve the previously stored
      bytes. These shifts are executed in the wrong order, thus
      reporting the values swapped as shown above.
      
      This patch fixes this mistake by reversing the read
      operations' order.
      Signed-off-by: default avatarGiacomo Guiduzzi <guiduzzi.giacomo@gmail.com>
      Signed-off-by: default avatarPaolo Valente <paolo.valente@linaro.org>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20220322200653.15862-1-guiduzzi.giacomo@gmail.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      17aaf019