Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:

This device exposes a headset codec on link0 and an amplifier on
link3. This is a very unusual pin-muxing, usually the microphones are
pin-muxed with link2/link3. This resulted in a problematic error
handling leading to a kernel oops, and invalidated a hard-coded
assumption.

Full support for this device requires a DMI quirk shared separately
("soundwire: dmi-quirks: add remapping for HP Omen 16-k0005TX").

Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:

Address the warning: "Codec: dpcm_be_connect: FE is nonatomic but BE is
not, forcing BE as nonatomic" by marking BE DAI as nonatomic. Aligns
with what is already done for FE DAIs.

This patchset iterates the change over all HSW and BDW related machine
board drivers.

Merge series from Stefan Binding <sbinding@opensource.cirrus.com>:

CS35L41 has a DSP which is able to run firmware, as well as a tuning file.
Different systems may want to use different firmwares and tuning files, and
some firmwares/tunings may not be compatible with other systems.
To allow a system to select the correct fimware/tuning, we can read an _SUB
from the ACPI. This _SUB can then be used to uniquely identify the system
in the firmware/tuning file name.

Add a helper function which reads the _SUB, so this can be used by other
parts in the future.
Add support inside the CS35L41 ASoC driver to read this _SUB, and save it
appropriately.

When PCH-attached DMICs are used on a SoundWire-based platform, all
known devices pin-mux SoundWire link2 and link3 with DMIC, and only
use link0 and link1 for SoundWire.

The HP Omen16 is the first exception to the rule, with SoundWire using
link0 and link3. Rather than using a fixed mask, let's count the
number of SoundWire links used.

BugLink: https://github.com/thesofproject/sof/issues/5966Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220715144144.274770-5-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The JD2 jack detection was selected based on similar settings from
other platforms based on RT711-SDCA.

BugLink: https://github.com/thesofproject/sof/issues/5955Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220715144144.274770-4-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

This device has an RT711-SDCA headset codec on link0 and an RT1316
amplifier on link3.

BugLink: https://github.com/thesofproject/sof/issues/5955Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220715144144.274770-3-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

While tinkering with ACPI work-arounds for the HP Omen 16 support, we
identified a corner case where the headset codec device properties are
not set in the codec .init when -EPROBE_DEFER is returned, but
released unconditionally in the .exit().

This leads to a kernel oops

