This loop iterates 200 times and then gives up. The problem is that
currently the loop exits with "retry" set to -1 on the failure path but
the check for failure expects it to be 0. Change from a post-op to a
pre-op so that it exits with "retry" set to 0.
Fixes: 22937af75a ("ASoC: rt1320: support RAE parameters loading")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/aUZiNJ7pzuahXFYE@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Clang warns (or errors with CONFIG_WERROR=y / W=e):
sound/soc/codecs/rt1320-sdw.c:1387:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
1387 | if (!fw_ready) {
| ^~~~~~~~~
sound/soc/codecs/rt1320-sdw.c:1421:9: note: uninitialized use occurs here
1421 | return ret;
| ^~~
sound/soc/codecs/rt1320-sdw.c:1387:2: note: remove the 'if' if its condition is always false
1387 | if (!fw_ready) {
| ^~~~~~~~~~~~~~~~
1388 | dev_warn(dev, "%s, DSP FW is NOT ready\n", __func__);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1389 | goto _exit_;
| ~~~~~~~~~~~~
1390 | }
| ~
sound/soc/codecs/rt1320-sdw.c:1366:9: note: initialize the variable 'ret' to silence this warning
1366 | int ret;
| ^
| = 0
The return value of rt1320_t0_load() is never actually used, so it can
just be eliminated altogether by returning void, clearing up the
warning.
Fixes: da1682d5e8 ("ASoC: rt1320: support calibration and temperature/r0 loading")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202512191711.wY6XU796-lkp@intel.com/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Shuming Fan <shumingf@realtek.com>
Link: https://patch.msgid.link/20251219-rt1320-sdw-avoid-uninit-ret-v1-1-faa3e250ebc4@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
We support bytes control type for set and get, but these are module specific
controls and there is no way to handle notifications from them in a generic way.
Each control have module specific param_id and this param_id is only valid in
the module's scope, other modules might use the same id for different functions
for example.
This series will add a new generic control type, similar to the existing ones
for ENUM and SWITCH, which can be used to create bytes controls which can send
notifications from firmware on change.
The new param_id is 202 and the sof_ipc4_control_msg_payload is updated to
describe bytes payload also.
On set, the payload must include the sof_ipc4_control_msg_payload struct with
the control's ID and data size, followed by the data.
On get, the kernel needs to send the sof_ipc4_control_msg_payload struct along
with the LARGE_CONFIG_GET message as payload with the ID of the control that
needs to be retrieved. The raw data is received back without additional header.
A notification might contain data, in this case the num_elems reflects the size
in bytes, or without data. If no data is received then the control is marked as
dirty and on read the kernel will refresh the data from firmware.
The series includes mandatory fixes for existing code and adds support for
sending payload with LARGE_CONFIG_GET when the param_id is either generic ENUM,
SWITCH or BYTES control.
Components are bound inside a new devres group so that any resources
allocated can be released on bind failure and on unbind without
affecting anything else.
Switch to using device managed regmap allocation for consistency while
dropping the misleading comment claiming that devres cannot be used.
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20251201092259.11761-1-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace manual "request_threaded_irq()" with the device managed
"devm_request_threaded_irq" to manage the IRQ lifetime and also
it removes the smatch reported warning.
Remove the manual "free_irq()" in the "remove" function as free_irq
is tied to device teardown.
Signed-off-by: HariKrishna Sagala <hariconscious@gmail.com>
Link: https://patch.msgid.link/20251217054458.38257-2-hariconscious@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The firmware file for tas2783A contains the device
and algorithm settings. So the firmware files are unique
for a system and driver should have the ability to
distinctly identify and pick the right firmware.
This commit adds the method to uniquely identify the
firmware for a system based on the below format.
<Subsystem>-<Link>-<Unique>.bin
* Subsystem is the PCI device subsystem-id
* Link is the SoundWire link id on which the device recides.
* Unique is the SoundWire slave unique id in the system.
Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20251215153219.810-5-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are message types when we would need to send a payload along with
the LARGE_CONFIG_GET message to provide information to the firmware on
what data is requested.
Such cases are the ALSA Kcontrol related messages when the high level
param_id tells only the type of the control, but the ID/index of the exact
control is specified in the payload area.
The caller must place the payload for TX before calling the set_get_data()
and this payload will be sent alongside with the message to the firmware.
The data area will be overwritten by the received data from firmware.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20251217143945.2667-7-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace the use of __free(kfree) in _cs_amp_set_efi_calibration_data()
with normal kfree() at the end of the function.
Krzysztof Kozlowski pointed out that __free() can be dangerous.
It can introduce new cleanup bugs. These are more subtle and difficult to
spot than a missing goto in traditional cleanup, because they are triggered
by writing regular idiomatic C code instead of using C++ conventions. As
it's regular C style it's more likely to be missed because the code is as
would be expected for C. The traditional goto also more obviously flags
to anyone changing the code in the future that they must be careful about
the cleanup.
Arguably the traditional approach is more readable, and it avoids the
manipulation of __free() pointers when the buffer is reallocated for
resizing.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251201123906.86876-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace manual "request_threaded_irq()" with the device managed
"devm_request_threaded_irq" to manage the IRQ lifetime and also
it removes the smatch reported warning.
Remove the manual "free_irq()" in the "remove" function as free_irq
is tied to device teardown.
Signed-off-by: HariKrishna Sagala <hariconscious@gmail.com>
Link: https://patch.msgid.link/20251217104356.60839-3-hariconscious@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
On system suspend / resume we always power up the DSP and boot the
firmware, which is not strictly needed as right after the firmware booted
up we power the DSP down again on suspend and we also power it down after
resume after some inactivity.
Similarly, on jack insert/removal we needlesly boot up the firmware to check
the jack status, which needs no DSP/firmware communication.
The on-demand DSP boot will make sure that we boot the DSP firmware up only
when it is needed - for audio activity, in other cases the firmware will be
not booted up, which saves time.
Out of caution, add a new platform descriptor flag to enable on-demand
DSP boot since this might not work without changes to platform code on
certain platforms.
With the on-demand dsp boot enabled we will not boot the DSP and firmware
up on system or rpm resume, just enable audio subsystem since audio IPs,
like HDA and SoundWire might be needed (codecs suspend/resume operation).
Only boot up the DSP during the first hw_params() call when the DSP is
really going to be needed.
In this way we can handle the audio related use cases:
normal audio use (rpm suspend/resume)
system suspend/resume without active audio
system suspend/resume with active audio
system suspend/resume without active audio, and audio start before the rpm
suspend timeout
Add module option to force the on-demand DSP boot to allow it to be
disabled or enabled without kernel change for testing.
The on-demand boot has been tested in our CI for more than half a year
and so far no issues have been seen on supported platforms since it's
introduction to our development tree (sof-dev).
On system suspend / resume we always power up the DSP and boot the
firmware, which is not strictly needed as right after the firmware booted
up we power the DSP down again on suspend and we also power it down after
resume after some inactivity.
Out of caution, add a new platform descriptor flag to enable on-demand
DSP boot since this might not work without changes to platform code on
certain platforms.
With the on-demand dsp boot enabled we will not boot the DSP and firmware
up on system or rpm resume, just enable audio subsystem since audio IPs,
like HDA and SoundWire might be needed (codecs suspend/resume operation).
Only boot up the DSP during the first hw_params() call when the DSP is
really going to be needed.
In this way we can handle the audio related use cases:
normal audio use (rpm suspend/resume)
system suspend/resume without active audio
system suspend/resume with active audio
system suspend/resume without active audio, and audio start before the rpm
suspend timeout
Add module option to force the on-demand DSP boot to allow it to be
disabled or enabled without kernel change for testing.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20251215132946.2155-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>