1. 24 Apr, 2019 1 commit
  2. 17 Apr, 2019 1 commit
  3. 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
  4. 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
  5. 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
  6. 10 Apr, 2019 5 commits
  7. 08 Apr, 2019 5 commits
  8. 05 Apr, 2019 3 commits
  9. 04 Apr, 2019 6 commits
  10. 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
  11. 02 Apr, 2019 4 commits
  12. 01 Apr, 2019 1 commit
  13. 26 Mar, 2019 2 commits
  14. 25 Mar, 2019 3 commits
    • 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
    • Pankaj Bharadiya's avatar
      ASoC: dapm: Fix NULL pointer dereference in snd_soc_dapm_free_kcontrol · cacea3a9
      Pankaj Bharadiya authored
      w_text_param can be NULL and it is being dereferenced without checking.
      Add the missing sanity check to prevent  NULL pointer dereference.
      Signed-off-by: default avatarPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      cacea3a9
    • Guenter Roeck's avatar
      ASoC: intel: Fix crash at suspend/resume after failed codec registration · 8f71370f
      Guenter Roeck authored
      If codec registration fails after the ASoC Intel SST driver has been probed,
      the kernel will Oops and crash at suspend/resume.
      
      general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
      CPU: 1 PID: 2811 Comm: cat Tainted: G        W         4.19.30 #15
      Hardware name: GOOGLE Clapper, BIOS Google_Clapper.5216.199.7 08/22/2014
      RIP: 0010:snd_soc_suspend+0x5a/0xd21
      Code: 03 80 3c 10 00 49 89 d7 74 0b 48 89 df e8 71 72 c4 fe 4c 89
      fa 48 8b 03 48 89 45 d0 48 8d 98 a0 01 00 00 48 89 d8 48 c1 e8 03
      <8a> 04 10 84 c0 0f 85 85 0c 00 00 80 3b 00 0f 84 6b 0c 00 00 48 8b
      RSP: 0018:ffff888035407750 EFLAGS: 00010202
      RAX: 0000000000000034 RBX: 00000000000001a0 RCX: 0000000000000000
      RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88805c417098
      RBP: ffff8880354077b0 R08: dffffc0000000000 R09: ffffed100b975718
      R10: 0000000000000001 R11: ffffffff949ea4a3 R12: 1ffff1100b975746
      R13: dffffc0000000000 R14: ffff88805cba4588 R15: dffffc0000000000
      FS:  0000794a78e91b80(0000) GS:ffff888068d00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007bd5283ccf58 CR3: 000000004b7aa000 CR4: 00000000001006e0
      Call Trace:
      ? dpm_complete+0x67b/0x67b
      ? i915_gem_suspend+0x14d/0x1ad
      sst_soc_prepare+0x91/0x1dd
      ? sst_be_hw_params+0x7e/0x7e
      dpm_prepare+0x39a/0x88b
      dpm_suspend_start+0x13/0x9d
      suspend_devices_and_enter+0x18f/0xbd7
      ? arch_suspend_enable_irqs+0x11/0x11
      ? printk+0xd9/0x12d
      ? lock_release+0x95f/0x95f
      ? log_buf_vmcoreinfo_setup+0x131/0x131
      ? rcu_read_lock_sched_held+0x140/0x22a
      ? __bpf_trace_rcu_utilization+0xa/0xa
      ? __pm_pr_dbg+0x186/0x190
      ? pm_notifier_call_chain+0x39/0x39
      ? suspend_test+0x9d/0x9d
      pm_suspend+0x2f4/0x728
      ? trace_suspend_resume+0x3da/0x3da
      ? lock_release+0x95f/0x95f
      ? kernfs_fop_write+0x19f/0x32d
      state_store+0xd8/0x147
      ? sysfs_kf_read+0x155/0x155
      kernfs_fop_write+0x23e/0x32d
      __vfs_write+0x108/0x608
      ? vfs_read+0x2e9/0x2e9
      ? rcu_read_lock_sched_held+0x140/0x22a
      ? __bpf_trace_rcu_utilization+0xa/0xa
      ? debug_smp_processor_id+0x10/0x10
      ? selinux_file_permission+0x1c5/0x3c8
      ? rcu_sync_lockdep_assert+0x6a/0xad
      ? __sb_start_write+0x129/0x2ac
      vfs_write+0x1aa/0x434
      ksys_write+0xfe/0x1be
      ? __ia32_sys_read+0x82/0x82
      do_syscall_64+0xcd/0x120
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      In the observed situation, the problem is seen because the codec driver
      failed to probe due to a hardware problem.
      
      max98090 i2c-193C9890:00: Failed to read device revision: -1
      max98090 i2c-193C9890:00: ASoC: failed to probe component -1
      cht-bsw-max98090 cht-bsw-max98090: ASoC: failed to instantiate card -1
      cht-bsw-max98090 cht-bsw-max98090: snd_soc_register_card failed -1
      cht-bsw-max98090: probe of cht-bsw-max98090 failed with error -1
      
      The problem is similar to the problem solved with commit 2fc995a8
      ("ASoC: intel: Fix crash at suspend/resume without card registration"),
      but codec registration fails at a later point. At that time, the pointer
      checked with the above mentioned commit is already set, but it is not
      cleared if the device is subsequently removed. Adding a remove function
      to clear the pointer fixes the problem.
      
      Cc: stable@vger.kernel.org
      Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
      Cc: Curtis Malainey <cujomalainey@chromium.org>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      8f71370f
  15. 22 Mar, 2019 1 commit