1. 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
  2. 24 5月, 2019 1 次提交
  3. 08 4月, 2019 1 次提交
    • R
      ASoC: core: conditionally increase module refcount on component open · b4ed6b51
      Ranjani Sridharan 提交于
      Recently, for Intel platforms the "ignore_module_refcount" field
      was introduced for the component driver. In order to avoid a
      deadlock preventing the PCI modules from being removed
      even when the card was idle, the refcounts were not incremented
      for the device driver module during component probe.
      
      However, this change introduced a nasty side effect:
      the device driver module can be unloaded while a pcm stream is open.
      
      This patch proposes to change the field to be renamed as
      "module_get_upon_open". When this field is set, the module
      refcount should be incremented on pcm open amd decremented
      upon pcm close. This will enable modules to be removed
      when no PCM playback/capture happens and prevent removal
      when the component is actually in use.
      
      Also, align with the skylake component driver with the new name.
      
      Fixes: b450b878('ASoC: core: don't increase component module refcount
                       unconditionally'
      Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      b4ed6b51
  4. 05 4月, 2019 1 次提交
    • R
      ASoC: core: remove link components before cleaning up card resources · f96fb7d1
      Ranjani Sridharan 提交于
      When the card is registered by the machine driver,
      dai link components are probed after the snd_card is
      created. This is done in snd_soc_bind_card() which calls
      snd_soc_instantiate_card() to first create the snd_card
      and then probes the link components by calling
      soc_probe_link_components(). The snd_card is used by the
      component driver to add the kcontrols associated
      with dapm widgets to the card.
      
      When the machine driver is unregistered, the snd_card
      is freed when the card resources are cleaned up.
      But the snd_card needs to be valid while unloading the
      topology dapm widgets in order to remove the kcontrols
      from the card.
      
      Since, unloading topology is done when the component
      driver is removed, the link components should be removed
      in snd_soc_unbind_card(). This will ensure that the kcontrols
      are removed before the card resources are cleaned up and
      the snd_card itself is freed.
      Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      f96fb7d1
  5. 02 4月, 2019 1 次提交
  6. 18 3月, 2019 1 次提交
    • K
      ASoC: dpcm: prevent snd_soc_dpcm use after free · bbfaa7d3
      KaiChieh Chuang 提交于
      The dpcm get from fe_clients/be_clients
      may be free before use
      
      Add a spin lock at snd_soc_card level,
      to protect the dpcm instance.
      The lock may be used in atomic context, so use spin lock.
      
      possible race condition between
      void dpcm_be_disconnect(
      	...
      	list_del(&dpcm->list_be);
      	list_del(&dpcm->list_fe);
      	kfree(dpcm);
      	...
      
      and
      	for_each_dpcm_fe()
      	for_each_dpcm_be*()
      
      race condition example
      Thread 1:
          snd_soc_dapm_mixer_update_power()
              -> soc_dpcm_runtime_update()
                  -> dpcm_be_disconnect()
                      -> kfree(dpcm);
      Thread 2:
          dpcm_fe_dai_trigger()
              -> dpcm_be_dai_trigger()
                  -> snd_soc_dpcm_can_be_free_stop()
                      -> if (dpcm->fe == fe)
      
      Excpetion Scenario:
      	two FE link to same BE
      	FE1 -> BE
      	FE2 ->
      
      	Thread 1: switch of mixer between FE2 -> BE
      	Thread 2: pcm_stop FE1
      
      Exception:
      
      Unable to handle kernel paging request at virtual address dead0000000000e0
      
      pc=<> [<ffffff8960e2cd10>] dpcm_be_dai_trigger+0x29c/0x47c
      	sound/soc/soc-pcm.c:3226
      		if (dpcm->fe == fe)
      lr=<> [<ffffff8960e2f694>] dpcm_fe_dai_do_trigger+0x94/0x26c
      
      Backtrace:
      [<ffffff89602dba80>] notify_die+0x68/0xb8
      [<ffffff896028c7dc>] die+0x118/0x2a8
      [<ffffff89602a2f84>] __do_kernel_fault+0x13c/0x14c
      [<ffffff89602a27f4>] do_translation_fault+0x64/0xa0
      [<ffffff8960280cf8>] do_mem_abort+0x4c/0xd0
      [<ffffff8960282ad0>] el1_da+0x24/0x40
      [<ffffff8960e2cd10>] dpcm_be_dai_trigger+0x29c/0x47c
      [<ffffff8960e2f694>] dpcm_fe_dai_do_trigger+0x94/0x26c
      [<ffffff8960e2edec>] dpcm_fe_dai_trigger+0x3c/0x44
      [<ffffff8960de5588>] snd_pcm_do_stop+0x50/0x5c
      [<ffffff8960dded24>] snd_pcm_action+0xb4/0x13c
      [<ffffff8960ddfdb4>] snd_pcm_drop+0xa0/0x128
      [<ffffff8960de69bc>] snd_pcm_common_ioctl+0x9d8/0x30f0
      [<ffffff8960de1cac>] snd_pcm_ioctl_compat+0x29c/0x2f14
      [<ffffff89604c9d60>] compat_SyS_ioctl+0x128/0x244
      [<ffffff8960283740>] el0_svc_naked+0x34/0x38
      [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: NKaiChieh Chuang <kaichieh.chuang@mediatek.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      bbfaa7d3
  7. 12 3月, 2019 1 次提交
    • K
      ASoC: dpcm: prevent snd_soc_dpcm use after free · a9764869
      KaiChieh Chuang 提交于
      The dpcm get from fe_clients/be_clients
      may be free before use
      
      Add a spin lock at snd_soc_card level,
      to protect the dpcm instance.
      The lock may be used in atomic context, so use spin lock.
      
      Use irq spin lock version,
      since the lock may be used in interrupts.
      
      possible race condition between
      void dpcm_be_disconnect(
      	...
      	list_del(&dpcm->list_be);
      	list_del(&dpcm->list_fe);
      	kfree(dpcm);
      	...
      
      and
      	for_each_dpcm_fe()
      	for_each_dpcm_be*()
      
      race condition example
      Thread 1:
          snd_soc_dapm_mixer_update_power()
              -> soc_dpcm_runtime_update()
                  -> dpcm_be_disconnect()
                      -> kfree(dpcm);
      Thread 2:
          dpcm_fe_dai_trigger()
              -> dpcm_be_dai_trigger()
                  -> snd_soc_dpcm_can_be_free_stop()
                      -> if (dpcm->fe == fe)
      
      Excpetion Scenario:
      	two FE link to same BE
      	FE1 -> BE
      	FE2 ->
      
      	Thread 1: switch of mixer between FE2 -> BE
      	Thread 2: pcm_stop FE1
      
      Exception:
      
      Unable to handle kernel paging request at virtual address dead0000000000e0
      
      pc=<> [<ffffff8960e2cd10>] dpcm_be_dai_trigger+0x29c/0x47c
      	sound/soc/soc-pcm.c:3226
      		if (dpcm->fe == fe)
      lr=<> [<ffffff8960e2f694>] dpcm_fe_dai_do_trigger+0x94/0x26c
      
      Backtrace:
      [<ffffff89602dba80>] notify_die+0x68/0xb8
      [<ffffff896028c7dc>] die+0x118/0x2a8
      [<ffffff89602a2f84>] __do_kernel_fault+0x13c/0x14c
      [<ffffff89602a27f4>] do_translation_fault+0x64/0xa0
      [<ffffff8960280cf8>] do_mem_abort+0x4c/0xd0
      [<ffffff8960282ad0>] el1_da+0x24/0x40
      [<ffffff8960e2cd10>] dpcm_be_dai_trigger+0x29c/0x47c
      [<ffffff8960e2f694>] dpcm_fe_dai_do_trigger+0x94/0x26c
      [<ffffff8960e2edec>] dpcm_fe_dai_trigger+0x3c/0x44
      [<ffffff8960de5588>] snd_pcm_do_stop+0x50/0x5c
      [<ffffff8960dded24>] snd_pcm_action+0xb4/0x13c
      [<ffffff8960ddfdb4>] snd_pcm_drop+0xa0/0x128
      [<ffffff8960de69bc>] snd_pcm_common_ioctl+0x9d8/0x30f0
      [<ffffff8960de1cac>] snd_pcm_ioctl_compat+0x29c/0x2f14
      [<ffffff89604c9d60>] compat_SyS_ioctl+0x128/0x244
      [<ffffff8960283740>] el0_svc_naked+0x34/0x38
      [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: NKaiChieh Chuang <kaichieh.chuang@mediatek.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      a9764869
  8. 04 3月, 2019 1 次提交
    • J
      ASoC: soc-core: Fix probe deferral following prelink failure · c342febc
      Jonathan Hunter 提交于
      Commit 78a24e10 ("ASoC: soc-core: clear platform pointers on error")
      re-worked the clean-up of any platform pointers that may have been
      initialised by the function snd_soc_init_platform(). This commit missed
      one error path where if any of the prelinks for a soundcard failed to
      initialise, then these platform pointers would not be cleaned-up. This
      then prevents the soundcard from being initialised following a probe
      deferral when any of the soundcard prelinks cannot be found.
      
      Fix this by ensuring that soc_cleanup_platform() is called when
      initialising the soundcard prelinks fails.
      
      Fixes: 78a24e10 ("ASoC: soc-core: clear platform pointers on error")
      Signed-off-by: NJonathan Hunter <jonathanh@nvidia.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      c342febc
  9. 09 2月, 2019 1 次提交
    • P
      ASoC: core: don't increase component module refcount unconditionally · b450b878
      Pierre-Louis Bossart 提交于
      The ASoC core has for the longest time increased the module reference
      counts, even before the transition to the component model. This is
      probably fine on most platforms, but it introduces a deadlock case on
      Intel devices with the Skylake and SOF drivers which cannot be removed
      due to their reference counts being modified by the core.
      
      In these 2 cases, the PCI or ACPI driver .probe creates a platform
      device to let the machine driver .probe register the audio
      card. Conversely the PCI or ACPI driver .remove will unregister the
      platform device which results in the card being removed by the machine
      driver .remove.
      
      With ascii art, this can be represented as
      
      modprobe
      snd_soc_skl/
      soc-pci-dev/sof-acpci-dev  ----------> pci/acpi probe
             ^                                    |
             |                     ---------------|
             |                    |               |
             |                    V               V
          increase            register        register machine
          refcount            component       platform_device
             ^                                    |
             |                                    |
             |                                    V
          component <----   register card  <---- probe
          probe
      
      The issue is that by playing with the component's module reference
      counts during the card registration, it's no longer possible to remove
      the module which controls the component. This can be shown, e.g. with
      the following error:
      
      root@plb-XPS-13-9350:~# lsmod | grep snd_soc_skl
      snd_soc_skl           110592  1
      
      root@plb-XPS-13-9350:~# rmmod snd_soc_skl
      rmmod: ERROR: Module snd_soc_skl is in use
      
      Increasing the reference count during the component probe is not
      useful. If the PCI/ACPI module is removed, the card will be removed
      anyway.
      
      To avoid breaking existing platforms and allowing Intel platforms to
      safely deal with module load/unload cases, this patch introduces a
      flag which needs to be set during the component initialization. This
      is a strictly opt-in capability that should only be used when the
      handling of the component module does not require a reference count
      increase to prevent removal during use.
      
      Note that this solution is not directly applicable to the legacy
      Atom/SST driver, which uses a different device hierarchy. There are
      however additional refcount issues which prevent the ACPI driver from
      being removed. This is a different issue which would need a different
      patch.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      b450b878
  10. 04 2月, 2019 1 次提交
    • C
      ASoC: soc-core: clear platform pointers on error · 78a24e10
      Curtis Malainey 提交于
      Originally snd_soc_init_platform was not cleaning up its pointers, this
      was fixed to always reallocate dynamic memory but created a memory leak
      when snd_soc_init_platform was called multiple times during the same
      probe attempt and also threw away any changes made to the struct between
      calls. In order to avoid reallocating memory that is still valid, the
      behaviour will be changed to clear the dynamically set pointers on a
      probe error and a unregister event and snd_soc_init_platform will go
      back to its original behaviour of only allocating null pointers so it will
      stop throwing away valid changes.
      Signed-off-by: NCurtis Malainey <cujomalainey@chromium.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      78a24e10
  11. 03 2月, 2019 1 次提交
  12. 28 1月, 2019 1 次提交
  13. 26 1月, 2019 1 次提交
  14. 23 1月, 2019 1 次提交
  15. 22 1月, 2019 6 次提交
  16. 19 1月, 2019 2 次提交
    • K
      ASoC: soc.h: add explanation of legacy/modern style of dai_link · 62bc79d3
      Kuninori Morimoto 提交于
      Current ALSA SoC is assuming 1 CPU 1 Platform (= DMA) style system.
      Because of this background, it is directly using
      xxx_name / xxx_of_node / xxx_dai_name on dai_link.
      Let's call it as legacy style here.
      
      More complex style system like multi CPU multi Platform (= DMA) will
      coming. To supporting it, we can use snd_soc_dai_link_component on
      dai_link. Let's call it as modern style here.
      But current ALSA SoC can't support it so far. Thus, we need to have
      multi CPU / multi Codec / multi Platform style in the future on ALSA SoC.
      
      Currently we already have multi Codec support. Platform is starting to
      use modern style on dai_link, but still style only. Multi Platform is
      not yet implemented. And we still don't have multi CPU support on ALSA
      SoC, and not have modern style either.
      
      Currently, if driver is using legacy style Codec/Platform, it will be
      converted to modern style on soc-core. This means, we are using glue code
      for legacy vs modern style so far on ALSA SoC.
      We can fully switch to modern style on all drivers if ALSA SoC supported
      modern style for CPU, and then, legacy style code will be removed from
      ALSA SoC.
      Untile then, we need to keep both legacy/modern style and its glue code.
      This patch adds such future plan and background on soc.h
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      62bc79d3
    • S
      ASoC: soc-core: remove error due to probe deferral · 7c7e2d6a
      Stefan Agner 提交于
      Deferred probes shouldn't cause error messages in the boot log, so
      change the dev_err() to the more harmless dev_info().
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      7c7e2d6a
  17. 16 1月, 2019 1 次提交
  18. 15 1月, 2019 2 次提交
    • M
      ASoC: core: Make snd_soc_find_component() more robust · 5a7b2aab
      Mark Brown 提交于
      There are some use cases where you're checking for a lot of things on a
      card and it makes sense that you might end up trying to call
      snd_soc_find_component() without either a name or an of_node.  Currently
      in that case we try to dereference the name and crash but it's more
      useful to allow the caller to just treat that as a case where we don't
      find anything, that error handling will already exist.
      
      Inspired by a patch from Ajit Pandey fixing some callers.
      
      Fixes: 8780cf11 ("ASoC: soc-core: defer card probe until all component is added to list")
      Reported-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      5a7b2aab
    • C
      ASoC: soc-core: fix init platform memory handling · 09ac6a81
      Curtis Malainey 提交于
      snd_soc_init_platform initializes pointers to snd_soc_dai_link which is
      statically allocated and it does this by devm_kzalloc. In the event of
      an EPROBE_DEFER the memory will be freed and the pointers are left
      dangling. snd_soc_init_platform sees the dangling pointers and assumes
      they are pointing to initialized memory and does not reallocate them on
      the second probe attempt which results in a use after free bug since
      devm has freed the memory from the first probe attempt.
      
      Since the intention for snd_soc_dai_link->platform is that it can be set
      statically by the machine driver we need to respect the pointer in the
      event we did not set it but still catch dangling pointers. The solution
      is to add a flag to track whether the pointer was dynamically allocated
      or not.
      Signed-off-by: NCurtis Malainey <cujomalainey@chromium.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      09ac6a81
  19. 10 1月, 2019 1 次提交
  20. 09 1月, 2019 1 次提交
  21. 14 12月, 2018 1 次提交
    • R
      ASoC: core: Invoke pcm_new() for all DAI-link · de17f14e
      Rohit kumar 提交于
      Remove no_pcm check to invoke pcm_new() for backend dai-links
      too. This fixes crash in hdmi codec driver during hdmi_codec_startup()
      while accessing chmap_info struct. chmap_info struct memory is
      allocated in pcm_new() of hdmi codec driver which is not invoked
      in case of DPCM when hdmi codec driver is part of backend dai-link.
      
      Below is the crash stack:
      
      [   61.635493] Unable to handle kernel NULL pointer dereference at virtual address 00000018
      ..
      [   61.666696]   CM = 0, WnR = 1
      [   61.669778] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffc0d6633000
      [   61.676526] [0000000000000018] *pgd=0000000153fc8003, *pud=0000000153fc8003, *pmd=0000000000000000
      [   61.685793] Internal error: Oops: 96000046 [#1] PREEMPT SMP
      [   61.722955] CPU: 7 PID: 2238 Comm: aplay Not tainted 4.14.72 #21
      ..
      [   61.740269] PC is at hdmi_codec_startup+0x124/0x164
      [   61.745308] LR is at hdmi_codec_startup+0xe4/0x164
      Signed-off-by: NRohit kumar <rohitkr@codeaurora.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      de17f14e
  22. 23 11月, 2018 1 次提交
  23. 15 11月, 2018 1 次提交
    • T
      ASoC: dapm: Recalculate audio map forcely when card instantiated · 882eab6c
      Tzung-Bi Shih 提交于
      Audio map are possible in wrong state before card->instantiated has
      been set to true.  Imaging the following examples:
      
      time 1: at the beginning
      
        in:-1    in:-1    in:-1    in:-1
       out:-1   out:-1   out:-1   out:-1
       SIGGEN        A        B      Spk
      
      time 2: after someone called snd_soc_dapm_new_widgets()
      (e.g. create_fill_widget_route_map() in sound/soc/codecs/hdac_hdmi.c)
      
         in:1     in:0     in:0     in:0
        out:0    out:0    out:0    out:1
       SIGGEN        A        B      Spk
      
      time 3: routes added
      
         in:1     in:0     in:0     in:0
        out:0    out:0    out:0    out:1
       SIGGEN -----> A -----> B ---> Spk
      
      In the end, the path should be powered on but it did not.  At time 3,
      "in" of SIGGEN and "out" of Spk did not propagate to their neighbors
      because snd_soc_dapm_add_path() will not invalidate the paths if
      the card has not instantiated (i.e. card->instantiated is false).
      To correct the state of audio map, recalculate the whole map forcely.
      Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      882eab6c
  24. 19 10月, 2018 1 次提交
  25. 22 9月, 2018 2 次提交
  26. 21 9月, 2018 5 次提交
  27. 18 9月, 2018 2 次提交