1. 11 12月, 2019 2 次提交
  2. 10 12月, 2019 2 次提交
  3. 09 12月, 2019 1 次提交
  4. 08 12月, 2019 1 次提交
    • O
      ALSA: echoaudio: simplify get_audio_levels · c08f0a92
      Olof Johansson 提交于
      The loop optimizer seems to go astray here, and produces some warnings
      that don't seem valid.
      
      Still, the code can be simplified -- just clear the whole array at the
      beginning, and fill in whatever values are valid on the platform.
      
      Warnings before this change (GCC 8.2.0 ARM allmodconfig):
      
      In file included from ../sound/pci/echoaudio/gina24.c:115:
      ../sound/pci/echoaudio/echoaudio.c: In function 'snd_echo_vumeters_get':
      ../sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
      In file included from ../sound/pci/echoaudio/layla24.c:112:
      ../sound/pci/echoaudio/echoaudio.c: In function 'snd_echo_vumeters_get':
      ../sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
      ../sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Link: https://lore.kernel.org/r/20191207224953.25944-1-olof@lixom.netSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      c08f0a92
  5. 04 12月, 2019 2 次提交
    • T
      ALSA: pcm: oss: Avoid potential buffer overflows · 4cc8d650
      Takashi Iwai 提交于
      syzkaller reported an invalid access in PCM OSS read, and this seems
      to be an overflow of the internal buffer allocated for a plugin.
      Since the rate plugin adjusts its transfer size dynamically, the
      calculation for the chained plugin might be bigger than the given
      buffer size in some extreme cases, which lead to such an buffer
      overflow as caught by KASAN.
      
      Fix it by limiting the max transfer size properly by checking against
      the destination size in each plugin transfer callback.
      
      Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      4cc8d650
    • T
      ALSA: hda: hdmi - Keep old slot assignment behavior for Intel platforms · 643a2cc9
      Takashi Iwai 提交于
      The commit 609f5485 ("ALSA: hda: hdmi - preserve non-MST PCM
      routing for Intel platforms") tried to restore the old behavior wrt
      assignment of the PCM slot for Intel platforms, but this didn't do it
      right.  As found in the later discussion, a positive pipe id on Intel
      platforms can be passed for single monitor attachment case.
      
      This patch reverts the previous attempt and applies a simpler
      workaround instead.  Actually, for Intel platforms, we can handle as
      if per_pin->dev_id=0, assign the primary slot at the first try.  This
      assures the compatible behavior with the previous versions regarding
      the slot assignment.
      
      Fixes: 609f5485 ("ALSA: hda: hdmi - preserve non-MST PCM routing for Intel platforms")
      Link: https://lore.kernel.org/r/20191203154105.30414-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      643a2cc9
  6. 03 12月, 2019 1 次提交
  7. 29 11月, 2019 4 次提交
  8. 28 11月, 2019 2 次提交
  9. 27 11月, 2019 1 次提交
  10. 26 11月, 2019 4 次提交
  11. 25 11月, 2019 3 次提交
  12. 24 11月, 2019 1 次提交
  13. 23 11月, 2019 7 次提交
  14. 22 11月, 2019 7 次提交
  15. 21 11月, 2019 2 次提交