| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A standard set of driver-specific fixes and quirks accumulated since
the merge window:
ASoC:
- SOF: Sanity check to prevent OOB reads
- rsnd: Fix clock leak and double-disable issues with PM
- tas675x: Misc fixes for register fields, etc
- lpass-va-macro: Correct codec version for Qualcomm SC7280
- amd-yc: DMIC quirk for Alienware m15 R7 AMD
Others:
- us144mkii: Fix a UAF on disconnect and anchor list corruption
- HD-audio: Realtek quirks for HP models"
* tag 'sound-7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: rsnd: src: Add missing scu_supply clock to suspend/resume
Documentation: sound: tas675x: Fix temperature range and impedance documentation
ASoC: codecs: tas675x: Fix CHx temperature range register bit fields
ASoC: codecs: tas675x: use READ_ONCE for params to be used concurrently
ASoC: rsnd: adg: make rsnd_adg_clk_control() idempotent
ASoC: SOF: validate probe info element counts
ALSA: usx2y: us144mkii: fix work UAF on disconnect
ASoC: amd: yc: Add Alienware m15 R7 AMD to DMIC quirk table
ALSA: hda/realtek: Add quirk for HP Victus 16-e0xxx (88EE) to enable mute LED
MAINTAINERS: ASoC: SOF: add AMD reviewer for Sound Open Firmware
ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280
ALSA: us144mkii: capture_urb_complete: redundant usb_anchor_urb corrupts anchor list on each resubmission
|
|
files)
Replace the #include of <linux/mod_devicetable.h> by the more specific
<linux/device-id/*.h> where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
Sen Wang <sen@ti.com> says:
Few miscellaneous bug fixes after the initial merge of TAS675x driver, of
which includes:
- Adding READ_ONCE for all concurrent read params
- Corrected kcontrol bits for temperature range
- Corrected conversion notes in the driver documentation
Link: https://patch.msgid.link/20260630183126.2588322-1-sen@ti.com
|
|
The initial merged patch mixed up the bits for temp reg with LDG report,
now fixing to the right bits according to TRM (SLOU589A).
Fixes: 133c81f84471 ("ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver")
Signed-off-by: Sen Wang <sen@ti.com>
Link: https://patch.msgid.link/20260630183126.2588322-3-sen@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
active_playback_dais and active_capture_dais are written atomically via
set_bit()/clear_bit() and can be read concurrently from the
fault_check_work delayed work handler.
fault_check_work already uses READ_ONCE; extend the same guard to all other
reads in tas675x_hw_params() and tas675x_mute_stream().
Fixes: 133c81f84471 ("ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver")
Signed-off-by: Sen Wang <sen@ti.com>
Link: https://patch.msgid.link/20260630183126.2588322-2-sen@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
According to both the static definition in downstream...
yupik-audio-overlay.dtsi: qcom,bolero-version = <4>;
#define BOLERO_VERSION_2_0 0x0004)
and the runtime detection:
CDC_VA_TOP_CSR_CORE_ID_0=0x1
CDC_VA_TOP_CSR_CORE_ID_1=0xf
SC7280 has LPASS Codec Version 2.0 and not, as declared with
sm8250_va_data LPASS_CODEC_VERSION_1_0.
Create new va_macro_data with .version not set to use the runtime
detection and correctly get .version = LPASS_CODEC_VERSION_2_0.
Fixes: 77212f300bfd ("ASoC: codecs: lpass-va-macro: set the default codec version for sm8250")
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260526-sc7280-va-macro-2-0-v1-1-2c1b572fa388@fairphone.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.2
We've got a good collection of device specific fix here, plus a couple
of stand out things:
- Richard fixed some special cases with the new device_link creation
by more gracefully handling any errors during creation.
- Charles did some light refactoring of the SoundWire interfaces to
fix some persistent randconfig issues that people kept running into.
|
|
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 addr field in the SPI burst write buffer represents on-wire
little-endian data. Define it as __le32 so that the assignment of
cpu_to_le32() is type correct and avoids sparse endian warnings.
Closes:
https://lore.kernel.org/oe-kbuild-all/202606230139.rFZUVpCa-lkp@intel.com/
Fixes: 420739112e95 ("ASoC: rt5575: Add the codec driver for the ALC5575")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://patch.msgid.link/20260623102514.2422990-1-oder_chiou@realtek.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>
|
|
Charles Keepax <ckeepax@opensource.cirrus.com> says:
Moving all the waiting for soundwire devices to enumerate into the core
code [1] has caused some randconfig issues. This is the second attempt
to fix this after there were some short coming in [2].
Sorry for sending during the merge window, but people are keen to see
a solution posted.
[1] https://lore.kernel.org/linux-sound/20260608102714.2503120-1-ckeepax@opensource.cirrus.com/
[2] https://lore.kernel.org/lkml/20260615150523.4006982-1-ckeepax@opensource.cirrus.com/
Link: https://patch.msgid.link/20260623101814.24044-1-ckeepax@opensource.cirrus.com
|
|
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>
|
|
When this driver was first added, it accepted rates of 24.56 MHz and
22.572 MHz for the MCLK when PLL bypass is enabled.
These rates seem to have no basis in the datasheets and were thus replaced
with 45.1584 MHz and 49.152 MHz, respectively, in commit e7ab858390f2
("ASoC: cs530x: Correct MCLK reference frequency values").
While the new rates are indeed correct for the CS4xxx ICs[0][1][2][3],
they are incorrect for the CS530x ICs the driver was originally written to
support as the MCLK frequencies are halved there[4][5][6].
Fix this by checking against the correct type-appropriate rates.
While at it, drop the CS530X_SYSCLK_REF_* macros. They arguably confuse
more than they help, especially as they are not applicable to the
cs5302/4/8.
[0]: https://statics.cirrus.com/pubs/proDatasheet/CS4282P_DS1318F1.pdf
[1]: https://statics.cirrus.com/pubs/proDatasheet/CS4302P_DS1315F1.pdf
[2]: https://statics.cirrus.com/pubs/proDatasheet/CS4304P_DS1316F1.pdf
[3]: https://statics.cirrus.com/pubs/proDatasheet/CS4308P_DS1317F1.pdf
[4]: https://statics.cirrus.com/pubs/proDatasheet/CS5302P_DS1312F1.pdf
[5]: https://statics.cirrus.com/pubs/proDatasheet/CS5304P_DS1313F1.pdf
[6]: https://statics.cirrus.com/pubs/proDatasheet/CS5308P_DS1314F1.pdf
Fixes: 2884c29152c0 ("ASoC: cs530x: Support for cs530x ADCs")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260617-cs530x-mclk-v1-1-0215b5f1a0a4@pengutronix.de
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: 4f9c16ccfa26 ("[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>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v7.2
There's been quite a lot of framework improvements this time around,
though mainly cleanups and robustness rather than user visible features.
The same pattern is seen with a lot of the driver work that's going on,
there are new features but a huge proportion of this is bug fixing and
cleanup work. We also have a good selectio of new device support.
- Improvements to SDCA jack handling from Charles Keepax.
- Use of device links to make suspend handling more robust from Richard
Fitzgerald.
- Use of a new helper to factor out a common pattern in SoundWire
enmeration from Charles Keepax.
- Slimming down of the component from Kuninori Morimoto.
- Simplification of format auto selection from Kuninori Morimoto.
- Lots of conversions to guard() from Bui Duc Phuc.
- Addition of a simple-amplifier driver supporting more featureful GPIO
controller amplifiers than the previous basic driver from Herve
Codina.
- Support for AMD ACP 7.x, Cirrus Logic CS42448/CS42888, Everest Semi
ES9356, Mediatek MT2701 and MT8196, Renesas RZ/G3E, Spacemit K3,
Texas Instruments TAC5xx2 and TAS67524.
|
|
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
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
|
|
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: bfe6a264effc ("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>
|
|
Commit [1] updated the core to use complete_all() which means that
the wait_for_completion() will now simply return if the device
is already attached, so skipping the completion isn't required
anymore. Update the code to simply call sdw_slave_wait_for_init()
unconditionally.
[1] c40d6b3249b1 ("soundwire: fix enumeration completion")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260608102714.2503120-11-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Now the new wait for SoundWire enumeration helper no longer depends on
unattach_request it is safe to use from probe time. Update the driver
to use the new core helper.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260608102714.2503120-9-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Now the new wait for SoundWire enumeration helper no longer depends on
unattach_request it is safe to use from probe time. Update the driver
to use the new core helper.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260608102714.2503120-8-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Now the new wait for SoundWire enumeration helper no longer depends on
unattach_request it is safe to use from probe time. Update the driver
to use the new core helper.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260608102714.2503120-7-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Now the new wait for SoundWire enumeration helper no longer depends on
unattach_request it is safe to use from probe time. Update the driver
to use the new core helper.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260608102714.2503120-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Now the new wait for SoundWire enumeration helper no longer depends on
unattach_request it is safe to use from probe time. Update the driver
to use the new core helper.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260608102714.2503120-5-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Now the new wait for SoundWire enumeration helper no longer depends on
unattach_request it can be used for code that also doesn't check this
flag. Update the driver to use the new core helper.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260608102714.2503120-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
HyeongJun An <sammiee5311@gmail.com> says:
Some custom ASoC kcontrol put() handlers use the written enum value
(ucontrol->value.enumerated.item[0]) to index a table or compute a bit
shift before validating that the value is within the control's enum range.
An out-of-range value written from userspace is therefore consumed before
it is rejected.
This is the same class addressed for the Meson codecs in commit
1e001206804b ("ASoC: meson: g12a-tohdmitx: Validate written enum values")
and commit 3150b70e944e ("ASoC: meson: g12a-toacodec: Validate written
enum values").
Fix four more instances:
- hdac_hdmi reads e->texts[item] before validation.
- aiu converts the item before validating it.
- fsl_audmix converts the item and uses the result before validation.
- tegra210_ahub reads e->values[item] before validation.
Link: https://patch.msgid.link/20260609124317.38046-1-sammiee5311@gmail.com
|
|
hdac_hdmi_set_pin_port_mux() uses the written enum value to index the
texts array before calling snd_soc_dapm_put_enum_double(), which validates
that the value is within the enum item range.
An out-of-range value can therefore make the driver read past the texts
array before the helper rejects the write. Move the lookup after the helper
has accepted the value.
Fixes: 4a3478debf36 ("ASoC: hdac_hdmi: Add jack reporting")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260609124317.38046-2-sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In cs35l56_cal_data_debugfs_write() fix the if statement that checks for
error return to only check for negative values.
Reported by Sashiko:
simple_write_to_buffer() returns the positive number of bytes copied
on success. Since the condition returns immediately on any non-zero
value, is it possible that the written calibration data is discarded
and cs35l56_stash_calibration() is never called?
Fixes: f7097161e94c ("ASoC: cs35l56: Add common code for factory calibration")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260610093432.557375-1-rf%40opensource.cirrus.com
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260611151234.1111153-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In cs35l56_spi_system_reset() initialize val to zero before using it in
the read_poll_timeout(). This prevents testing an uninitialized value if
the regmap_read_bypassed() returns an error.
Read errors are intentionally ignored during this loop because the
device is resetting (though SPI can't really detect that so shouldn't
fail because of that, it's safer to ignore errors and keep polling).
Because of this, val must be initialized to something in case the first
read fails. The polling loop is looking for a non-zero value, so
initializing val to 0 will ensure that the loop continues until a valid
state is read from the device or it times out.
Fixes: 769c1b79295c ("ASoC: cs35l56: Prevent races when soft-resetting using SPI control")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260611132221.1100497-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In cs35l56_system_suspend() re-enable the parent IRQ if the call to
pm_runtime_force_suspend() returns an error.
Fixes: f9dc6b875ec0 ("ASoC: cs35l56: Add basic system suspend handling")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260610105556.612830-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The tas2783 driver defines two functions tas25xx_register_misc and
tas25xx_deregister_misc which have stub implementations. It uses
external implementations if CONFIG_SND_SOC_TAS2783_UTIL is enabled, but
that symbol has never been present in the kernel. Therefore, these
functions are entirely unused. Remove them.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Link: https://patch.msgid.link/20260610013534.30762-1-enelsonmoore@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Richard Fitzgerald <rf@opensource.cirrus.com> says:
These are for-next.
They are not urgent because it only leaks memory if the driver failed to
component_probe or is removed, which wouldn't happen in normal use.
This series fixes some memory leaks:
- The memory allocated by wm_adsp/cs_dsp was not freed.
- If component_probe() failed it didn't clean up.
The addition of this cleanup in patch #3 exposes an existing possible
double-free of the debugfs, which is fixed in patch #2.
Link: https://patch.msgid.link/20260610093432.557375-1-rf@opensource.cirrus.com
|
|
If cs35l56_component_probe() fails, call cs35l56_component_remove() to
clean up.
All the cleanup in cs35l56_component_remove() is the same cleanup that
would need to be done (at least partially) if cs35l56_component_probe()
fails. So calling cs35l56_component_remove() avoids convoluted cleanup
gotos and duplicated code in cs35l56_component_probe().
The only action in cs35l56_component_remove() that is nominally
dependent on having completed the component_probe() action is the call
to wm_adsp2_component_remove(). Though it is currently safe to call that
even if wm_adsp2_component_probe() was not called. However,
wm_adsp2_component_probe() has been trivially updated to check itself
whether it needs to cleanup.
Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260610093432.557375-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Invalidate the debugfs pointer after debugfs_remove_recursive() in
cs35l56_remove_cal_debugfs(). This prevents a double-free situation when
a future commit adds proper failure cleanup in cs35l56_component_probe().
As described by Sashiko (including the future cs35l56_component_probe()
cleanup commit):
During a normal component unbind, cs35l56_component_remove() calls
cs35l56_remove_cal_debugfs() which removes the directory but leaves
a dangling pointer.
If the component is later bound again, but _cs35l56_component_probe()
fails early (for example, if the init_completion times out), this new
error path will call cs35l56_component_remove(). This causes
cs35l56_remove_cal_debugfs() to be called again with the dangling
cs35l56_base->debugfs pointer from the previous lifecycle, resulting in
a use-after-free in debugfs_remove_recursive().
Fixes: f7097161e94c ("ASoC: cs35l56: Add common code for factory calibration")
Reported-by: sashiko <sashiko@sashiko.dev>
Link: https://sashiko.dev/#/patchset/20260609120738.284770-1-rf%40opensource.cirrus.com
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260610093432.557375-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Call wm_adsp2_remove() in cs35l56_remove() and the error path of
cs35l56_common_probe().
Depends on commit 7d3fb78b5503 ("ASoC: wm_adsp: Fix NULL dereference
when removing firmware controls").
The call to wm_halo_init() during driver probe should be paired with
a call to wm_adsp2_remove() but this was missing. The consequence
would be a memory leak of the control lists in the cs_dsp driver.
Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260610093432.557375-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
processing
Fix reset for device-0: In older projects (e.g., Merino), the hardware
reset pin for the first SPI device (device-0) is ineffective, causing
initialization failures. Added a software reset sequence for device-0
to ensure proper initialization.
Handle -EXDEV correctly: When processing block data, if the data does
not belong to the current SPI device, the driver returned -EXDEV.
This error code is now ignored to allow the driver to continue iterating
through the block data and correctly calculate the total block size.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
Link: https://patch.msgid.link/20260609105253.19510-1-baojun.xu@ti.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Val Packett <val@packett.cool> says:
The Awinic smart speaker/amp drivers were merged in a very
"downstream-brained" state, where configuration was only really
determined by the binary "firmware" (register list) file instead
of properly participating in the ASoC system. Let's start
untangling this mess. This series makes aw88261 actually usable
on devices like fairphone-fp5, motorola-dubai and xiaomi-pipa.
Link: https://patch.msgid.link/20260529200550.529719-1-val@packett.cool
|
|
- Invert the value to match userspace expectations (in the hardware,
positive numbers represent negative dB attenuation)
- Provide TLV metadata for the dB scale (and divide the raw values by 2
as the excessive precision used by HW is not representable in TLV)
- Do not unnecessarily reset the volume while switching profiles
- Simplify aw88261_dev_set_volume using regmap_update_bits
- Do not add the initial volume from the profile to the requested volume
as that would throw off the dB mapping (if a lower max limit is
desired, it can be set in the UCM profile in userspace)
With this change, it's actually possible to use this hardware volume
control as PlaybackVolume in an ALSA UCM profile.
Fixes: 028a2ae25691 ("ASoC: codecs: Add aw88261 amplifier driver")
Signed-off-by: Val Packett <val@packett.cool>
Link: https://patch.msgid.link/20260529200550.529719-8-val@packett.cool
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The boost-related register fields used in aw88261_reg_force_set use the
exact same definitions as the rest of the fields, where the mask must be
inverted when passing it to regmap_update_bits, but they weren't
inverted here.
Fixes: 028a2ae25691 ("ASoC: codecs: Add aw88261 amplifier driver")
Signed-off-by: Val Packett <val@packett.cool>
Tested-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://patch.msgid.link/20260529200550.529719-7-val@packett.cool
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Codec drivers are not supposed to do anything like this. The result was
that the first second or so of playback was essentially inaudible, and
very short alert sounds could be missed entirely. Let's not do this.
Signed-off-by: Val Packett <val@packett.cool>
Tested-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://patch.msgid.link/20260529200550.529719-6-val@packett.cool
Signed-off-by: Mark Brown <broonie@kernel.org>
|
