Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 7月, 2018 1 次提交
    • L
      ASoC: core: Allow topology to override machine driver FE DAI link config. · a655de80
      由 Liam Girdwood 提交于 
      Machine drivers statically define a number of DAI links that currently
cannot be changed or removed by topology. This means PCMs and platform
components cannot be changed by topology at runtime AND machine drivers
are tightly coupled to topology.

This patch allows topology to override the machine driver DAI link config
in order to reuse machine drivers with different topologies and platform
components. The patch supports :-

1) create new FE PCMs with a topology defined PCM ID.
2) destroy existing static FE PCMs
3) change the platform component driver.
4) assign any new HW params fixups.
5) assign a new card name prefix to differentiate this topology to userspace.

The patch requires no changes to the machine drivers, but does add some
platform component flags that the platform component driver can assign
before loading topologies.
Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      a655de80
  3. 02 7月, 2018 11 次提交
  5. 29 6月, 2018 2 次提交
  7. 22 6月, 2018 1 次提交
  9. 19 6月, 2018 1 次提交
  11. 18 6月, 2018 4 次提交
  13. 30 5月, 2018 1 次提交
  15. 24 5月, 2018 1 次提交
  17. 17 5月, 2018 1 次提交
    • T
      ALSA: core: Assure control device to be registered at last · dc82e524
      由 Takashi Iwai 提交于 
      The commit 289ca025 ("ALSA: Use priority list for managing device
list") changed the way to register/disconnect/free devices via a
single priority list.  This helped to make behavior consistent, but it
also changed a slight behavior change: namely, the control device is
registered earlier than others, while it was supposed to be the very
last one.

I've put SNDRV_DEV_CONTROL in the current position as the release of
ctl elements often conflict with the private ctl elements some PCM or
other components may create, which often leads to a double-free.
But, the order of register and disconnect should be indeed fixed as
expected in the early days: the control device gets registered at
last, and disconnected at first.

This patch changes the priority list order to move SNDRV_DEV_CONTROL
as the last guy to assure the register / disconnect order.  Meanwhile,
for keeping the messy resource release order, manually treat the
control and lowlevel devices as last freed one.

Additional note:
The lowlevel device is the device where a card driver creates at
probe.  And, we still keep the release order control -> lowlevel, as
there might  be link from a control element back to a lowlevel object.

Fixes: 289ca025 ("ALSA: Use priority list for managing device list")
Reported-by: NTzung-Bi Shih <tzungbi@google.com>
Tested-by: NTzung-Bi Shih <tzungbi@google.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      dc82e524
  19. 12 5月, 2018 1 次提交
  21. 11 5月, 2018 2 次提交
  23. 09 5月, 2018 6 次提交
  25. 02 5月, 2018 1 次提交
    • J
      ASoC: dai playback and capture active may be greater than 1 · 40c57963
      由 Jerome Brunet 提交于 
      At the moment playback_active and capture_active are using only 1 bit so
the maximum active count is 1.

However, snd_soc_runtime_activate() may be called several time on the
same dai. This happens when a dai is part of several dai_links. It is
often the case for "snd-soc-dummy-dai".

This is a problem if snd_soc_runtime_activate() is called an even number
of times on a dai. In this case the active count overflow back to 0. As
consequence, ASoC functions, such as soc_dpcm_runtime_update(), won't run
correctly.

Storing these usage counts on plain 'unsigned int' solves the problem.

Fixes: f0fba2ad ("ASoC: multi-component - ASoC Multi-Component Support")
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      40c57963
  27. 26 4月, 2018 1 次提交
  29. 25 4月, 2018 1 次提交
    • T
      ALSA: control: Hardening for potential Spectre v1 · 088e861e
      由 Takashi Iwai 提交于 
      As recently Smatch suggested, a few places in ALSA control core codes
may expand the array directly from the user-space value with
speculation:

  sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd'

Although all these seem doing only the first load without further
reference, we may want to stay in a safer side, so hardening with
array_index_nospec() would still make sense.

In this patch, we put array_index_nospec() to the common
snd_ctl_get_ioff*() helpers instead of each caller.  These helpers are
also referred from some drivers, too, and basically all usages are to
calculate the array index from the user-space value, hence it's better
to cover there.

BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      088e861e
  31. 24 4月, 2018 1 次提交
  33. 19 4月, 2018 1 次提交
  35. 18 4月, 2018 3 次提交