Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 1月, 2020 3 次提交
  3. 04 1月, 2020 2 次提交
    • T
      ALSA: control: Add verification for kctl accesses · fbd3eb7f
      由 Takashi Iwai 提交于 
      The current implementation of ALSA control API fully relies on the
callbacks of each driver, and there is no verification of the values
passed via API.  This patch is an attempt to improve the situation
slightly by adding the validation code for the values stored via info
and get callbacks.

The patch adds a new kconfig, CONFIG_SND_CTL_VALIDATION.  It depends
on CONFIG_SND_DEBUG and off as default since the validation would
require a slight overhead including the additional call of info
callback at each get callback invocation.

When this config is enabled, the values stored by each info callback
invocation are verified, namely:
- Whether the info type is valid
- Whether the number of enum items is non-zero
- Whether the given info count is within the allowed boundary

Similarly, the values stored at each get callback are verified as
well:
- Whether the values are within the given range
- Whether the values are aligned with the given step
- Whether any further changes are seen in the data array over the
  given info count

The last point helps identifying a possibly invalid data type access,
typically a case where the info callback declares the type being
SNDRV_CTL_ELEM_TYPE_ENUMERATED while the get/put callbacks store
the values in value.integer.value[] array.

When a validation fails, the ALSA core logs an error message including
the device and the control ID, and the API call also returns an
error.  So, with the new validation turned on, the driver behavior
difference may be visible on user-space, too -- it's intentional,
though, so that we can catch an error more clearly.

The patch also introduces a new ctl access type,
SNDRV_CTL_ELEM_ACCESS_SKIP_CHECK.  A driver may pass this flag with
other access bits to indicate that the ctl element won't be verified.
It's useful when a driver code is specially written to access the data
greater than info->count size by some reason.  For example, this flag
is actually set now in HD-audio HDMI codec driver which needs to clear
the data array in the case of the disconnected monitor.

Also, the PCM channel-map helper code is slightly modified to avoid
the false-positive hit by this validation code, too.

Link: https://lore.kernel.org/r/20200104083556.27789-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      fbd3eb7f
    • K
      ALSA: hda/realtek - Add new codec supported for ALCS1200A · 6d9ffcff
      由 Kailang Yang 提交于 
      Add ALCS1200A supported.
It was similar as ALC900.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/a9bd3cdaa02d4fa197623448d5c51e50@realtek.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      6d9ffcff
  5. 03 1月, 2020 4 次提交
  7. 01 1月, 2020 1 次提交
  9. 30 12月, 2019 1 次提交
  11. 27 12月, 2019 1 次提交
  13. 24 12月, 2019 1 次提交
    • T
      ALSA: hda - Apply sync-write workaround to old Intel platforms, too · c366b3db
      由 Takashi Iwai 提交于 
      Klaus Ethgen reported occasional high CPU usages in his system that
seem caused by HD-audio driver.  The perf output revealed that it's
in the unsolicited event handling in the workqueue, and the problem
seems triggered by some communication stall between the controller and
the codec at the runtime or system resume.

Actually a similar phenomenon was seen in the past for other Intel
platforms, and we already applied the workaround to enforce sync-write
for CORB/RIRB verbs for Skylake and newer chipsets (commit
2756d914 "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel
chips").  Fortunately, the same workaround is applicable to the old
chipset, and the experiment showed the positive effect.

Based on the experiment result, this patch enables the sync-write
workaround for all Intel chipsets.  The only reason I hesitated to
apply this workaround was about the possibly slightly higher CPU usage.
But if the lack of sync causes a much severer problem even for quite
old chip, we should think this would be necessary for all Intel chips.
Reported-by: NKlaus Ethgen <Klaus@ethgen.ch>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191223171833.GA17053@chua
Link: https://lore.kernel.org/r/20191223221816.32572-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      c366b3db
  15. 21 12月, 2019 1 次提交
  17. 19 12月, 2019 1 次提交
  19. 16 12月, 2019 1 次提交
  21. 15 12月, 2019 4 次提交
  23. 13 12月, 2019 1 次提交
  25. 12 12月, 2019 2 次提交
  27. 11 12月, 2019 6 次提交
  29. 04 12月, 2019 1 次提交
    • 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
  31. 03 12月, 2019 1 次提交
  33. 29 11月, 2019 4 次提交
  35. 28 11月, 2019 2 次提交
  37. 26 11月, 2019 3 次提交