[    4.186891] sof_sdw sof_sdw: snd_soc_register_card failed -517
[    4.186896] BUG: kernel NULL pointer dereference, address: 00000000000003f0
[    4.186914] Oops: 0000 [#1] PREEMPT SMP NOPTI
[    4.186926] RIP: 0010:dev_fwnode+0x5/0x20
[    4.186974]  device_remove_software_node+0x10/0x80
[    4.186982]  sof_sdw_rt711_exit+0x19/0x30 [snd_soc_sof_sdw]
[    4.186990]  mc_dailink_exit_loop+0x94/0xc0 [snd_soc_sof_sdw]
[    4.186996]  ? rt711_rtd_init+0x170/0x170 [snd_soc_sof_sdw]

A similar error case can occur if the addition of the device property
fails. We need to test if the property was successfully added before
removing it.

BugLink: https://github.com/thesofproject/linux/issues/3727
Fixes: 768ad6d8 ("ASoC: Intel: sof_sdw: handle errors on card registration")
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220715144144.274770-2-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Address the warning: "Codec: dpcm_be_connect: FE is nonatomic but BE is
not, forcing BE as nonatomic" by marking BE DAI as nonatomic. Aligns
with what is already done for FE ones.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220624134317.3656128-5-cezary.rojewski@intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Address the warning: "Codec: dpcm_be_connect: FE is nonatomic but BE is
not, forcing BE as nonatomic" by marking BE DAI as nonatomic. Aligns
with what is already done for FE ones.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220624134317.3656128-4-cezary.rojewski@intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Address the warning: "Codec: dpcm_be_connect: FE is nonatomic but BE is
not, forcing BE as nonatomic" by marking BE DAI as nonatomic. Aligns
with what is already done for FE DAIs.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220624134317.3656128-3-cezary.rojewski@intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Address the warning: "Codec: dpcm_be_connect: FE is nonatomic but BE is
not, forcing BE as nonatomic" by marking BE DAI as nonatomic. Aligns
with what is already done for FE DAIs.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220624134317.3656128-2-cezary.rojewski@intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Remove #ifdef CONFIG_PM and use pm_ptr() instead.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220715090939.1679963-1-claudiu.beznea@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

When loading firmware, wm_adsp uses a number of parameters to
determine the path of the firmware and tuning files to load.
One of these parameters is system_name.
Add support in cs35l41 to read this system name from the ACPI
_SUB ID in order to uniquely identify the firmware and tuning
mapped to a particular system.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220707151037.3901050-3-sbinding@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add a wrapper function to read the _SUB string from ACPI.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220707151037.3901050-2-sbinding@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

Needed for further development.

Before, ssiu.c didn't care SSI5-8, thus,
commit b1384d4c ("ASoC: rsnd: care default case on
rsnd_ssiu_busif_err_status_clear()") cares it for status clear.

But we should care it for error irq handling, too.
This patch cares it.
Reported-by: Nguyen Bao Nguyen <nguyen.nguyen.yj@renesas.com>
Reported-by: Nishiyama Kunihiko <kunihiko.nishiyama.dn@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871quocio1.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

There are two bugs that have to do with when we copy the payload:

	size = simple_write_to_buffer(ipc4_msg->data_ptr,
			      priv->max_msg_size, ppos, buffer,
			      count);

The value of "*ppos" was supposed to be zero but it is
sizeof(ipc4_msg->header_u64) so it will copy the data into the middle of
the "ipc4_msg->data_ptr" buffer instead of to the start.  The second
problem is "buffer" should be "buffer + sizeof(ipc4_msg->header_u64)".

This function is used for fuzz testing so the data is normally random
and this bug likely does not affect anyone very much.

In this context, it's simpler and more appropriate to use copy_from_user()
instead of simple_write_to_buffer() so I have re-written the function.

Fixes: 066c6762 ("ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/Ysg1tB2FKLnRMsel@kiliSigned-off-by: Mark Brown <broonie@kernel.org>

The version of the BCLK pinctrl management changes that made it into
v5.19 has caused problems on some systems due to overly strict DT
requirements but attempts to fix it have caused further breakage on
other platforms.  Just drop the changes for this release, we already
have a better version queued for -next.

Fixes: 26b9f2fa ("ASoC: rockchip: i2s: Fix NULL pointer dereference when pinctrl is not found")
Fixes: a5450aba ("ASoC: rockchip: i2s: switch BCLK to GPIO")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220713130451.31481-1-broonie@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>:

For SOF IPC4, we need to set pipeline state in BE DAI trigger.

For IPC4, we need to set pipeline state in BE DAI trigger.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220708061312.25878-3-yung-chuan.liao@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

When a pipeline is split into FE and BE parts, the BE pipeline may need to
be triggered separately in the BE trigger op. So add the trigger callback
in the link_res ops that will be invoked during BE DAI trigger.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20220708061312.25878-2-yung-chuan.liao@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call
of_node_put() for the reference returned by of_get_child_by_name()
which has increased the refcount.

Fixes: 68353028 ("ASoC: mt6359: fix failed to parse DT properties")
Fixes: eef07b9e ("ASoC: mediatek: mt6359: add MT6359 accdet jack driver")
Signed-off-by: Liang He <windhl@126.com>
Link: https://lore.kernel.org/r/20220713102013.367336-1-windhl@126.comSigned-off-by: Mark Brown <broonie@kernel.org>

Since SND_SOC_ES8316 has a hard dependency on I2C and since 'select'
does not follow any dependency chains, SND_SOC_AMD_ST_ES8336_MACH
also needs to have a hard dependency on I2C.

Fixes a kconfig warning and subsequent build errors:

WARNING: unmet direct dependencies detected for SND_SOC_ES8316
  Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && I2C [=n]
  Selected by [y]:
  - SND_SOC_AMD_ST_ES8336_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AMD_ACP [=y] && ACPI [=y] && (I2C [=n] || COMPILE_TEST [=y])

sound/soc/codecs/es8316.c:866:1: warning: data definition has no type or storage class
  866 | module_i2c_driver(es8316_i2c_driver);
sound/soc/codecs/es8316.c:866:1: error: type defaults to ‘int’ in declaration of ‘module_i2c_driver’ [-Werror=implicit-int]
sound/soc/codecs/es8316.c:866:1: warning: parameter names (without types) in function declaration
sound/soc/codecs/es8316.c:857:26: warning: ‘es8316_i2c_driver’ defined but not used [-Wunused-variable]
  857 | static struct i2c_driver es8316_i2c_driver = {

Fixes: f94fa840 ("ASoC: amd: enable machine driver build for Jadeite platform")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Link: https://lore.kernel.org/r/20220712183348.31046-1-rdunlap@infradead.orgSigned-off-by: Mark Brown <broonie@kernel.org>

We should call of_node_put() for the reference before its replacement
as it returned by of_get_parent() which has increased the refcount.
Besides, we should also call of_node_put() before return.

Fixes: c8c74939 ("ASoC: audio-graph-card2: add Multi CPU/Codec support")
Signed-off-by: Liang He <windhl@126.com>
Link: https://lore.kernel.org/r/20220713071200.366729-1-windhl@126.comSigned-off-by: Mark Brown <broonie@kernel.org>

The "gpio_pa" pointer is an error pointer, there is no need to try
put it.  Calling gpiod_put() on it will lead to an error pointer
dereference.

Fixes: 02527c3f ("ASoC: amd: add Machine driver for Jadeite platform")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/Ys2IRPHWGIwuVs21@kiliSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:

The FSR (Firmware State Register) holds the ROM state information, it does not
contain error information.
The FSR itself is a bit more complicated as well as the state depends on the
module currently in use.

The error code from ROM or the status code from the firmware is located at the
next register.

Fix the handling of the FSR in order to provide usable and human readable (in
most cases) report on the status and error.

Merge series from Daniel Baluta <daniel.baluta@oss.nxp.com>
Daniel Baluta <daniel.baluta@nxp.com>:

From: Daniel Baluta <daniel.baluta@nxp.com>

We need a way to send extra parameters to DSP firmware. In order to do
this, we introduce ext_data array at the end of ipc_stream_params.

With this new addition we can send compress parameters.

This requires SOF ABI bump.

Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:

By mistake a developer managed to create a 'corrupted' IPC4 firmware image which
loaded fine to the DSP and after boot it sent an IPC reply before we would have
received the FW_READY message.
It turned out that the image was an IPC3 firmware and the IPC reply was the IPC3
FW_READY notification message which got understood as an IPC4 reply message due
to the difference between the two IPC mechanism.

This caused a NULL pointer dereference since the reply memory will be allocated
after the FW_READY message.

To make sure this will not bite again, skip any spurious reply messages before
the FW_READY.

Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:

There is no need to decouple a decoupled stream twice.
Keep the decoupling in hda_link_stream_assign() only as it is going to be
executed in all cases.

Drop the outdated comment from hda_link_dma_hw_params() as well since the code
has changed around it.

We have sanity checks for byte controls and if any of the fail the locally
allocated scontrol->ipc_control_data is freed up, but not set to NULL.

On a rollback path of the error the higher level code will also try to free
the scontrol->ipc_control_data which will eventually going to lead to
memory corruption as double freeing memory is not a good thing.

Fixes: b5cee8fe ("ASoC: SOF: topology: Make control parsing IPC agnostic")
Reported-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
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: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20220712130103.31514-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The current implementation of probes only supports IPC3 and should not be
loaded for other IPC implementation.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220712131022.1124-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:

In case of a firmware crash we force the DSP to be powered down and rebooted.
To make sure that the next boot is going to be clean, force the boot process to
skip the IMR booting and re-download the firmware.

Add new field to sof_ipc_stream_params in order to extend
stream params struct with extended data to store compress parameters.

Older kernel will still work this as they ext_data_length will always be
zero.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712141531.14599-5-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

After introducing extended parameters we need to forbid older firmware
versions to run with the current and future kernel versions.

Although in theory the communication protocol will still work the
semantics at application level are undefined. So, prevent this by
disallowing older firmwares to run with newer kernels.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712141531.14599-4-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

Allocate memory at the end of sof_ipc_stream_params to store
snd_compr_params in order to be sent them to SOF firmware.

This will help firmware correctly configure codecs parameters.

Notice, that we use 2 bytes from the reserved pool in order to store
the extended data length. This is compatible with older FWs where
there was no extended data.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712141531.14599-3-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

We need to extend sof_ipc_pcm_parmas with additional data in order
to send compress_params to SOF FW.

The extensions will be done at runtime so we need to dynamically
allocate pcm object of type struct sof_ipc_pcm_params.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712141531.14599-2-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

Call snd_hdac_ext_stream_decouple_locked() unconditionally in
hda_link_stream_assign(), the snd_hdac_ext_stream_decouple_locked() have
internal checks to avoid re-configuring.

There is no need to call snd_hdac_ext_stream_decouple() via
hda_link_dma_params() as the stream must have been set to decoupled when
it got assigned (even if it used local condition to call
snd_hdac_ext_stream_decouple_locked()).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220712131620.13365-3-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The comment in hda_link_dma_hw_params() is no longer valid as the dma_data
is set to NULL at system suspend as well.

Instead of rewording the comment to state the obvious: try to take the
hext_stream from the dma_data and if it is not set then assign a new one
and store it as dma_data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220712131620.13365-2-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The FSR (Firmware State Register) can be found at offset 0 in the SRAM and
it is holding information about the state of the ROM/FW.
In case of a boot failure it can be used to get the state where the boot
process got stuck, it does not itself contains error codes as such.

The error code (or the firmware state information) is stored in the next
soft register at offset 0x4.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220712125734.30512-2-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

'ret' is never used. Remove it and return 0 instead.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712123902.14696-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>