Takashi Iwai
94c1ceb043
ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()
...
snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).
This patch replaces with a safer version, scnprintf() for papering
over such a potential issue.
Fixes: 29c8e4398ftiwai@suse.de >
Link: https://lore.kernel.org/r/20220801165420.25978-4-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-08-05 12:57:24 +01:00
Pierre-Louis Bossart
e516995050
ASoC: SOF: Intel: hda: add sanity check on SSP index reported by NHLT
...
We should have a limited trust in the BIOS and verify that the SSP
index reported in NHLT is valid for each platform.
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/20220725195343.145603-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-25 22:37:00 +01:00
Pierre-Louis Bossart
321add801b
ASoC: SOF: Intel: hda-stream: test DMA buffer first in hw_params
...
We should be consistent and always test that the DMA buffer is
allocated before continuing with the hw_params setup.
Signed-off-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 >
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com >
Link: https://lore.kernel.org/r/20220715145216.277003-12-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-15 20:11:40 +01:00
Pierre-Louis Bossart
bdcf7926fa
ASoC: SOF: probes: rename assign/free callbacks as startup/shutdown
...
assign/free are not well aligned to usual conventions and specifically
not to the compressed ops that make use of the probe callbacks.
Use the more common startup/shutdown. No functional change beyond
renaming.
Signed-off-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 >
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com >
Link: https://lore.kernel.org/r/20220715145216.277003-11-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-15 20:11:38 +01:00
Pierre-Louis Bossart
054d1fd138
ASoC: SOF: Intel: hda: only fixup topology name if not set already
...
We do all kinds of renaming tricks that get in the way of kernel
parameter and DMI quirk overrides at a higher level.
Tested on UpExtreme board with
options snd-sof-pci tplg_filename=sof-hda-generic.tplg
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com >
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com >
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com >
Link: https://lore.kernel.org/r/20220715145216.277003-10-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-15 20:11:37 +01:00
Pierre-Louis Bossart
ef05eb575e
ASoC: SOF: Intel: hda: don't set fw_filename
...
The fw_filename is now set at a higher level and can be overridden by
kernel parameters or DMI quirks.
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com >
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com >
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com >
Link: https://lore.kernel.org/r/20220715145216.277003-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-15 20:11:36 +01:00
Peter Ujfalusi
27b196c19c
ASoC: SOF: Intel: atom: don't keep a temporary string in fixup_tplg_name
...
fixup_tplg_name() doesn't need to keep the string, allocated for
filename - it's temporary.
Inspired by similar change for hda:
commit b9088535e1yung-chuan.liao@linux.intel.com >
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com >
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com >
Link: https://lore.kernel.org/r/20220715145216.277003-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-15 20:11:35 +01:00
Yong Zhi
740e5d8713
ASoC: SOF: Intel: MTL: remove redundant snd_sof_dsp_read() call
...
Drop redundant CPA bit check after polling the same condition.
Fixes: 064520e8aechao.song@intel.com >
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com >
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com >
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com >
Signed-off-by: Yong Zhi <yong.zhi@intel.com >
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com >
Link: https://lore.kernel.org/r/20220715145216.277003-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-15 20:11:29 +01:00
Pierre-Louis Bossart
ba4c6a1a8f
ASoC: SOF: Intel: enable dmic handling with 2 or fewer SoundWire links
...
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/5966
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-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-15 17:10:57 +01:00
Bard Liao
2a1be12c4d
ASoC: SOF: Intel: add trigger callback into sdw_callback
...
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.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-13 14:26:14 +01:00
Mark Brown
4e90651e52
ASoC: SOF: Intel: hda: Correct Firmware State Register use
...
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.
2022-07-12 19:21:45 +01:00
Mark Brown
501935dae8
ASoC: SOF: Intel: Do not process IPC reply before firmware boot
...
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.
2022-07-12 19:21:42 +01:00
Mark Brown
274a3e6f98
ASoC: SOF: Intel: hda-dai: No need to decouple host/link DMA twice
...
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.
2022-07-12 19:21:41 +01:00
Peter Ujfalusi
fbabebfb26
ASoC: SOF: Intel: hda-dai: Do snd_hdac_ext_stream_decouple() only once
...
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.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-12 14:22:58 +01:00
Peter Ujfalusi
402355e6cd
ASoC: SOF: Intel: hda-dai: Drop misleading comment regarding dma_data
...
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.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-12 14:22:57 +01:00
Peter Ujfalusi
15d8370cf6
ASoC: SOF: Intel: hda: Correct the ROM/FW state reporting code
...
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.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-12 13:59:57 +01:00
Peter Ujfalusi
57724db17a
ASoC: SOF: Intel: hda: Introduce skip_imr_boot flag
...
Use a dedicated flag instead of directly checking the
sdev->system_suspend_target to decide if we need to skip IMR boot due to
too deep sleep state where the memory used for IMR booting will not retain
its content.
The skip_imr_boot flag will be set true during suspend if the target state
is deeper than S3 and reset back to false on successful boot to re-enable
IMR booting in shallower sleep states.
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/20220712120936.28072-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-12 13:45:05 +01:00
Peter Ujfalusi
1549a69b89
ASoC: SOF: Intel: mtl: Do not process IPC reply before firmware boot
...
It is not yet clear, but it is possible to create a firmware so broken
that it will send a reply message before a FW_READY message (it is not
yet clear if FW_READY will arrive later).
Since the reply_data is allocated only after the FW_READY message, this
will lead to a NULL pointer dereference if not filtered out.
Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com >
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20220712122357.31282-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-12 13:45:03 +01:00
Peter Ujfalusi
499cc881b0
ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot
...
It is not yet clear, but it is possible to create a firmware so broken
that it will send a reply message before a FW_READY message (it is not
yet clear if FW_READY will arrive later).
Since the reply_data is allocated only after the FW_READY message, this
will lead to a NULL pointer dereference if not filtered out.
The issue was reported with IPC4 firmware but the same condition is present
for IPC3.
Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com >
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20220712122357.31282-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-12 13:45:02 +01:00
Peter Ujfalusi
acacd9eefd
ASoC: SOF: Intel: cnl: Do not process IPC reply before firmware boot
...
It is not yet clear, but it is possible to create a firmware so broken
that it will send a reply message before a FW_READY message (it is not
yet clear if FW_READY will arrive later).
Since the reply_data is allocated only after the FW_READY message, this
will lead to a NULL pointer dereference if not filtered out.
The issue was reported with IPC4 firmware but the same condition is present
for IPC3.
Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com >
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20220712122357.31282-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-12 13:45:01 +01:00
Andy Shevchenko
65b6851d24
ASoC: SOF: Intel: byt: remove duplicating driver data retrieval
...
device_get_match_data() in ACPI case calls similar to acpi_match_device().
Hence there is no need to duplicate the call. Just assign what is in
the id->driver_data.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com >
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com >
Link: https://lore.kernel.org/r/20220705161102.76250-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-05 19:54:03 +01:00
Andy Shevchenko
0d356c186f
ASoC: SOF: Intel: bdw: remove duplicating driver data retrieval
...
device_get_match_data() in ACPI case calls similar to acpi_match_device().
Hence there is no need to duplicate the call. Just assign what is in
the id->driver_data.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com >
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com >
Link: https://lore.kernel.org/r/20220705161102.76250-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-07-05 19:54:01 +01:00
Mark Brown
644ed467c7
ASoC: Merge fixes
...
Needed for new development.
2022-06-22 12:14:20 +01:00
Mark Brown
57b06e9711
ASoC: SOF: Intel: fix resume from hibernate
...
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com >:
The enablement of IMR-based DSP boot helped reduce resume latency, but
unfortunately the context is not saved in S4 and S5 which leads to
multiple reports of boot failures.
This patchset forces a full firmware reload/reboot when resuming from
S4/S5 and restores functionality.
2022-06-18 00:18:16 +01:00
Pierre-Louis Bossart
b837870fe1
ASoC: SOF: Intel: mtl: remove use of __func__ in dev_dbg
...
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org >
Signed-off-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 >
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com >
Link: https://lore.kernel.org/r/20220616215351.135643-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org >
2022-06-17 10:46:40 +01:00
