1. 30 Apr, 2019 1 commit
  2. 28 Apr, 2019 2 commits
  3. 24 Apr, 2019 1 commit
  4. 17 Apr, 2019 1 commit
  5. 16 Apr, 2019 2 commits
    • Takashi Iwai's avatar
      ALSA: core: Fix card races between register and disconnect · 2a3f7221
      Takashi Iwai authored
      There is a small race window in the card disconnection code that
      allows the registration of another card with the very same card id.
      This leads to a warning in procfs creation as caught by syzkaller.
      
      The problem is that we delete snd_cards and snd_cards_lock entries at
      the very beginning of the disconnection procedure.  This makes the
      slot available to be assigned for another card object while the
      disconnection procedure is being processed.  Then it becomes possible
      to issue a procfs registration with the existing file name although we
      check the conflict beforehand.
      
      The fix is simply to move the snd_cards and snd_cards_lock clearances
      at the end of the disconnection procedure.  The references to these
      entries are merely either from the global proc files like
      /proc/asound/cards or from the card registration / disconnection, so
      it should be fine to shift at the very end.
      
      Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2a3f7221
    • Takashi Iwai's avatar
      ALSA: info: Fix racy addition/deletion of nodes · 8c2f8708
      Takashi Iwai authored
      The ALSA proc helper manages the child nodes in a linked list, but its
      addition and deletion is done without any lock.  This leads to a
      corruption if they are operated concurrently.  Usually this isn't a
      problem because the proc entries are added sequentially in the driver
      probe procedure itself.  But the card registrations are done often
      asynchronously, and the crash could be actually reproduced with
      syzkaller.
      
      This patch papers over it by protecting the link addition and deletion
      with the parent's mutex.  There is "access" mutex that is used for the
      file access, and this can be reused for this purpose as well.
      
      Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8c2f8708
  6. 13 Apr, 2019 1 commit
    • Takashi Iwai's avatar
      ALSA: hda: Initialize power_state field properly · 183ab39e
      Takashi Iwai authored
      The recent commit 98081ca6 ("ALSA: hda - Record the current power
      state before suspend/resume calls") made the HD-audio driver to store
      the PM state in power_state field.  This forgot, however, the
      initialization at power up.  Although the codec drivers usually don't
      need to refer to this field in the normal operation, let's initialize
      it properly for consistency.
      
      Fixes: 98081ca6 ("ALSA: hda - Record the current power state before suspend/resume calls")
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      183ab39e
  7. 11 Apr, 2019 1 commit
    • Takashi Iwai's avatar
      Merge tag 'asoc-fix-v5.1-rc4' of... · 9b0dcd0e
      Takashi Iwai authored
      Merge tag 'asoc-fix-v5.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v5.1
      
      A few core fixes along with the driver specific ones, mainly fixing
      small issues that only affect x86 platforms for various reasons (their
      unusual machine enumeration mechanisms mainly, plus a fix for error
      handling in topology).
      
      There's some of the driver fixes that look larger than they are, like
      the hdmi-codec changes which resulted in an indentation change, and most
      of the other large changes are for new drivers like the STM32 changes.
      9b0dcd0e
  8. 10 Apr, 2019 5 commits
  9. 08 Apr, 2019 5 commits
  10. 05 Apr, 2019 3 commits
  11. 04 Apr, 2019 6 commits
  12. 03 Apr, 2019 4 commits
    • Richard Sailer's avatar
      ALSA: hda/realtek - Add quirk for Tuxedo XC 1509 · 80690a27
      Richard Sailer authored
      This adds a SND_PCI_QUIRK(...) line for the Tuxedo XC 1509.
      
      The Tuxedo XC 1509 and the System76 oryp5 are the same barebone
      notebooks manufactured by Clevo. To name the fixups both use after the
      actual underlying hardware, this patch also changes System76_orpy5
      to clevo_pb51ed in 2 enum symbols and one function name,
      matching the other pci_quirk entries which are also named after the
      device ODM.
      
      Fixes: 7f665b1c ("ALSA: hda/realtek - Headset microphone and internal speaker support for System76 oryp5")
      Signed-off-by: default avatarRichard Sailer <rs@tuxedocomputers.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      80690a27
    • Kailang Yang's avatar
      ALSA: hda/realtek - Move to ACT_INIT state · 8983eb60
      Kailang Yang authored
      It will be lose Mic JD state when Chrome OS boot and headset was plugged.
      Just Implement of reset combo jack JD verb for ACT_PRE_PROBE state.
      Intel test result was also failed.
      It test passed until changed the initial state to ACT_INIT.
      Mic JD will show every time.
      This patch also changed the model name as 'alc-chrome-book' for
      application of Chrome OS.
      
      Fixes: 10f5b1b8 ("ALSA: hda/realtek - Fixed Headset Mic JD not stable")
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8983eb60
    • Hans de Goede's avatar
      ASoC: Intel: cht_bsw_max98090_ti: Enable codec clock once and keep it enabled · 4bcdec39
      Hans de Goede authored
      Users have been seeing sound stability issues with max98090 codecs since:
      commit 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
      
      At first that commit broke sound for Chromebook Swanky and Clapper models,
      the problem was that the machine-driver has been controlling the wrong
      clock on those models since support for them was added. This was hidden by
      clk-pmc-atom.c keeping the actual clk on unconditionally.
      
      With the machine-driver controlling the proper clock, sound works again
      but we are seeing bug reports describing it as: low volume,
      "sounds like played at 10x speed" and instable.
      
      When these issues are hit the following message is seen in dmesg:
      "max98090 i2c-193C9890:00: PLL unlocked".
      
      Attempts have been made to fix this by inserting a delay between enabling
      the clk and enabling and checking the pll, but this has not helped.
      
      It seems that at least on boards which use pmc_plt_clk_0 as clock,
      if we ever disable the clk, the pll looses its lock and after that we get
      various issues.
      
      This commit fixes this by enabling the clock once at probe time on
      these boards. In essence this restores the old behavior of clk-pmc-atom.c
      always keeping the clk on on these boards.
      
      Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
      Reported-by: default avatarMogens Jensen <mogens-jensen@protonmail.com>
      Reported-by: default avatarDean Wallace <duffydack73@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      4bcdec39
    • Charles Keepax's avatar
      ASoC: wm_adsp: Check for buffer in trigger stop · 43d147be
      Charles Keepax authored
      Trigger stop can be called in situations where trigger start failed
      and as such it can't be assumed the buffer is already attached to
      the compressed stream or a NULL pointer may be dereferenced.
      
      Fixes: 639e5eb3 ("ASoC: wm_adsp: Correct handling of compressed streams that restart")
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      43d147be
  13. 02 Apr, 2019 4 commits
  14. 01 Apr, 2019 1 commit
  15. 26 Mar, 2019 2 commits
  16. 25 Mar, 2019 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Don't suspend stream in unrecoverable PCM state · 113ce081
      Takashi Iwai authored
      Currently PCM core sets each opened stream forcibly to SUSPENDED state
      via snd_pcm_suspend_all() call, and the user-space is responsible for
      re-triggering the resume manually either via snd_pcm_resume() or
      prepare call.  The scheme works fine usually, but there are corner
      cases where the stream can't be resumed by that call: the streams
      still in OPEN state before finishing hw_params.  When they are
      suspended, user-space cannot perform resume or prepare because they
      haven't been set up yet.  The only possible recovery is to re-open the
      device, which isn't nice at all.  Similarly, when a stream is in
      DISCONNECTED state, it makes no sense to change it to SUSPENDED
      state.  Ditto for in SETUP state; which you can re-prepare directly.
      
      So, this patch addresses these issues by filtering the PCM streams to
      be suspended by checking the PCM state.  When a stream is in either
      OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend
      action is skipped.
      
      To be noted, this problem was originally reported for the PCM runtime
      PM on HD-audio.  And, the runtime PM problem itself was already
      addressed (although not intended) by the code refactoring commits
      3d21ef0b ("ALSA: pcm: Suspend streams globally via device type PM
      ops") and 17bc4815 ("ALSA: pci: Remove superfluous
      snd_pcm_suspend*() calls").  These commits eliminated the
      snd_pcm_suspend*() calls from the runtime PM suspend callback code
      path, hence the racy OPEN state won't appear while runtime PM.
      (FWIW, the race window is between snd_pcm_open_substream() and the
      first power up in azx_pcm_open().)
      
      Although the runtime PM issue was already "fixed", the same problem is
      still present for the system PM, hence this patch is still needed.
      And for stable trees, this patch alone should suffice for fixing the
      runtime PM problem, too.
      Reported-and-tested-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      113ce081