If sclk is not provided the driver falls back to using bclk and prints
an info message in the system log. Under normal operations the message
is repeated many times:
[ 17.929576] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 17.949172] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 17.953029] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 17.965059] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 82.592980] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 82.866293] pcm512x 0-004c: No SCLK, using BCLK: -2
Switch from dev_info to dev_info_once to reduce log noise.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Link: https://patch.msgid.link/20260625122811.4056274-1-christianshewitt@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The previous TAS2781 address is overwritten during calibration,
so switching to the TAS2563 address is required.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
Link: https://patch.msgid.link/20260625102815.20043-1-baojun.xu@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If device_link_add() fails in snd_soc_bind_card() just skip that
driver pair and carry on.
This means that ASoC must now keep track of which components it was
able to device_link to the card->dev. The new card_device_link member
of struct snd_soc_component is non-NULL if a device_link exists.
The intent of the device link is to ensure that the machine driver
system-suspends before the component drivers, to prevent ASoC
suspend attempting to reconfigure a driver that has already suspended.
It isn't possible to create this device link if the machine driver is
a parent of the component driver or already has a device_link in the
opposite direction. In this case skip the link. A warn is placed in
kernel log since this might indicate a genuine design problem with
those two drivers (this can be downgraded to dbg in future when
people are happy that all these special drivers correctly handle their
reversed shutdown order).
Fixes: 0f54ce994b ("ASoC: soc-core: Create device_link to ensure correct suspend order")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/linux-sound/61bd38e7-5eb9-4448-a93f-afa2ccbd1c9d@opensource.cirrus.com/T/#m496fe5a11b0a3649afd2e85da5e1cea82bb16d8a
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260623135821.4125543-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently that header is only included via:
<sound/dmaengine_pcm.h> ->
<sound/soc.h> ->
<linux/platform_device.h>
which doesn't look reliable, still more in the presence of the comment:
/* For the current users of sound/soc.h to avoid build issues */
in <sound/soc.h>.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260624083708.254517-2-u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In linux-firmware commit from 2026-05-19 `2f90f4fe5c67f51a8410907a...`
`ASoC: tas2783: Add Firmware files for tas2783A projects` by Baojun Xu
138 new firmware files for tas2783 were added, none of which are loaded
by the kernel. Kernel expects files to be named with the following
convention: "%04X-%1X-%1X.bin". However the added firmware files follow
"-0x%1X.bin" naming instead with `0x` hex prefix, which fails to load
resulting in following dmesg log:
slave-tas2783 sdw:0:1:0102:0000:01:8: Direct firmware load for 1714-1-8.bin failed with error -2
slave-tas2783 sdw:0:1:0102:0000:01:8: Failed to read fw binary 1714-1-8.bin
slave-tas2783 sdw:0:1:0102:0000:01:b: Direct firmware load for 1714-1-B.bin failed with error -2
slave-tas2783 sdw:0:1:0102:0000:01:b: Failed to read fw binary 1714-1-B.bin
slave-tas2783 sdw:0:1:0102:0000:01:8: error playback without fw download
slave-tas2783 sdw:0:1:0102:0000:01:8: ASoC error (-22): at snd_soc_dai_hw_params() on tas2783-codec
This same commit removes all 22 symlinks from WHENCE, that used naming
without the '0x' prefix to only 6 prevoiusly existing .bin files.
This patch adds `0x` prefix explicitly to the generated firmware name
allowing file to successfully load. In case prefixed firmware is missing
due to out of date linux-firmware, we set the fallback flag and attempt
to load firmware again based on the old file names.
This prefix change results in functioning firmware loading on ASUS
ProArt PX13 HN7306EAC, which uses 1714-1-0x8.bin and 1714-1-0xB.bin
firmware files.
Tested on top of 7.1 and next-20260619 with SND_SOC_AMD_ACP7X set to no.
Signed-off-by: Bartosz Juraszewski <bjuraszewski@gmail.com>
Link: https://patch.msgid.link/20260622182733.23947-1-bjuraszewski@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ge_put_enum_double() passes the user-supplied enumeration index
item[0] to snd_soc_enum_item_to_val() without checking it against the
number of items in the enum:
ret = snd_soc_enum_item_to_val(e, item[0]);
snd_soc_enum_item_to_val() indexes the heap-allocated e->values[] array
with that index (e->values is set from a devm_kcalloc() of e->items
entries), so a control write with an out-of-range item[0] reads past the
end of the values buffer. The bounds check in
snd_soc_dapm_put_enum_double() only runs afterwards, so it does not
prevent the read here.
Reject an out-of-range item before using it, matching the other enum put
handlers.
This issue was pointed out by the Sashiko AI review bot while reviewing a
related enum-validation series:
https://lore.kernel.org/all/20260609125735.CEB651F00893@smtp.kernel.org/
Fixes: 812ff1baa7 ("ASoC: SDCA: Limit values user can write to Selected Mode")
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260623110526.813217-1-sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As the core no longer calls this debug helper add it back to the drivers
that originally called it.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260623101814.24044-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As the core no longer calls this debug helper add it back to the drivers
that originally called it.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260623101814.24044-5-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As the core no longer calls this debug helper add it back to the drivers
that originally called it.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260623101814.24044-4-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As the core no longer calls this debug helper add it back to the drivers
that originally called it.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260623101814.24044-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As SoundWire devices tend to enumerate on the bus after probe, drivers
frequently need to wait for the device to initialise from common driver
code. The common system is to split drivers into a core module and then
a module for each communication bus. These two facts tend to cause
Kconfig issues, the issue tends to be when SOUNDWIRE=m and DRIVER_I2C=y,
this usually selects DRIVER=y. The driver code then wants to call
sdw_slave_wait_for_init(), but this results in calling a module function
from built in code. A depends on SOUNDWIRE | !SOUNDWIRE could be added to
the end driver but this seems slightly off as it adds a lot of counter
intuitive depends.
A simpler solution is to make sdw_slave_wait_for_init() a static inline
function. As part of doing this add a check for the slave device being
NULL acknowledging that this is likely called from code that is shared
between control buses. It does require dropping the call to
sdw_show_ping_status() but this can be added back in end drivers that
used it originally.
Currently this is causing rand config issues on RT5682 and will soon
also cause similar problems on cs42l43.
Acked-by: Vinod Koul <vkoul@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260623101814.24044-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Sometimes the DAI format must be specified in the audio-graph-card2
device tree, so emitting a warning can be misleading. Revert back to
emitting no warning.
A few examples where automatic format selection might not be applicable:
- For DPCM, where the other side of the DAI link is not apparent, no
proper selection can actually be made. This can lead to disagreeing
formats.
- Due to hardware peculiarities, some ostensibly supported formats might
not work in practice.
In either case, the only correct solution is for the sound card to set
the format
Link: https://lore.kernel.org/all/87ik7s36k2.wl-kuninori.morimoto.gx@renesas.com/
Signed-off-by: Alvin Šipraga <alvin.sipraga@analog.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/20260617145508.327213-1-alvin@pqrs.dk
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adjusts several default settings to ensure
the speaker protection function can be enabled safely.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20260615091012.718168-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The datasheet documents that when the PLL is disabled and dual-rate mode
is enabled, only Q values {4, 8, 9, 12, 16} are valid for the CLKDIV
bypass path; all other Q values produce invalid bitclock output.
The existing loop iterates Q from 2 to 17 without this restriction,
causing silent audio failure when an out-of-spec Q is picked.
Restrict the Q search to the allowed set in dual-rate mode.
Fixes: 4f9c16ccfa ("[ALSA] soc - tlv320aic3x - revisit clock setup")
Suggested-by: Mir Jeffres <m-jeffres@ti.com>
Signed-off-by: Sen Wang <sen@ti.com>
Link: https://patch.msgid.link/20260616233322.873081-1-sen@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit f7fe9f7073 ("ASoC: rockchip: rockchip_sai: Use
guard() for spin locks").
This is very noisy pointless churn that was not tested by the submitter,
nor was it addressed to the driver's maintainer. It mixes unrelated
whitespace changes (eliminating the blank line between the includes -
why?) with hard to review diffs that add a whole indentation level to
the function for no benefit, while also not following kernel code style
by doing stuff like "ret == 0".
The driver is better off without these changes, and they're not worth
the time to validate whether they really do make no functional changes.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260617-sai-revert-v1-1-e46adda2213b@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When q6apm_free_fragments() is called it frees rx_data.buf/tx_data.buf
and sets them to NULL under graph->lock. A late DSP buffer-done response
can race with this: graph_callback() passes the !graph->ar_graph guard
(not yet NULL), acquires the lock, but then dereferences a now-NULL buf
pointer to read buf[token].phys, crashing at virtual address 0x10.
Add a NULL check for buf inside the mutex-protected section in both the
write-done (DATA_CMD_RSP_WR_SH_MEM_EP_DATA_BUFFER_DONE_V2) and
read-done (DATA_CMD_RSP_RD_SH_MEM_EP_DATA_BUFFER_V2) handlers and bail
out cleanly if buffers have already been freed.
This problem is only shown up recently while apr bus was updated to
process the commands per service rather from single global queue.
Fixes: 5477518b8a ("ASoC: qdsp6: audioreach: add q6apm support")
Cc: Stable@vger.kernel.org
Assisted-by: Claude:claude-4-6-sonnet
Reported-by: Val Packett <val@packett.cool>
Closes: https://lore.kernel.org/all/133ced18-1aa9-475d-80d8-6120678bdde4@packett.cool/
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260616170257.9381-1-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
"realtek,gpio-config" is described as six 8-bit GPIO configuration
values, and the RT5677 driver stores and reads those values as bytes.
The binding incorrectly documented the property as a uint32 array.
Document "realtek,gpio-config" as a uint8-array so the generated
schema matches the hardware definition and the existing driver helper.
Assisted-by: Codex:gpt-5-5
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260612214911.1883234-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
Current ASoC supports snd_soc_daifmt_parse_format() which can specify DAI
format by "dai-format" property from DT.
But strictly speaking, it is SW settings, so doesn't match to DT's policy.
Current ASoC is supporting auto format select via
snd_soc_dai_ops :: .auto_selectable_formats.
But the user is very few today.
DT doesn't need to specify the DAI format via "dai-format", if both CPU
and Codec drivers were supporting .auto_selectable_formats. It will be
automatically selected from .auto_selectable_formats.
But, I noticed that current auto format select method can't handle all cases.
For example, current .auto_selectable_formats is like below
static u64 xxx_auto_formats[] = {
(A) /* First Priority */
SND_SOC_POSSIBLE_DAIFMT_I2S |
SND_SOC_POSSIBLE_DAIFMT_LEFT_J |
SND_SOC_POSSIBLE_DAIFMT_NB_NF |
SND_SOC_POSSIBLE_DAIFMT_NB_IF | (x)
SND_SOC_POSSIBLE_DAIFMT_IB_NF |
SND_SOC_POSSIBLE_DAIFMT_IB_IF, (x)
/* Second Priority */
(B) SND_SOC_POSSIBLE_DAIFMT_DSP_A | (y)
SND_SOC_POSSIBLE_DAIFMT_DSP_B, (y)
};
It try to find DAI format from (A) first, and next it will use (A | B).
But it can't handle the format if some format were independent.
For example, DSP_x (y) can't use with xB_IF (x), etc.
So, I would like to update the method. New method doesn't use OR.
It try to find DAI format from (a), next it will use (b).
static u64 xxx_auto_formats[] = {
(a) /* First Priority */
SND_SOC_POSSIBLE_DAIFMT_I2S |
SND_SOC_POSSIBLE_DAIFMT_LEFT_J |
SND_SOC_POSSIBLE_DAIFMT_NB_NF |
SND_SOC_POSSIBLE_DAIFMT_NB_IF |
SND_SOC_POSSIBLE_DAIFMT_IB_NF |
SND_SOC_POSSIBLE_DAIFMT_IB_IF,
/* Second Priority */
(b) SND_SOC_POSSIBLE_DAIFMT_DSP_A |
SND_SOC_POSSIBLE_DAIFMT_DSP_B |
SND_SOC_POSSIBLE_DAIFMT_NB_NF |
SND_SOC_POSSIBLE_DAIFMT_IB_NF,
};
Switch old method to new method, Current auto select user need to update
.auto_selectable_formats. Fortunately, current few users doesn't have
above limitation. update (A)(B) to (a)(b) style is possible.
a = A
b = A | B
I would like to update method, and add .auto_selectable_formats
support on all drivers.
One note is that auto select might not find best format on some CPU/Codec
combination. So "dai-format" is necessary anyway.
And, there haven't been any big problems on .auto_selectable_formats,
because there were few users.
But if all drivers try to use this, it cannot be denied that they may
encounter unknown problems... In such case, "dai-format" can help, though.
Link: https://patch.msgid.link/87v7bs36m0.wl-kuninori.morimoto.gx@renesas.com
"Simple Audio Card", "Audio Graph Card", "Audio Graph Card2" are
possible to set DAI format via DT.
OTOH, ASoC is supporting .auto_selectable_formats to select DAI
format automatically. Let's recommend to use it on "Audio Graph Card2".
One note is that it keeps supporting DAI format setting via DT.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87ik7s36k2.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current DAI supports auto format selection. It allow to have array like
below.
(X) static u64 xxx_auto_formats[] = {
(A) /* First Priority */
SND_SOC_POSSIBLE_DAIFMT_I2S |
SND_SOC_POSSIBLE_DAIFMT_LEFT_J,
/* Second Priority */
(B) SND_SOC_POSSIBLE_DAIFMT_DSP_A |
SND_SOC_POSSIBLE_DAIFMT_DSP_B,
};
It try to find available format from I2S/LEFT_J first (A).
Then, try to find from I2S/LEFT_J/DSP_A/DSP_B if couldn't find (A)+(B).
(OR:ed)
In this method, it can't handle if there is format combination.
For example, some driver has pattern.
Pattern1
I2S/RIFHT_J/LEFT_J (FORMAT) and NB_NF/IB_IF/IB_NF/NB_IF (INV)_
Pattern2
DSP_A/DSP_B (FORMAT) and NB_NF/ IB_NF
Because it will try to OR Pattern1 and Pattern2, un-supported
pattern might be selected.
This patch update method not to use OR, and assumes full format array.
Above sample (X) need to be
static u64 xxx_auto_formats[] = {
/* First Priority */
SND_SOC_POSSIBLE_DAIFMT_I2S |
SND_SOC_POSSIBLE_DAIFMT_LEFT_J,
/* Second Priority */
SND_SOC_POSSIBLE_DAIFMT_I2S |
SND_SOC_POSSIBLE_DAIFMT_LEFT_J |
SND_SOC_POSSIBLE_DAIFMT_DSP_A |
SND_SOC_POSSIBLE_DAIFMT_DSP_B,
};
Note: It doesn't support Multi CPU/Codec for now
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87jys836k8.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current auto select format start with the highest priority format and
gradually add lower priority formats one by one, and search matched
format. Like A+X -> A+B+X -> A+B+C+X+Y... (a)
But in this method, we can't handle format if HW has some kind of
patterns, like A+X or B+Y etc (b).
Current drivers are using (a) style, this patch switch to use (b) style.
This is needed before update auto select format method.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87ldco36kf.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current auto select format start with the highest priority format and
gradually add lower priority formats one by one, and search matched
format. Like A+X -> A+B+X -> A+B+C+X+Y... (a)
But in this method, we can't handle format if HW has some kind of
patterns, like A+X or B+Y etc (b).
Current drivers are using (a) style, this patch switch to use (b) style.
This is needed before update auto select format method.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87mrx436kl.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current auto select format start with the highest priority format and
gradually add lower priority formats one by one, and search matched
format. Like A+X -> A+B+X -> A+B+C+X+Y... (a)
But in this method, we can't handle format if HW has some kind of
patterns, like A+X or B+Y etc (b).
Current drivers are using (a) style, this patch switch to use (b) style.
This is needed before update auto select format method.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87o6hk36kp.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Because it is confusable during debugging ASoC FW update, tidyup
auto format style not to use array if single pattern case.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87pl2036kt.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Because it is confusable during debugging ASoC FW update, tidyup
auto format style not to use array if single pattern case.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87qzmg36ky.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Because it is confusable during debugging ASoC FW update, tidyup
auto format style not to use array if single pattern case.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87se6w36la.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clock provider / consumer selection is based on board, we can't select
automatically from software. Let's remove SND_SOC_POSSIBLE_xBx_xFx.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87tsrc36li.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PLL lock failure path in adau1372_set_power() unwinds by putting
the regmap back in cache-only mode, asserting the optional power-down
GPIO and disabling mclk.
adau1372_enable_pll() enables CLK_CTRL.PLL_EN before polling the PLL
lock bit. If the lock fails on a board without a power-down GPIO, the
error path disables mclk and returns an error, but leaves PLL_EN set in
the hardware register. The normal power-off path already handles the
no-GPIO case by explicitly clearing PLL_EN.
Mirror that cleanup in the PLL lock failure path and clear PLL_EN while
the regmap is still live, before switching it back to cache-only mode.
Fixes: bfe6a264ef ("ASoC: adau1372: Fix clock leak on PLL lock failure")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260604125520.1428905-1-lgs201920130244@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Cássio Gabriel <cassiogabrielcontato@gmail.com> says:
Some ASoC drivers still manually release child OF nodes
when leaving child-node iteration loops early.
Convert these focused cases to scoped OF node cleanup
so early returns and normal loop exits keep the same node
lifetime handling without explicit of_node_put() calls.
- Patch 1 updates qcom_snd_parse_of() to use
for_each_available_child_of_node_scoped() for link nodes and
__free(device_node) for temporary cpu/platform/codec child nodes.
- Patch 2 updates fsl_qmc_audio to use
for_each_available_child_of_node_scoped() for DAI child-node parsing.
- Patch 3 updates cygnus-ssp to use
for_each_available_child_of_node_scoped() for SSP child-node parsing.
Link: https://patch.msgid.link/20260608-asoc-of-node-scoped-cleanup-v1-0-9e3ac518dc2e@gmail.com
cygnus_ssp_probe() manually puts the current child node before returning
from the child parsing loop on error.
Use for_each_available_child_of_node_scoped() so the current child node is
released automatically on early return and normal loop exit.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260608-asoc-of-node-scoped-cleanup-v1-3-9e3ac518dc2e@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
qmc_audio_probe() manually puts the current child node before returning
from the DAI parsing loop on error.
Use for_each_available_child_of_node_scoped() so the current child node is
released automatically on early return and normal loop exit.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260608-asoc-of-node-scoped-cleanup-v1-2-9e3ac518dc2e@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
qcom_snd_parse_of() manually drops the link child node and the
cpu/platform/codec child nodes on error paths and at the end of each
iteration.
Use for_each_available_child_of_node_scoped() for the link node and
__free(device_node) for the named child nodes. This keeps the existing
ownership rules for DAI component phandle references, while removing the
manual cleanup labels from a path that has previously needed OF refcount
fixes.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260608-asoc-of-node-scoped-cleanup-v1-1-9e3ac518dc2e@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 87a3f5c8ac ("ASoC: sdw_utils: cs42l43: allow spk component names
to be combined") moved spk:cs42l43-spk generation from rtd_init() into
the asoc_sdw_rtd_init() generic path by adding component_name to
codec_info_list entries. However, only the 0x4243 cs42l43 entry was
updated; the 0x2A3B entry (vendor_id 0x01fa, Cirrus Logic cs42l43 with
sidecar bridge) was missed.
Without component_name on the 0x2A3B dp6 DAI, asoc_sdw_rtd_init() never
accumulates spk_components and never appends 'spk:cs42l43-spk' (or its
sidecar alias 'spk:cs35l56-bridge') to card->components. The sof-soundwire
UCM regex ' spk:([a-z0-9]+...)' then fails to match, causing WirePlumber
to mark all HiFi profiles as unavailable=no and fall back to the Off
profile — resulting in Dummy Output in GNOME.
The existing sidecar redirect in asoc_sdw_rtd_init() already handles the
SOC_SDW_SIDECAR_AMPS case: when component_name is 'cs42l43-spk' and
sidecar amps are active, it substitutes 'cs35l56-bridge' into
card->components, which matches the existing cs35l56-bridge.conf UCM file.
Fixes: 87a3f5c8ac ("ASoC: sdw_utils: cs42l43: allow spk component names to be combined")
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Link: https://patch.msgid.link/20260610041753.1151088-1-acelan.kao@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
These are tidyup details of mediatek drivers. Basically there is no
functional change. This is prepare for later Card capsuling.
This makes code review easy when Card capsuling happen.
Kuninori Morimoto (6):
Link: https://patch.msgid.link/87ik7tesdw.wl-kuninori.morimoto.gx@renesas.com
use *dev, instead of card->dev.
No functional change, but is preparation for cleanup driver.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87a4t5escw.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
use *dev, instead of card->dev.
No functional change, but is preparation for cleanup driver.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87bjdlesd0.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
mtk_sof_dailink_parse_of() is using unnecessarily complicated parameters.
Let's cleanup it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87h5ndesdg.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When the topology filename contains "dummy" and tplg_cnt is 0, the
function returns -EINVAL directly without freeing the tplg_files
allocated by kcalloc() at line 2497. This leaks memory on every
such topology load attempt.
Fix this by setting ret = -EINVAL and jumping to the out: label,
which already handles the kfree(tplg_files) cleanup.
Fixes: 99c159279c ("ASoC: SOF: don't check the existence of dummy topology")
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/tencent_3EED6D778DC52C3703A2D1EE8119372E8E08@qq.com
Signed-off-by: Mark Brown <broonie@kernel.org>
bui duc phuc <phucduc.bui@gmail.com> says:
This series converts mutex and spinlock handling in Mediatek ASoC drivers
to use guard() helpers.
Most patches are straightforward conversions to guard() helpers with no
functional change intended.
One exception is mt8192-afe-gpio, where the mutex release point moves from
immediately before dev_warn() to scope exit. However, the affected path
only emits a warning and immediately returns -EINVAL, without any further
processing.
Compile-tested only.
Link: https://patch.msgid.link/20260610102021.83273-1-phucduc.bui@gmail.com
Clean up the code using guard() for mutex & spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260610102021.83273-9-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
