1. 07 6月, 2019 3 次提交
  2. 13 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. 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
  5. 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
  6. 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
  7. 29 1月, 2019 1 次提交
    • P
      ASoC: add helper to change platform name for all dailinks · cb50358b
      Pierre-Louis Bossart 提交于
      To reuse the same machine drivers with Atom/SST, Skylake and SOF, we
      need to change the default platform_name (or platforms->name in the
      "modern" representation).
      
      So far, this override was done with an automatic override, which was
      broken by a set of changes for DT platforms related to deferred probe
      handling.
      
      This automatic override is actually not really needed, the machine
      driver can already receive the platform name as a platform_data
      parameter. This is used e.g. for HDaudio support where we have
      different PCI aliases used for different platforms. We can reuse the
      same mechanism and modify the machine drivers to override the dailinks
      prior to registrating the card.
      
      This will require additional work for SOF, but with this helper it'll
      be just two lines of additional code per machine driver which is
      reused, not the end of the world.
      
      This helper can be simplified when all drivers have transitioned to
      the "modern" representation of dailinks.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      cb50358b
  8. 22 1月, 2019 1 次提交
    • K
      ASoC: soc-core: add .num_platform for dai_link · 910fdcab
      Kuninori Morimoto 提交于
      Current snd_soc_dai_link is starting to use snd_soc_dai_link_component
      (= modern) style for Platform, but it is still assuming single Platform
      so far. We will need to have multi Platform support in the not far
      future.
      
      Currently only simple card is using it as sound card driver,
      and other drivers are converted to it from legacy style by
      snd_soc_init_platform().
      To avoid future problem of multi Platform support, let's add
      num_platforms before it is too late.
      
      In the same time, to make it same naming mothed, "platform" should
      be "platforms". This patch fixup it too.
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      910fdcab
  9. 19 1月, 2019 1 次提交
    • 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
  10. 15 1月, 2019 1 次提交
    • 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
  11. 26 11月, 2018 1 次提交
  12. 23 11月, 2018 1 次提交
  13. 05 11月, 2018 1 次提交
    • A
      ASoC: wm97xx: fix uninitialized regmap pointer problem · 576ce407
      Arnd Bergmann 提交于
      gcc notices that without either the ac97 bus or the pdata, we never
      initialize the regmap pointer, which leads to an uninitialized variable
      access:
      
      sound/soc/codecs/wm9712.c: In function 'wm9712_soc_probe':
      sound/soc/codecs/wm9712.c:666:2: error: 'regmap' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      Since that configuration is invalid, it's better to return an error
      here. I tried to avoid adding complexity to the conditions, and turned
      the #ifdef into a regular if(IS_ENABLED()) check for readability.
      This in turn requires moving some header file declarations out of
      an #ifdef.
      
      The same code is used in three drivers, all of which I'm changing
      the same way.
      
      Fixes: 2ed1a8e0 ("ASoC: wm9712: add ac97 new bus support")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      576ce407
  14. 30 10月, 2018 1 次提交
  15. 22 9月, 2018 1 次提交
  16. 21 9月, 2018 6 次提交
  17. 12 9月, 2018 2 次提交
  18. 06 9月, 2018 1 次提交
  19. 04 9月, 2018 2 次提交
  20. 31 8月, 2018 1 次提交
    • K
      ASoC: soc-core: use snd_soc_dai_link_component for platform · daecf46e
      Kuninori Morimoto 提交于
      Current struct snd_soc_dai_link is supporting multicodec,
      and it is supporting legacy style of
      	codec_name
      	codec_of_node
      	code_dai_name
      This is handled as single entry of multicodec.
      
      We don't have multicpu support yet, but in the future we will.
      In such case, we can use snd_soc_dai_link_component for both
      cpu/codec. Then the code will be more simple and readble.
      
      As next step, we want to use it for platform, too.
      This patch adds snd_soc_dai_link_component style for platform.
      We might have multiplatform support in the future, but we
      don't know yet. To avoid un-known issue / complex code,
      this patch supports just single-platform as 1st step.
      
      If we could use snd_soc_dai_link_component for all CPU/Codec/Platform,
      we will switch to new style, and remove legacy code.
      This is prepare for it.
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      daecf46e
  21. 03 8月, 2018 1 次提交
  22. 21 7月, 2018 1 次提交
  23. 18 7月, 2018 1 次提交
  24. 11 7月, 2018 1 次提交
  25. 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
  26. 02 7月, 2018 1 次提交
  27. 22 6月, 2018 1 次提交
  28. 30 5月, 2018 1 次提交
  29. 09 5月, 2018 3 次提交