ALSA: hda: Drop NULL check for snd_ctl_remove()

Since snd_ctl_remove() accepts the NULL kcontrol argument now, we can
drop the check in the caller side.

Link: https://lore.kernel.org/20240617100529

ALSA: hda: Drop NULL check for snd_ctl_remove()

Since snd_ctl_remove() accepts the NULL kcontrol argument now, we can
drop the check in the caller side.

Link: https://lore.kernel.org/20240617100529.6667-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...

ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup

Use the control private_free callback to free the associated data
block. This ensures that the memory won't leak, whatever way the
control

ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup

Use the control private_free callback to free the associated data
block. This ensures that the memory won't leak, whatever way the
control gets destroyed.

The original implementation didn't actually remove the ALSA
controls in hda_cs_dsp_control_remove(). It only freed the internal
tracking structure. This meant it was possible to remove/unload the
amp driver while leaving its ALSA controls still present in the
soundcard. Obviously attempting to access them could cause segfaults
or at least dereferencing stale pointers.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 3233b978af23 ("ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls")
Link: https://lore.kernel.org/r/20240508095627.44476-1-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...

ALSA: hda: hda_cs_dsp_ctl: Remove notification of driver write

Any control that the driver is updating should be marked as SYSTEM and
therefore will not have an ALSA control to notify.

Signed-off-b

ALSA: hda: hda_cs_dsp_ctl: Remove notification of driver write

Any control that the driver is updating should be marked as SYSTEM and
therefore will not have an ALSA control to notify.

Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://msgid.link/r/20240325113127.112783-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ALSA: hda: hda_cs_dsp_ctl: Use cs_dsp_coeff_lock_and_[read|write]_ctrl()

Using the cs_dsp_coeff_lock_and_[read|write]_ctrl() wrappers tidies
the calling functions as it does not need to manage the D

ALSA: hda: hda_cs_dsp_ctl: Use cs_dsp_coeff_lock_and_[read|write]_ctrl()

Using the cs_dsp_coeff_lock_and_[read|write]_ctrl() wrappers tidies
the calling functions as it does not need to manage the DSP pwr_lock.

Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://msgid.link/r/20240325113127.112783-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ALSA: hda: cs35l41: Correct error condition handling

Function cs_dsp_coeff_write_ctrl() can return 3 possible values:
0 - no change, 1 - value has changed and -1 - error, so positive value
is not an

ALSA: hda: cs35l41: Correct error condition handling

Function cs_dsp_coeff_write_ctrl() can return 3 possible values:
0 - no change, 1 - value has changed and -1 - error, so positive value
is not an error.
Fixes: 7406bdbc4fb8 ("ASoC: wm_adsp: Return whether changed when writing controls")

Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230213145008.1215849-2-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...

firmware: cs_dsp: Make the exports namespaced

Move all the exports into a namespace.
This also adds the MODULE_IMPORT_NS to the 3 drivers that use the
exported functions.

Signed-off-by: Richard Fit

firmware: cs_dsp: Make the exports namespaced

Move all the exports into a namespace.
This also adds the MODULE_IMPORT_NS to the 3 drivers that use the
exported functions.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221124134556.3343784-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

ALSA: hda/cs_dsp_ctl: Fix mutex inversion when creating controls

Redesign the creation of ALSA controls so that the cs_dsp
pwr_lock is not held when calling snd_ctl_add(). Instead of
creating the AL

ALSA: hda/cs_dsp_ctl: Fix mutex inversion when creating controls

Redesign the creation of ALSA controls so that the cs_dsp
pwr_lock is not held when calling snd_ctl_add(). Instead of
creating the ALSA control from the cs_dsp control_add callback,
do it after cs_dsp_power_up() has completed. The existing
functions are changed to return void instead of passing errors
back - this duplicates the original behaviour, as cs_dsp does
not abort firmware load if creation of a control fails.

It is safe to walk the control list without taking any mutex
provided that the caller is not trying to load a new firmware
or remove the driver in parallel. There is no other situation
that the list can change. So the caller can trigger creation
of ALSA controls after cs_dsp_power_up() has returned. A cs_dsp
control will have a non-NULL priv pointer if we have created
an ALSA control.

With the previous code the ALSA controls were created from
the cs_dsp control_add callback. But this is called with
pwr_lock held (as it is part of the DSP power-up sequence).
The kernel lock checking will show a mutex inversion between
this and the control creation path:

control_add
pwr_lock held, takes controls_rwsem (in snd_ctl_add)

get/put
controls_rwsem held, takes pwr_lock to call cs_dsp.

This is not completely theoretical. Although the time window
is very small, it is possible for these to run in parallel
and deadlock the old implementation.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221011143552.621792-4-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...

ALSA: hda: hda_cs_dsp_ctl: Ensure pwr_lock is held before reading/writing controls

These apis require the pwr_lock to be held.

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: h

ALSA: hda: hda_cs_dsp_ctl: Ensure pwr_lock is held before reading/writing controls

These apis require the pwr_lock to be held.

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221011143552.621792-3-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...

ALSA: hda: hda_cs_dsp_ctl: Minor clean and redundant code removal

The cs_dsp core will return an error if passed a NULL cs_dsp struct so
there is no need for the hda_cs_dsp_write|read_ctl functions

ALSA: hda: hda_cs_dsp_ctl: Minor clean and redundant code removal

The cs_dsp core will return an error if passed a NULL cs_dsp struct so
there is no need for the hda_cs_dsp_write|read_ctl functions to manually
check that. The cs_dsp core will also check the data is within bounds of
the control so the additional bounds check is redundant too. Simplify
things a bit by removing said code.

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221011143552.621792-2-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...

ALSA: hda: hda_cs_dsp_ctl: Add fw id strings

This will be used to define the firmware names.

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Vitaly Rodionov <vitalyr@o

ALSA: hda: hda_cs_dsp_ctl: Add fw id strings

This will be used to define the firmware names.

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220630002335.366545-12-vitalyr@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...

ALSA: hda: hda_cs_dsp_ctl: Add apis to write the controls directly

DSP controls are exposed as ALSA controls, however,
some of these controls are required to be accessed by
the driver. Add apis whic

ALSA: hda: hda_cs_dsp_ctl: Add apis to write the controls directly

DSP controls are exposed as ALSA controls, however,
some of these controls are required to be accessed by
the driver. Add apis which allow read/write of these
controls. The write api will also notify the ALSA control
on value change.

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220630002335.366545-3-vitalyr@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...

ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls

The cs35l41 part contains a DSP which is able to run firmware.
The cs_dsp library can be used to control the DSP.
These control

ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls

The cs35l41 part contains a DSP which is able to run firmware.
The cs_dsp library can be used to control the DSP.
These controls can be exposed to userspace using ALSA controls.
This library adds apis to be able to interface between
cs_dsp and hda drivers and expose the relevant controls as
ALSA controls.

[ Note: the dependency of CONFIG_SND_HDA_CS_DSP_CONTROLS Kconfig is
corrected. Also, this Kconfig isn't enabled now but will be
actually enabled in a later patch -- tiwai ]

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220630002335.366545-2-vitalyr@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

show more ...