1. 05 8月, 2019 3 次提交
  2. 01 8月, 2019 3 次提交
  3. 26 7月, 2019 4 次提交
  4. 24 7月, 2019 4 次提交
  5. 23 7月, 2019 1 次提交
  6. 22 7月, 2019 1 次提交
    • C
      ASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks · 8dd26dff
      Charles Keepax 提交于
      DPCM uses snd_soc_dapm_dai_get_connected_widgets to build a
      list of the widgets connected to a specific front end DAI so it
      can search through this list for available back end DAIs. The
      custom_stop_condition was added to is_connected_ep to facilitate this
      list not containing more widgets than is necessary. Doing so both
      speeds up the DPCM handling as less widgets need to be searched and
      avoids issues with CODEC to CODEC links as these would be confused
      with back end DAIs if they appeared in the list of available widgets.
      
      custom_stop_condition was implemented by aborting the graph walk
      when the condition is triggered, however there is an issue with this
      approach. Whilst walking the graph is_connected_ep should update the
      endpoints cache on each widget, if the walk is aborted the number
      of attached end points is unknown for that sub-graph. When the stop
      condition triggered, the original patch ignored the triggering widget
      and returned zero connected end points; a later patch updated this
      to set the triggering widget's cache to 1 and return that. Both of
      these approaches result in inaccurate values being stored in various
      end point caches as the values propagate back through the graph,
      which can result in later issues with widgets powering/not powering
      unexpectedly.
      
      As the original goal was to reduce the size of the widget list passed
      to the DPCM code, the simplest solution is to limit the functionality
      of the custom_stop_condition to the widget list. This means the rest
      of the graph will still be processed resulting in correct end point
      caches, but only widgets up to the stop condition will be added to the
      returned widget list.
      
      Fixes: 6742064a ("ASoC: dapm: support user-defined stop condition in dai_get_connected_widgets")
      Fixes: 5fdd022c ("ASoC: dpcm: play nice with CODEC<->CODEC links")
      Fixes: 09464974 ("ASoC: dapm: Fix to return correct path list in is_connected_ep.")
      Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20190718084333.15598-1-ckeepax@opensource.cirrus.comSigned-off-by: NMark Brown <broonie@kernel.org>
      8dd26dff
  7. 25 6月, 2019 1 次提交
  8. 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
  9. 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
  10. 20 5月, 2019 1 次提交
  11. 16 5月, 2019 1 次提交
  12. 02 5月, 2019 1 次提交
  13. 02 4月, 2019 1 次提交
  14. 25 3月, 2019 2 次提交
  15. 19 2月, 2019 1 次提交
  16. 12 2月, 2019 1 次提交
  17. 07 2月, 2019 2 次提交
  18. 06 2月, 2019 1 次提交
  19. 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
  20. 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
  21. 19 10月, 2018 1 次提交
  22. 21 9月, 2018 1 次提交
  23. 19 9月, 2018 1 次提交
  24. 10 9月, 2018 2 次提交
  25. 07 9月, 2018 1 次提交