1. 08 May, 2016 5 commits
    • Kangjie Lu's avatar
      ALSA: timer: Fix leak in events via snd_timer_user_tinterrupt · e4ec8cc8
      Kangjie Lu authored
      The stack object “r1” has a total size of 32 bytes. Its field
      “event” and “val” both contain 4 bytes padding. These 8 bytes
      padding bytes are sent to user without being initialized.
      Signed-off-by: default avatarKangjie Lu <kjlu@gatech.edu>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Kangjie Lu's avatar
      ALSA: timer: Fix leak in events via snd_timer_user_ccallback · 9a47e9cf
      Kangjie Lu authored
      The stack object “r1” has a total size of 32 bytes. Its field
      “event” and “val” both contain 4 bytes padding. These 8 bytes
      padding bytes are sent to user without being initialized.
      Signed-off-by: default avatarKangjie Lu <kjlu@gatech.edu>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Kangjie Lu's avatar
      ALSA: timer: Fix leak in SNDRV_TIMER_IOCTL_PARAMS · cec8f96e
      Kangjie Lu authored
      The stack object “tread” has a total size of 32 bytes. Its field
      “event” and “val” both contain 4 bytes padding. These 8 bytes
      padding bytes are sent to user without being initialized.
      Signed-off-by: default avatarKangjie Lu <kjlu@gatech.edu>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Vinod Koul's avatar
      ALSA: compress: fix some typo · 242658ff
      Vinod Koul authored
      Noticed two typos in Documentation, so fix them up
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Sakamoto's avatar
      ALSA: dice: add support for M-Audio Profire 610 and perhaps 2626 · f8ff65bc
      Takashi Sakamoto authored
      M-Audio Profire 610 has an unexpected value in version field of its config
      ROM, thus ALSA dice driver is not assigned to the model due to a mismatch
      of modalias.
      This commit adds an entry to support the model. I expect the entry is
      also for Profire 2626.
      I note that Profire 610 uses TCD2220 (so-called Dice Jr.), and supports a
      part of Extended Application Protocol (EAP).
      $ cd linux-firewire-utils/src
      $ ./crpp < /sys/bus/firewire/devices/fw1/config_rom
                     ROM header and bus information block
      400  04047689  bus_info_length 4, crc_length 4, crc 30345
      404  31333934  bus_name "1394"
      408  e0ff8112  irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255,
                     max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400)
      40c  000d6c04  company_id 000d6c     |
      410  04400002  device_id 0404400002  | EUI-64 000d6c0404400002
                     root directory
      414  000695fe  directory_length 6, crc 38398
      418  03000d6c  vendor
      41c  8100000a  --> descriptor leaf at 444
      420  17000011  model
      424  8100000d  --> descriptor leaf at 458
      428  0c0087c0  node capabilities per IEEE 1394
      42c  d1000001  --> unit directory at 430
                     unit directory at 430
      430  0004fb14  directory_length 4, crc 64276
      434  12000d6c  specifier id
      438  130100d1  version
      43c  17000011  model
      440  8100000c  --> descriptor leaf at 470
                     descriptor leaf at 444
      444  0004b8e4  leaf_length 4, crc 47332
      448  00000000  textual descriptor
      44c  00000000  minimal ASCII
      450  4d2d4175  "M-Au"
      454  64696f00  "dio"
                     descriptor leaf at 458
      458  00053128  leaf_length 5, crc 12584
      45c  00000000  textual descriptor
      460  00000000  minimal ASCII
      464  50726f46  "ProF"
      468  69726520  "ire "
      46c  36313000  "610"
                     descriptor leaf at 470
      470  00053128  leaf_length 5, crc 12584
      474  00000000  textual descriptor
      478  00000000  minimal ASCII
      47c  50726f46  "ProF"
      480  69726520  "ire "
      484  36313000  "610"
      $ cat /proc/asound/card1/dice
        global: offset 10, size 90
        tx: offset 100, size 142
        rx: offset 242, size 282
        ext_sync: offset 524, size 4
        unused2: offset 0, size 0
        owner: ffc0:000100000000
        notification: 00000040
        nick name: FW610
        clock select: internal 48000
        enable: 1
        status: locked 48000
        ext status: 00000040
        sample rate: 48000
        clock caps: 32000 44100 48000 88200 96000 176400 192000 aes1 aes4 aes adat tdif wc arx1 arx2 internal
        clock source names: SPDIF\AES34\AES56\TOS\AES_ANY\ADAT\ADAT_AUX\Word Clock\Unused\Unused\Unused\Unused\Internal\\
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  2. 29 Apr, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Limit retrying sample rate reads · 57dd5414
      Takashi Iwai authored
      There are many USB audio devices with buggy firmware that don't react
      with the sample rate reading properly.  This often results in the
      flood of error messages and slowing down the operation.
      The sample rate read back is basically only for confirming the sample
      rate setup, and it's not critically important.  As a compromise, in
      this patch, we stop the sample rate read back once when the device
      gives errors more than tolerance (twice, as of now).  This should
      improve most of error cases while we still can catch the firmware
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  3. 26 Apr, 2016 5 commits
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · a33d5959
      Takashi Iwai authored
      For taking back the recent change of HDA HDMI fixes for i915 HSW/BDW.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: hda - Update BCLK also at hotplug for i915 HSW/BDW · bb03ed21
      Takashi Iwai authored
      The recent bug report suggests that BCLK setup for i915 HSW/BDW needs
      to be updated at each HDMI hotplug, not only at initialization and
      resume.  That is, we need to update HSW_EM4 and HSW_EM5 registers at
      ELD notification, too.  Otherwise the HDMI audio may be out of sync
      and played in a wrong pitch.
      However, the HDA codec driver has no access to the controller
      registers, and currently the code managing these registers is in
      hda_intel.c, i.e. local to the controller driver.  For allowing the
      explicit BCLK update from the codec driver, as in this patch, the
      former haswell_set_bclk() in hda_intel.c is moved to hdac_i915.c and
      exposed as snd_hdac_i915_set_bclk().  This is called from both the HDA
      controller driver and intel_pin_eld_notify() in HDMI codec driver.
      Along with this change, snd_hdac_get_display_clk() gets dropped as
      it's no longer used.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91410
      Cc: <stable@vger.kernel.org> # v4.5+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Conrad Kostecki's avatar
      ALSA: hda - Add dock support for ThinkPad X260 · 037e1197
      Conrad Kostecki authored
      Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013
      docking station series (basic, pro, ultra).
      Signed-off-by: default avatarConrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: au88x0: Fix overlapped PCM pointer · 58a8738c
      Takashi Iwai authored
      au88x0 hardware seems returning the current pointer at the buffer
      boundary instead of going back to zero.  This results in spewing
      warnings from PCM core.
      This patch corrects the return value from the pointer callback within
      the proper value range, just returning zero if the position is equal
      or above the buffer size.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: hrtimer: Handle start/stop more properly · d2c5cf88
      Takashi Iwai authored
      This patch tries to address the still remaining issues in ALSA hrtimer
      - Spurious use-after-free was detected in hrtimer callback
      - Incorrect rescheduling due to delayed start
      - WARN_ON() is triggered in hrtimer_forward() invoked in hrtimer
      The first issue happens only when the new timer is scheduled even
      while hrtimer is being closed.  It's related with the second and third
      items; since ALSA timer core invokes hw.start callback during hrtimer
      interrupt, this may result in the explicit call of hrtimer_start().
      Also, the similar problem is seen for the stop; ALSA timer core
      invokes hw.stop callback even in the hrtimer handler, too.  Since we
      must not call the synced hrtimer_cancel() in such a context, it's just
      a hrtimer_try_to_cancel() call that doesn't properly work.
      Another culprit of the second and third items is the call of
      hrtimer_forward_now() before snd_timer_interrupt().  The timer->stick
      value may change during snd_timer_interrupt() call, but this
      possibility is ignored completely.
      For covering these subtle and messy issues, the following changes have
      been done in this patch:
      - A new flag, in_callback, is introduced in the private data to
        indicate that the hrtimer handler is being processed.
      - Both start and stop callbacks skip when called from (during)
        in_callback flag.
      - The hrtimer handler returns properly HRTIMER_RESTART and NORESTART
        depending on the running state now.
      - The hrtimer handler reprograms the expiry properly after
        snd_timer_interrupt() call, instead of before.
      - The close callback clears running flag and sets in_callback flag
        to block any further start/stop calls.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  4. 25 Apr, 2016 3 commits
  5. 21 Apr, 2016 2 commits
    • Takashi Iwai's avatar
      ALSA: hda - Fix possible race on regmap bypass flip · 3194ed49
      Takashi Iwai authored
      HD-audio driver uses regmap cache bypass feature for reading a raw
      value without the cache.  But this is racy since both the cached and
      the uncached reads may occur concurrently.  The former is done via the
      normal control API access while the latter comes from the proc file
      Even though the regmap itself has the protection against the
      concurrent accesses, the flag set/reset is done without the
      protection, so it may lead to inconsistent state of bypass flag that
      doesn't match with the current read and occasionally result in a
      kernel WARNING like:
        WARNING: CPU: 3 PID: 2731 at drivers/base/regmap/regcache.c:499 regcache_cache_only+0x78/0x93
      One way to work around such a problem is to wrap with a mutex.  But in
      this case, the solution is simpler: for the uncached read, we just
      skip the regmap and directly calls its accessor.  The verb execution
      there is protected by itself, so basically it's safe to call
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: pcxhr: Fix missing mutex unlock · 67f3754b
      Takashi Iwai authored
      The commit [9bef72bd: ALSA: pcxhr: Use nonatomic PCM ops]
      converted to non-atomic PCM ops, but shamelessly with an unbalanced
      mutex locking, which leads to the hangup easily.  Fix it.
      Fixes: 9bef72bd ('ALSA: pcxhr: Use nonatomic PCM ops')
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116441
      Cc: <stable@vger.kernel.org> # 3.18+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  6. 20 Apr, 2016 1 commit
  7. 19 Apr, 2016 2 commits
  8. 18 Apr, 2016 2 commits
  9. 17 Apr, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Don't trust the reported actual power state · 50fd4987
      Takashi Iwai authored
      We've got a regression report that the recording on Mac with a cirrus
      codec doesn't work any longer.  This turned out to be the missing
      power up to D0 by power_save_node enablement.
      After analyzing the traces, we found out that the culprit is that the
      codec advertises the "actual" power state of a few nodes to be D0
      while the "target" power state is D3.  This inconsistency is usually
      OK, as it implies the power transition.  But in the case of cirrus
      codec, this seems to be stuck to D3 while it's not actually D0.
      This patch addresses the issue by checking the power state difference
      more strictly.  It sends the power-state change verb unless both the
      target and the actual power states show the given value.
      We may introduce yet another flag indicating the possible broken
      hardware power state, but it's anyway safer to set the proper power
      state even in a transition (at least it's harmless as long as the
      target state is same).  So this simpler change was applied now.
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171
      Cc: <stable@vger.kernel.org> # v4.4+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  10. 15 Apr, 2016 1 commit
  11. 14 Apr, 2016 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm : Call kill_fasync() in stream lock · 3aa02cb6
      Takashi Iwai authored
      Currently kill_fasync() is called outside the stream lock in
      snd_pcm_period_elapsed().  This is potentially racy, since the stream
      may get released even during the irq handler is running.  Although
      snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
      guarantee that the irq handler finishes, thus the kill_fasync() call
      outside the stream spin lock may be invoked after the substream is
      detached, as recently reported by KASAN.
      As a quick workaround, move kill_fasync() call inside the stream
      lock.  The fasync is rarely used interface, so this shouldn't have a
      big impact from the performance POV.
      Ideally, we should implement some sync mechanism for the proper finish
      of stream and irq handler.  But this oneliner should suffice for most
      cases, so far.
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  12. 13 Apr, 2016 2 commits
    • Takashi Iwai's avatar
      ALSA: hda - Fix inconsistent monitor_present state until repoll · c44da62b
      Takashi Iwai authored
      While the previous commit fixed the missing monitor_present flag
      update, it may be still in an inconsistent state while the driver
      repolls: the flag itself is updated, but the eld_valid flag and the
      contents don't follow until the repoll finishes (and may be repeated
      for a few times).
      The basic problem is that pin_eld->monitor_present is updated in the
      caller side.  This should have been updated only in update_eld().  So,
      the proper fix is to avoid accessing pin_eld but only spec->temp_eld.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Hyungwon Hwang's avatar
      ALSA: hda - Fix regression of monitor_present flag in eld proc file · 023d8218
      Hyungwon Hwang authored
      The commit [bd481285: ALSA: hda - Fix forgotten HDMI
      monitor_present update] covered the missing update of monitor_present
      flag, but this caused a regression for devices without the i915 eld
      notifier.  Since the old code supposed that pin_eld->monitor_present
      was updated by the caller side, the hdmi_present_sense_via_verbs()
      doesn't update the temporary eld->monitor_present but only
      pin_eld->monitor_present, which is now overridden in update_eld().
      The fix is to update pin_eld->monitor_present as well before calling
      Note that this may still leave monitor_present flag in an inconsistent
      state when the driver repolls, but this is at least the old behavior.
      More proper fix will follow in the later patch.
      Fixes: bd481285 ('ALSA: hda - Fix forgotten HDMI monitor_present update')
      Signed-off-by: default avatarHyungwon Hwang <hyungwon.hwang7@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  13. 12 Apr, 2016 3 commits
  14. 11 Apr, 2016 2 commits
  15. 09 Apr, 2016 3 commits
  16. 08 Apr, 2016 1 commit
  17. 06 Apr, 2016 2 commits
    • Dennis Kadioglu's avatar
      ALSA: usb-audio: Add a quirk for Plantronics BT300 · b4203ff5
      Dennis Kadioglu authored
      Plantronics BT300 does not support reading the sample rate which leads
      to many lines of "cannot get freq at ep 0x1". This patch adds the USB
      ID of the BT300 to quirks.c and avoids those error messages.
      Signed-off-by: default avatarDennis Kadioglu <denk@post.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    • Takashi Iwai's avatar
      ALSA: intel8x0: Drop superfluous VM checks · 4926c804
      Takashi Iwai authored
      intel8x0 driver has the inside_vm check for skipping a buggy hardware
      workaround in the PCM pointer callback in the commit [228cf793:
      ALSA: intel8x0: Improve performance in virtual environment].  This was
      originally applied to all devices on known VMs, but the code was
      switched to use the PCI  ID matching for applying to only known
      devices (KVM and Parallels), in order to avoid applying wrongly to
      VT-d and other such cases, in the commit [7fb4f392: ALSA:
      intel8x0: improve virtual environment detection].
      Meanwhile, the original VM check was kept even after switching to the
      PCI ID matching.  It was partly because we weren't 100% sure whether
      we had covered all well, and partly because this would help
      identifying the issue once when a user of another VM hit the same
      problem or a regression.  Currently the VM check is used only for
      showing the kernel message that the VM-optimization isn't applied, and
      the VM check itself doesn't change the actual driver behavior at all.
      Despite the relatively safe driver behavior, the code caught attention
      of developers badly and brought many confusion / misunderstanding.
      Since we've got neither regression nor enhancement report for other
      VMs for five years long, it's likely safe to drop this superfluous VM
      check now.
      The module option is still kept, so if a user still needs to adjust,
      it can be applied as was.
      Acked-by: default avatarKonstantin Ozerkov <kozerkov@parallels.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
  18. 04 Apr, 2016 3 commits