1. 22 5月, 2019 1 次提交
  2. 13 5月, 2019 4 次提交
  3. 03 5月, 2019 2 次提交
  4. 20 4月, 2019 1 次提交
  5. 10 4月, 2019 1 次提交
  6. 08 4月, 2019 1 次提交
  7. 02 4月, 2019 1 次提交
  8. 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
  9. 12 3月, 2019 2 次提交
    • 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
    • R
      ASoC:soc-pcm:fix a codec fixup issue in TDM case · 570f18b6
      Rander Wang 提交于
      On HDaudio platforms, if playback is started when capture is working,
      there is no audible output.
      
      This can be root-caused to the use of the rx|tx_mask to store an HDaudio
      stream tag.
      
      If capture is stared before playback, rx_mask would be non-zero on HDaudio
      platform, then the channel number of playback, which is in the same codec
      dai with the capture, would be changed by soc_pcm_codec_params_fixup based
      on the tx_mask at first, then overwritten by this function based on rx_mask
      at last.
      
      According to the author of tx|rx_mask, tx_mask is for playback and rx_mask
      is for capture. And stream direction is checked at all other references of
      tx|rx_mask in ASoC, so here should be an error. This patch checks stream
      direction for tx|rx_mask for fixup function.
      
      This issue would affect not only HDaudio+ASoC, but also I2S codecs if the
      channel number based on rx_mask is not equal to the one for tx_mask. It could
      be rarely reproduecd because most drivers in kernel set the same channel number
      to tx|rx_mask or rx_mask is zero.
      
      Tested on all platforms using stream_tag & HDaudio and intel I2S platforms.
      Signed-off-by: NRander Wang <rander.wang@linux.intel.com>
      Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      570f18b6
  10. 03 2月, 2019 1 次提交
    • 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
  11. 16 1月, 2019 1 次提交
    • T
      ALSA: pcm: Suspend streams globally via device type PM ops · 3d21ef0b
      Takashi Iwai 提交于
      Until now we rely on each driver calling snd_pcm_suspend*() explicitly
      at its own PM handling.  However, this can be done far more easily by
      setting the PM ops to each actual snd_pcm device object.
      
      This patch adds the device_type object for PCM stream and assigns to
      each PCM stream object.  The type contains only the PM ops for system
      suspend; we don't need to deal with the resume in general.
      
      The suspend hook simply calls snd_pcm_suspend_all() for the given PCM
      streams.  This implies that the PM order is correctly put, i.e. PCM is
      suspended before the main (or codec) driver, which should be true in
      general.  If a special ordering is needed, you'd need to adjust the
      device PM order manually later.
      
      This patch introduces a new flag, snd_pcm.no_device_suspend, too.
      With this flag set, the PCM device object won't invoke
      snd_pcm_suspend_all() by itself.  This is needed for ASoC who wants to
      manage the PM call orders in its serialized way, and the flag is set
      in soc_new_pcm() as default.
      
      For the non-ASoC world, we can get rid of the manual snd_pcm_suspend
      calls.  This will be done in the later patches.
      Reviewed-by: NJaroslav Kysela <perex@perex.cz>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3d21ef0b
  12. 21 9月, 2018 5 次提交
  13. 04 9月, 2018 1 次提交
  14. 29 8月, 2018 1 次提交
    • C
      ASoC: dpcm: Properly initialise hw->rate_max · e33ffbd9
      Charles Keepax 提交于
      If the CPU DAI does not initialise rate_max, say if using
      using KNOT or CONTINUOUS, then the rate_max field will be
      initialised to 0. A value of zero in the rate_max field of
      the hardware runtime will cause the sound card to support no
      sample rates at all. Obviously this is not desired, just a
      different mechanism is being used to apply the constraints. As
      such update the setting of rate_max in dpcm_init_runtime_hw
      to be consistent with the non-DPCM cases and set rate_max to
      UINT_MAX if nothing is defined on the CPU DAI.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      e33ffbd9
  15. 01 8月, 2018 1 次提交
  16. 11 7月, 2018 2 次提交
  17. 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
  18. 02 7月, 2018 1 次提交
  19. 28 6月, 2018 3 次提交
    • J
      ASoC: dpcm: don't merge format from invalid codec dai · 4febced1
      Jerome Brunet 提交于
      When merging codec formats, dpcm_runtime_base_format() should skip
      the codecs which are not supporting the current stream direction.
      
      At the moment, if a BE link has more than one codec, and only one
      of these codecs has no capture DAI, it becomes impossible to start
      a capture stream because the merged format would be 0.
      
      Skipping invalid codec DAI solves the problem.
      
      Fixes: b073ed4e ("ASoC: soc-pcm: DPCM cares BE format")
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      4febced1
    • J
      ASoC: dpcm: extend channel merging to the backend cpu dai · 4f2bd18b
      Jerome Brunet 提交于
      Extend dpcm_merge_chan to also check backend cpu dai channels
      capabilities. Apply the same policy as soc_pcm_init_runtime_hw() for
      multicodec links and only check cpu dai in this case.
      
      Cc: Jiada Wang <jiada_wang@mentor.com>
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      4f2bd18b
    • J
      ASoC: dpcm: improve runtime update predictability · de15d7ff
      Jerome Brunet 提交于
      As it is, dpcm_runtime_update() performs the old path and new path
      update of a frontend before going on to the next frontend DAI.
      Depending the order of the FEs within the rtd list, the result of
      the update might be different.
      
      For example:
       * Frontend A connected to backend C, with a 48kHz playback
       * Frontend B connected to backend D, with a 44.1kHz playback
       * FE A appears before FE B in the rtd list of the card.
      
      If we reparent BE C to FE B (disconnecting BE D):
      * old path update of FE A will run first, and BE C will get hw_free()
        and shutdown()
      * new path update of FE B will run after and BE C, which is stopped,
        so it will be configured at 44.1kHz, as expected
      
      If we reparent BE D to FE A (disconnecting BE C):
      * new path update of FE A will run first but since BE D is still running
        at 44.1kHz, it won't be reconfigured (no call to startup() or
        hw_params())
      * old path update of FE B runs after, nothing happens
      * In this case, we end up with a BE playing at 44.1kHz a stream which is
        supposed to be played at 48Khz (too slow)
      
      To improve this situation, this patch performs all the FE old paths update
      before going on to update the new paths. With this, the result should
      no longer depend on the order of the FE within the card rtd list.
      
      Please note that there might be a small performance penalty since
      dpcm_process_paths() is called twice per stream direction.
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      de15d7ff
  20. 22 6月, 2018 1 次提交
  21. 19 6月, 2018 1 次提交
    • C
      ASoC: pcm: Tidy up open/hw_params handling · 244e2936
      Charles Keepax 提交于
      Currently, the core will continue processing open/hw_params
      component callbacks after one has failed even though it will abort
      immediately afterwards. This is unnecessary and also has the issue
      that close/hw_free will be called on the component which failed
      open/hw_params which could result in issues if the driver doesn't
      expect this behaviour.
      
      Update the core to abort processing open/hw_params when an error
      is hit and only call close/hw_free for those components that were
      successfully opened.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      244e2936
  22. 30 5月, 2018 1 次提交
  23. 29 5月, 2018 2 次提交
  24. 21 5月, 2018 1 次提交
  25. 09 5月, 2018 2 次提交
  26. 26 4月, 2018 1 次提交