Skip to content

L
linux
Switch branch/tag
  1. 14 Jul, 2024 1 commit
  3. 11 Jul, 2024 1 commit
  5. 09 Jul, 2024 1 commit
  7. 08 Jul, 2024 1 commit
  9. 06 Jul, 2024 1 commit
  11. 05 Jul, 2024 1 commit
  13. 04 Jul, 2024 3 commits
  15. 02 Jul, 2024 1 commit
  17. 01 Jul, 2024 4 commits
  19. 26 Jun, 2024 6 commits
  21. 25 Jun, 2024 4 commits
  23. 24 Jun, 2024 1 commit
    • Chen-Yu Tsai's avatar
      ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link · 282a4482
      Chen-Yu Tsai authored 
      Commit e70b8dd2 ("ASoC: mediatek: mt8195: Remove afe-dai component
and rework codec link") removed the codec entry for the ETDM1_OUT_BE
dai link entirely instead of replacing it with COMP_EMPTY(). This worked
by accident as the remaining COMP_EMPTY() platform entry became the codec
entry, and the platform entry became completely empty, effectively the
same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn't do anything
for platform entries.

This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe()
in sound/soc/mediatek/common/mtk-soundcard-driver.c:

	for_each_card_prelinks(card, i, dai_link) {
		if (adsp_node && !strncmp(dai_link->name, "AFE_SOF", strlen("AFE_SOF")))
			dai_link->platforms->of_node = adsp_node;
		else if (!dai_link->platforms->name && !dai_link->platforms->of_node)
			dai_link->platforms->of_node = platform_node;
	}

where the code expects the platforms array to have space for at least one entry.

Add an COMP_EMPTY() entry so that dai_link->platforms has space.

Fixes: e70b8dd2 ("ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link")
Signed-off-by: default avatarChen-Yu Tsai <wenst@chromium.org>
Reviewed-by: default avatarAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20240624061257.3115467-1-wenst@chromium.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      282a4482
  25. 21 Jun, 2024 2 commits
  27. 20 Jun, 2024 2 commits
  29. 19 Jun, 2024 3 commits
  31. 18 Jun, 2024 3 commits
  33. 16 Jun, 2024 2 commits
  35. 14 Jun, 2024 3 commits
    • Srinivas Kandagatla's avatar
      ASoC: q6apm-lpass-dai: close graph on prepare errors · be1fae62
      Srinivas Kandagatla authored 
      There is an issue around with error handling and graph management with
the exising code, none of the error paths close the graph, which result in
leaving the loaded graph in dsp, however the driver thinks otherwise.

This can have a nasty side effect specially when we try to load the same
graph to dsp, dsp returns error which leaves the board with no sound and
requires restart.

Fix this by properly closing the graph when we hit errors between
open and close.

Fixes: 30ad723b ("ASoC: qdsp6: audioreach: add q6apm lpass dai support")
Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # X13s
Link: https://lore.kernel.org/r/20240613-q6apm-fixes-v1-1-d88953675ab3@linaro.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      be1fae62
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Disconnect ASP1 TX sources when ASP1 DAI is hooked up · 8af49868
      Richard Fitzgerald authored 
      If the ASP1 DAI is hooked up by the machine driver the ASP TX mixer
sources should be initialized to disconnected. There aren't currently
any available products using the ASP so this doesn't affect any
existing systems.

The cs35l56 does not have any fixed default for the mixer source
registers. When the cs35l56 boots, its firmware patches these registers
to setup a system-specific routing; this is so that Windows can use
generic SDCA drivers instead of needing knowledge of chip-specific
registers. The setup varies between end-products, which each have
customized firmware, and so the default register state varies between
end-products. It can also change if the firmware on an end-product is
upgraded - for example if a change was needed to the routing for Windows
use-cases. It must be emphasized that the settings applied by the
firmware are not internal magic tuning; they are statically implementing
use-case setup that on Linux would be done via ALSA controls.

The driver is currently syncing the mixer controls with whatever
initial state the firmware wrote to the registers, so that they report
the actual audio routing. But if the ASP DAI is hooked up this can create
a powered-up DAPM graph without anything intentionally setting up a path.
This can lead to parts of the audio system powering up unexpectedly.

For example when cs35l56 is connected to cs42l43 using a codec-codec link,
this can create a complete DAPM graph which then powers-up cs42l43. But
the cs42l43 can only be clocked from its SoundWire bus so this causes a
bunch of errors in the kernel log where cs42l43 is unexpectedly powered-up
without a clock.

If the host is taking ownership of the ASP (either directly or as a
codec-to-codec link) there is no need to keep the mixer settings that the
firmware wrote. The driver has ALSA controls for setting these using
standard Linux mechanisms. So if the machine driver hooks up the ASP the
ASP mixers are initialized to "None" (no input). This prevents unintended
DAPM-graph power-ups, and means the initial state of the mixers is
always going to be None.

Since the initial state of the mixers can vary from system to system and
potentially between firmware upgrades, no use-case manager can currently
assume that cs35l56 has a known initial state. The firmware could just as
easily default them to "None" as to any input source. So defaulting them
to "None" in the driver is not increasing the entropy of the system.
Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20240613132527.46537-1-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      8af49868
    • Simon Trimmer's avatar
      ALSA: hda: tas2781: Component should be unbound before deconstruction · d832b5a0
      Simon Trimmer authored 
      The interface associated with the hda_component should be deactivated
before the driver is deconstructed during removal.

Fixes: 4e7914eb ("ALSA: hda/tas2781: remove sound controls in unbind")
Signed-off-by: default avatarSimon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240613133713.75550-4-simont@opensource.cirrus.com
      d832b5a0
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7