1. 01 Mar, 2016 1 commit
  2. 29 Feb, 2016 3 commits
  3. 28 Feb, 2016 6 commits
    • Takashi Iwai's avatar
      ALSA: timer: Fix ioctls for X32 ABI · b24e7ad1
      Takashi Iwai authored
      X32 ABI takes the 64bit timespec, thus the timer user status ioctl becomes
      incompatible with IA32.  This results in NOTTY error when the ioctl is
      issued.
      
      Meanwhile, this struct in X32 is essentially identical with the one in
      X86-64, so we can just bypassing to the existing code for this
      specific compat ioctl.
      
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b24e7ad1
    • Takashi Iwai's avatar
      ALSA: timer: Fix broken compat timer user status ioctl · 3a72494a
      Takashi Iwai authored
      The timer user status compat ioctl returned the bogus struct used for
      64bit architectures instead of the 32bit one.  This patch addresses
      it to return the proper struct.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3a72494a
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix ioctls X32 ABI · 2251fbbc
      Takashi Iwai authored
      Like the previous fixes for ctl and PCM, we need a fix for
      incompatible X32 ABI regarding the rawmidi: namely, struct
      snd_rawmidi_status has the timespec, and the size and the alignment on
      X32 differ from IA32.
      
      This patch fixes the incompatible ioctl for X32.
      
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2251fbbc
    • Takashi Iwai's avatar
      ALSA: rawmidi: Use comapt_put_timespec() · dd7e3f80
      Takashi Iwai authored
      Instead of open-coding, use the existing helper to copy a 32bit
      timespec from/to 64bit.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dd7e3f80
    • Takashi Iwai's avatar
      ALSA: pcm: Fix ioctls for X32 ABI · 513ace79
      Takashi Iwai authored
      X32 ABI uses the 64bit timespec in addition to 64bit alignment of
      64bit values.  This leads to incompatibilities in some PCM ioctls
      involved with snd_pcm_channel_info, snd_pcm_status and
      snd_pcm_sync_ptr structs.  Fix the PCM compat ABI for these ioctls
      like the previous commit for ctl API.
      Reported-by: default avatarSteven Newbury <steve@snewbury.org.uk>
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      513ace79
    • Takashi Iwai's avatar
      ALSA: ctl: Fix ioctls for X32 ABI · 6236d8bb
      Takashi Iwai authored
      The X32 ABI takes the same alignment like x86-64, and this may result
      in the incompatible struct size from ia32.  Unfortunately, we hit this
      in some control ABI: struct snd_ctl_elem_value differs between them
      due to the position of 64bit variable array.  This ends up with the
      unknown ioctl (ENOTTY) error.
      
      The fix is to add the compat entries for the new aligned struct.
      Reported-and-tested-by: default avatarSteven Newbury <steve@snewbury.org.uk>
      Cc: <stable@vger.kernel.org> # v3.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6236d8bb
  4. 26 Feb, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Loop interrupt handling until really cleared · 473f4145
      Takashi Iwai authored
      Currently the interrupt handler of HD-audio driver assumes that no irq
      update is needed while processing the irq.  But in reality, it has
      been confirmed that the HW irq is issued even during the irq
      handling.  Since we clear the irq status at the beginning, process the
      interrupt, then exits from the handler, the lately issued interrupt is
      left untouched without being properly processed.
      
      This patch changes the interrupt handler code to loop over the
      check-and-process.  The handler tries repeatedly as long as the IRQ
      status are turned on, and either stream or CORB/RIRB is handled.
      
      For checking the stream handling, snd_hdac_bus_handle_stream_irq()
      returns a value indicating the stream indices bits.  Other than that,
      the change is only in the irq handler itself.
      Reported-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      473f4145
  5. 25 Feb, 2016 3 commits
  6. 22 Feb, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Apply clock gate workaround to Skylake, too · 7e31a015
      Takashi Iwai authored
      Some Skylake machines show the codec probe errors in certain
      situations, e.g. HP Z240 desktop fails to probe the onboard Realtek
      codec at reloading the snd-hda-intel module like:
        snd_hda_intel 0000:00:1f.3: spurious response 0x200:0x2, last cmd=0x000000
        snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: lastcmd=0x000f0000
        snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
        snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
        hdaudio hdaudioC0D2: no AFG or MFG node found
        snd_hda_intel 0000:00:1f.3: no codecs initialized
      
      Also, HP G470 G3 suffers from the similar problem, as reported in
      bugzilla below.  On this machine, the codec probe error appears even
      at a fresh boot.
      
      As Libin suggested, the same workaround used for Broxton in the commit
      [6639484d: ALSA: hda - disable dynamic clock gating on Broxton
       before reset] can be applied for Skylake in order to fix this problem.
      The Intel HW team also confirmed that this is needed for SKL.
      
      This patch makes the workaround applied to both SKL and BXT
      platforms.  The referred macros are moved and one superfluous macro
      (IS_BROXTON()) is another one (IS_BXT()) as well.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112731Suggested-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v4.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7e31a015
  7. 18 Feb, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream · 67ec1072
      Takashi Iwai authored
      A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice
      in the same code path, e.g. one in snd_pcm_action_nonatomic() and
      another in snd_pcm_stream_lock().  Usually this is OK, but when a
      write lock is issued between these two read locks, the problem
      happens: the write lock is blocked due to the first reade lock, and
      the second read lock is also blocked by the write lock.  This
      eventually deadlocks.
      
      The reason is the way rwsem manages waiters; it's queued like FIFO, so
      even if the writer itself doesn't take the lock yet, it blocks all the
      waiters (including reads) queued after it.
      
      As a workaround, in this patch, we replace the standard down_write()
      with an spinning loop.  This is far from optimal, but it's good
      enough, as the spinning time is supposed to be relatively short for
      normal PCM operations, and the code paths requiring the write lock
      aren't called so often.
      Reported-by: default avatarVinod Koul <vinod.koul@intel.com>
      Tested-by: default avatarRamesh Babu <ramesh.babu@intel.com>
      Cc: <stable@vger.kernel.org> # v3.18+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      67ec1072
  8. 16 Feb, 2016 1 commit
  9. 15 Feb, 2016 2 commits
    • Takashi Iwai's avatar
      ALSA: hda - Cancel probe work instead of flush at remove · 0b8c8219
      Takashi Iwai authored
      The commit [991f86d7: ALSA: hda - Flush the pending probe work at
      remove] introduced the sync of async probe work at remove for fixing
      the race.  However, this may lead to another hangup when the module
      removal is performed quickly before starting the probe work, because
      it issues flush_work() and it's blocked forever.
      
      The workaround is to use cancel_work_sync() instead of flush_work()
      there.
      
      Fixes: 991f86d7 ('ALSA: hda - Flush the pending probe work at remove')
      Cc: <stable@vger.kernel.org> # v3.17+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0b8c8219
    • Takashi Iwai's avatar
      ALSA: seq: Fix leak of pool buffer at concurrent writes · d99a36f4
      Takashi Iwai authored
      When multiple concurrent writes happen on the ALSA sequencer device
      right after the open, it may try to allocate vmalloc buffer for each
      write and leak some of them.  It's because the presence check and the
      assignment of the buffer is done outside the spinlock for the pool.
      
      The fix is to move the check and the assignment into the spinlock.
      
      (The current implementation is suboptimal, as there can be multiple
       unnecessary vmallocs because the allocation is done before the check
       in the spinlock.  But the pool size is already checked beforehand, so
       this isn't a big problem; that is, the only possible path is the
       multiple writes before any pool assignment, and practically seen, the
       current coverage should be "good enough".)
      
      The issue was triggered by syzkaller fuzzer.
      
      BugLink: http://lkml.kernel.org/r/CACT4Y+bSzazpXNvtAr=WXaL8hptqjHwqEyFA+VN2AWEx=aurkg@mail.gmail.comReported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d99a36f4
  10. 13 Feb, 2016 1 commit
  11. 12 Feb, 2016 1 commit
    • Takashi Iwai's avatar
      Merge tag 'asoc-fix-v4.5-rc4' of... · 86c2ee16
      Takashi Iwai authored
      Merge tag 'asoc-fix-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v4.5
      
      A rather large batch of fixes here, almost all in the Intel driver.
      The changes that got merged in this merge window for Skylake were rather
      large and as well as issues that you'd expect in a large block of new
      code there were some problems created for older processors which needed
      fixing up.  Things are largely settling down now hopefully.
      86c2ee16
  12. 10 Feb, 2016 9 commits
  13. 09 Feb, 2016 5 commits
  14. 08 Feb, 2016 5 commits