Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 7月, 2019 4 次提交
  3. 25 6月, 2019 1 次提交
  5. 28 5月, 2019 1 次提交
    • K
      ASoC: soc-core: fixup references at soc_cleanup_card_resources() · 29040d1a
      由 Kuninori Morimoto 提交于 
      commit 53e947a0 ("ASoC: soc-core: merge card resources cleanup
method") merged cleanup method of snd_soc_instantiate_card() and
soc_cleanup_card_resources().

But, after this commit, if user uses unbind/bind to Component factor
drivers, Kernel might indicates refcount error at
soc_cleanup_card_resources().

The 1st reason is card->snd_card is still exist even though
snd_card_free() was called, but it is already cleaned.
We need to set NULL to it.

2nd is card->dapm and card create debugfs, but its dentry is still
exist even though it was removed. We need to set NULL to it.

Fixes: 53e947a0 ("ASoC: soc-core: merge card resources cleanup method")
Cc: stable@vger.kernel.org # for v5.1
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      29040d1a
  7. 24 5月, 2019 1 次提交
    • G
      ASoC: dapm: Use struct_size() in krealloc() · 07597910
      由 Gustavo A. R. Silva 提交于 
      One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with
memory for some number of elements for that array. For example:

struct foo {
    int stuff;
    struct boo entry[];
};

instance = krealloc(instance, sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, use the new
struct_size() helper:

instance = krealloc(instance, struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      07597910
  9. 20 5月, 2019 1 次提交
  11. 16 5月, 2019 1 次提交
  13. 02 5月, 2019 1 次提交
  15. 02 4月, 2019 1 次提交
  17. 25 3月, 2019 2 次提交
  19. 19 2月, 2019 1 次提交
  21. 12 2月, 2019 1 次提交
  23. 07 2月, 2019 2 次提交
  25. 06 2月, 2019 1 次提交
  27. 03 2月, 2019 3 次提交
    • Z
      ASoC: dapm: Add warnings for widget overwrite when adding route · 411db2ab
      由 Zhiwei Jiang 提交于 
      Currently, in some complex cases, more than one widgets have same
name and registed from differnt dapm context, and route add from
another context too. When snd_soc_dapm_add_route, the previous
registered widget will overwritten by the latest same name widget,
will cause unexpect error. For Asoc framework we cant avoid this
situation and we cant decide which widget that wanted with route.
At least we can give users a notice.
Signed-off-by: NZhiwei Jiang <qq282012236@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      411db2ab
    • C
      ASoC: dapm: Only power up active channels from a DAI · 078a85f2
      由 Charles Keepax 提交于 
      Currently all widgets attached to a DAI link will be powered
up when the DAI is active, however this may include routes
that are not actually in use if there are unused channels
available on the DAI.

The macros for creating AIF widgets already include an entry for
slot, it is proposed to change that to channel. The effective
difference here being respresenting the logical channel index
rather than the physical slot index. The CODECs currently
using the slot entry on the DAPM_AIF macros are using it in
a manner consistent with this, the CODECs not using it just
have the field set to zero.

A variable is added to snd_soc_dapm_widget to represent
this channel index and then for each AIF widget attached to
a DAI this is compared against the number of channels on
the stream. Enabling the links for those which will be in
use. This has the nice property that the CODECs which haven't
used the slot/channel entry in the macro will function exactly
as before due to all the AIF widgets having a channel of zero
and a stream by definition having at least one channel.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      078a85f2
    • P
      ASoC: dapm: fix use-after-free issue with dailink sname · 199ed3e8
      由 Pierre-Louis Bossart 提交于 
      Commit 7620fe91 ("ASoC: topology: fix memory leak in
soc_tplg_dapm_widget_create") fixed a memory leak issue, but
additional tests and KASAN reports show a use-after-free in soc-dapm.

The widgets are created with a kmemdup operating on a template. The
"name" string is also duplicated, but the "sname" string is not. As a
result, when the template is freed after widget creation, its sname
string is still used.

Fix by explicitly duplicating the "sname" string, and freeing it when
required.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      199ed3e8
  29. 16 1月, 2019 1 次提交
    • S
      ASoC: dapm: change snprintf to scnprintf for possible overflow · e581e151
      由 Silvio Cesare 提交于 
      Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.

1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up larger than SIZE. In later
uses of snprintf, SIZE - size will result in a negative number, leading
to problems. Note that size might already be too large by using
size = snprintf before the code reaches a case of size += snprintf.

2) If size is ultimately used as a length parameter for a copy back to user
space, then it will potentially allow for a buffer overflow and information
disclosure when size is greater than SIZE. When the size is used to index
the buffer directly, we can have memory corruption. This also means when
size = snprintf... is used, it may also cause problems since size may become
large.  Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
configuration.

The solution to these issues is to use scnprintf which returns the number of
characters actually written to the buffer, so the size variable will never
exceed SIZE.
Signed-off-by: NSilvio Cesare <silvio.cesare@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NWilly Tarreau <w@1wt.eu>
Signed-off-by: NMark Brown <broonie@kernel.org>
      e581e151
  31. 19 10月, 2018 1 次提交
  33. 21 9月, 2018 1 次提交
  35. 19 9月, 2018 1 次提交
  37. 10 9月, 2018 2 次提交
  39. 07 9月, 2018 1 次提交
  41. 06 9月, 2018 5 次提交
  43. 04 9月, 2018 1 次提交
  45. 03 9月, 2018 1 次提交
    • J
      ASoC: core: Don't schedule DAPM work if already in target state · e03546dd
      由 Jon Hunter 提交于 
      When dapm_power_widgets() is called, the dapm_pre_sequence_async() and
dapm_post_sequence_async() functions are scheduled for all DAPM contexts
(apart from the card DAPM context) regardless of whether the DAPM
context is already in the desired state. The overhead of this is not
insignificant and the more DAPM contexts there are the more overhead
there is.

For example, on the Tegra124 Jetson TK1, when profiling the time taken
to execute the dapm_power_widgets() the following times were observed.

  Times for function dapm_power_widgets() are (us):
     Min 23, Ave 190, Max 434, Count 39

Here 'Count' is the number of times that dapm_power_widgets() has been
called. Please note that the above time were measured using ktime_get()
to log the time on entry and exit from dapm_power_widgets(). So it
should be noted that these times may not be purely the time take to
execute this function if it is preempted. However, after applying this
patch and measuring the time taken to execute dapm_power_widgets() again
a significant improvement is seen as shown below.

  Times for function dapm_power_widgets() are (us):
     Min 4, Ave 16, Max 82, Count 39

Therefore, optimise the dapm_power_widgets() function by only scheduling
the dapm_pre/post_sequence_async() work if the DAPM context is not in
the desired state.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      e03546dd
  47. 29 8月, 2018 2 次提交
  49. 15 8月, 2018 1 次提交
    • C
      ASoC: dapm: Fix NULL pointer deference on CODEC to CODEC DAIs · 249dc495
      由 Charles Keepax 提交于 
      Commit a655de80 ("ASoC: core: Allow topology to override
machine driver FE DAI link config.") caused soc_dai_hw_params to
be come dependent on the substream private_data being set with
a pointer to the snd_soc_pcm_runtime. Currently, CODEC to CODEC
links don't set this, which causes a NULL pointer dereference:

[<4069de54>] (soc_dai_hw_params) from
[<40694b68>] (snd_soc_dai_link_event+0x1a0/0x380)

Since the ASoC core in general assumes that the substream
private_data will be set to a pointer to the snd_soc_pcm_runtime,
update the CODEC to CODEC links to respect this.
Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      249dc495
  51. 26 7月, 2018 1 次提交
  53. 02 7月, 2018 1 次提交