- Sound-open-firmware - mailman.alsa-project.org

Re: [PATCH] ASoC: SOF: ipc3-dtrace: uninitialized data in dfsentry_trace_filter_write()
by Mark Brown 17 Jul '23

17 Jul '23

On Fri, 07 Jul 2023 14:25:23 +0300, Dan Carpenter wrote: > This doesn't check how many bytes the simple_write_to_buffer() writes to > the buffer. The only thing that we know is that the first byte is > initialized and the last byte of the buffer is set to NUL. However > the middle bytes could be uninitialized. > > There is no need to use simple_write_to_buffer(). This code does not > support partial writes but instead passes "pos = 0" as the starting > offset regardless of what the user passed as "*ppos". Just use the > copy_from_user() function and initialize the whole buffer. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: ipc3-dtrace: uninitialized data in dfsentry_trace_filter_write() commit: 469e2f28c2cbee2430058c1c9bb6d1675d7195fb All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: (subset) [PATCH 1/2] ASoC: SOF: amd: add revision check for sending sha dma completion command
by Mark Brown 12 Jul '23

12 Jul '23

On Fri, 30 Jun 2023 12:35:42 +0530, Mastan Katragadda wrote: > ACP driver should send SHA DMA completion command to PSP module for RN > platform only. > Add a revision check for RN platform. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [2/2] ASoC: SOF: amd: refactor PSP smn_read commit: 2b48d170fb9965dda9d41edcb0bbfc9ee4c6584f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH 2/2] ASoC: SOF: amd: refactor PSP smn_read
by Mastan Katragadda 12 Jul '23

12 Jul '23

On 30/06/23 12:35, Mastan Katragadda wrote: > Use the read_poll_timeout marco for PSP smn_read calls. This patch has not been merged. > > Signed-off-by: Mastan Katragadda <Mastan.Katragadda(a)amd.com> > --- > sound/soc/sof/amd/acp.c | 34 +++++++++++++++------------------- > sound/soc/sof/amd/acp.h | 4 ++-- > 2 files changed, 17 insertions(+), 21 deletions(-) > > diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c > index afb505461ea1..c450931ae77e 100644 > --- a/sound/soc/sof/amd/acp.c > +++ b/sound/soc/sof/amd/acp.c > @@ -28,12 +28,14 @@ static int smn_write(struct pci_dev *dev, u32 smn_addr, u32 data) > return 0; > } > > -static int smn_read(struct pci_dev *dev, u32 smn_addr, u32 *data) > +static int smn_read(struct pci_dev *dev, u32 smn_addr) > { > + u32 data = 0; > + > pci_write_config_dword(dev, 0x60, smn_addr); > - pci_read_config_dword(dev, 0x64, data); > + pci_read_config_dword(dev, 0x64, &data); > > - return 0; > + return data; > } > > static void init_dma_descriptor(struct acp_dev_data *adata) > @@ -150,15 +152,13 @@ int configure_and_run_dma(struct acp_dev_data *adata, unsigned int src_addr, > static int psp_mbox_ready(struct acp_dev_data *adata, bool ack) > { > struct snd_sof_dev *sdev = adata->dev; > - int timeout; > + int ret; > u32 data; > > - for (timeout = ACP_PSP_TIMEOUT_COUNTER; timeout > 0; timeout--) { > - msleep(20); > - smn_read(adata->smn_dev, MP0_C2PMSG_114_REG, &data); > - if (data & MBOX_READY_MASK) > - return 0; > - } > + ret = read_poll_timeout(smn_read, data, data & MBOX_READY_MASK, MBOX_DELAY_US, > + ACP_PSP_TIMEOUT_US, false, adata->smn_dev, MP0_C2PMSG_114_REG); > + if (!ret) > + return 0; > > dev_err(sdev->dev, "PSP error status %x\n", data & MBOX_STATUS_MASK); > > @@ -177,23 +177,19 @@ static int psp_mbox_ready(struct acp_dev_data *adata, bool ack) > static int psp_send_cmd(struct acp_dev_data *adata, int cmd) > { > struct snd_sof_dev *sdev = adata->dev; > - int ret, timeout; > + int ret; > u32 data; > > if (!cmd) > return -EINVAL; > > /* Get a non-zero Doorbell value from PSP */ > - for (timeout = ACP_PSP_TIMEOUT_COUNTER; timeout > 0; timeout--) { > - msleep(MBOX_DELAY); > - smn_read(adata->smn_dev, MP0_C2PMSG_73_REG, &data); > - if (data) > - break; > - } > + ret = read_poll_timeout(smn_read, data, data, MBOX_DELAY_US, ACP_PSP_TIMEOUT_US, false, > + adata->smn_dev, MP0_C2PMSG_73_REG); > > - if (!timeout) { > + if (ret) { > dev_err(sdev->dev, "Failed to get Doorbell from MBOX %x\n", MP0_C2PMSG_73_REG); > - return -EINVAL; > + return ret; > } > > /* Check if PSP is ready for new command */ > diff --git a/sound/soc/sof/amd/acp.h b/sound/soc/sof/amd/acp.h > index dc624f727aa3..c3659dbc3745 100644 > --- a/sound/soc/sof/amd/acp.h > +++ b/sound/soc/sof/amd/acp.h > @@ -61,12 +61,12 @@ > #define HOST_BRIDGE_CZN 0x1630 > #define HOST_BRIDGE_RMB 0x14B5 > #define ACP_SHA_STAT 0x8000 > -#define ACP_PSP_TIMEOUT_COUNTER 5 > +#define ACP_PSP_TIMEOUT_US 1000000 > #define ACP_EXT_INTR_ERROR_STAT 0x20000000 > #define MP0_C2PMSG_114_REG 0x3810AC8 > #define MP0_C2PMSG_73_REG 0x3810A24 > #define MBOX_ACP_SHA_DMA_COMMAND 0x70000 > -#define MBOX_DELAY 1000 > +#define MBOX_DELAY_US 1000 > #define MBOX_READY_MASK 0x80000000 > #define MBOX_STATUS_MASK 0xFFFF >

1 0

Re: (subset) [PATCH 1/2] ASoC: SOF: amd: add revision check for sending sha dma completion command
by Mastan Katragadda 12 Jul '23

12 Jul '23

On 03/07/23 21:40, Mark Brown wrote: > On Mon, Jul 03, 2023 at 08:58:17PM +0530, Mukunda,Vijendar wrote: >> On 30/06/23 22:37, Mark Brown wrote: >>> Thanks! >>> >>> [1/2] ASoC: SOF: amd: add revision check for sending sha dma completion command >>> commit: b1db244c716fe300e36428aeb0874913d2e0a91d >> It looks like second patch didn't get merged in this series. >> Do we need to resend the second patch? > I don't know off hand what that second patch was. If it wasn't a bug > fix it'll just be waiting till after the merge window. Do I need to resend the second patch?

1 0

Re: (subset) [PATCH 1/2] ASoC: SOF: amd: add revision check for sending sha dma completion command
by Mark Brown 30 Jun '23

30 Jun '23

On Fri, 30 Jun 2023 12:35:42 +0530, Mastan Katragadda wrote: > ACP driver should send SHA DMA completion command to PSP module for RN > platform only. > Add a revision check for RN platform. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: SOF: amd: add revision check for sending sha dma completion command commit: b1db244c716fe300e36428aeb0874913d2e0a91d All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH] ASoC: SOF: amd: Add support for IPC with a reply_size set to zero
by Mark Brown 14 Jun '23

14 Jun '23

On Wed, 14 Jun 2023 16:07:05 +0530, Venkata Prasad Potturu wrote: > Add support for IPC tx_message with a reply_size set to zero, > return zero when message reply_size is zero at acp_dsp_ipc_get_reply(). > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: amd: Add support for IPC with a reply_size set to zero commit: fd01a15164a15328fd96f9ce820f0fc9f700f00b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH] ASoC: SOF: ipc4-topology: Improve unlocking of a mutex in sof_ipc4_widget_free()
by Pierre-Louis Bossart 12 Jun '23

12 Jun '23

On 6/10/23 06:36, Markus Elfring wrote: > From: Markus Elfring <elfring(a)users.sourceforge.net> > Date: Sat, 10 Jun 2023 12:40:09 +0200 > > Add a jump target so that a call of the function “mutex_unlock” > is stored only once in this function implementation. > > Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> > --- > sound/soc/sof/ipc4-topology.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c > index a4e1a70b607d..f0fd1dfa384e 100644 > --- a/sound/soc/sof/ipc4-topology.c > +++ b/sound/soc/sof/ipc4-topology.c > @@ -2300,8 +2300,7 @@ static int sof_ipc4_widget_free(struct snd_sof_dev *sdev, struct snd_sof_widget > if (pipeline->use_chain_dma) { > dev_warn(sdev->dev, "use_chain_dma set for scheduler %s", > swidget->widget->name); > - mutex_unlock(&ipc4_data->pipeline_state_mutex); > - return 0; > + goto unlock; > } > > header = SOF_IPC4_GLB_PIPE_INSTANCE_ID(swidget->instance_id); > @@ -2326,7 +2325,7 @@ static int sof_ipc4_widget_free(struct snd_sof_dev *sdev, struct snd_sof_widget > if (!pipeline->use_chain_dma) > ida_free(&fw_module->m_ida, swidget->instance_id); > } > - > +unlock: > mutex_unlock(&ipc4_data->pipeline_state_mutex); > > return ret; The change looks good but I am wondering if we need to print a dev_warn log which is already done on the sof_ipc4_widget_setup() path. This seems redundant. Ranjani, can we simplify?

1 0

[PATCH] ASoC: SOF: ipc4-topology: Use size_t for variable passed to kzalloc()
by Christophe JAILLET 02 Jun '23

02 Jun '23

struct_size() checks for overflow, but assigning its result to just a u32 may still overflow after a successful check. Use a size_t instead in order to be cleaner. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- Based on analysis from Dan Carpenter on another patch (see [1]). [1]: https://lore.kernel.org/all/00e84595-e2c9-48ea-8737-18da34eaafbf@kili.mount… --- sound/soc/sof/ipc4-topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c index db64e0cb8663..50faa4c88b97 100644 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -881,7 +881,7 @@ static int sof_ipc4_widget_setup_comp_process(struct snd_sof_widget *swidget) /* allocate memory for base config extension if needed */ if (process->init_config == SOF_IPC4_MODULE_INIT_CONFIG_TYPE_BASE_CFG_WITH_EXT) { struct sof_ipc4_base_module_cfg_ext *base_cfg_ext; - u32 ext_size = struct_size(base_cfg_ext, pin_formats, + size_t ext_size = struct_size(base_cfg_ext, pin_formats, swidget->num_input_pins + swidget->num_output_pins); base_cfg_ext = kzalloc(ext_size, GFP_KERNEL); -- 2.34.1

3 3

[PATCH v3 0/1] ASoC: SOF: add mt8188 audio support
by Trevor Wu 01 Jun '23

01 Jun '23

This series adds mt8188 audio support and dbg_dump callback for mt8186 and mt8188. Changes since v2: - resend the correct patch for adsp debug dump Changes since v1: - fix typo - adopt reviewer's suggestion Trevor Wu (1): ASoC: SOF: mediatek: add adsp debug dump sound/soc/sof/mediatek/mt8186/mt8186.c | 22 ++++++++++++++++++++++ sound/soc/sof/mediatek/mt8186/mt8186.h | 5 +++++ 2 files changed, 27 insertions(+) -- 2.18.0

3 3

Re: [PATCH v2 2/2] ASoC: SOF: mediatek: add adsp debug dump
by Trevor Wu (吳文良) 01 Jun '23

01 Jun '23

On Tue, 2023-05-30 at 15:12 +0100, Mark Brown wrote: > On Tue, May 23, 2023 at 10:59:33AM +0800, Trevor Wu wrote: > > Add mt8188 and mt8186 .dbg_dump callback to print some information > > when > > DSP panic occurs. > > This breaks an x86_64 allmodconfig build: > > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c: In > function ‘mt8186_adsp_dump’: > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:483:56: > error: ‘DSP_PDEBUGDATA’ undeclared (first use in this function); did > you mean ‘DSP_PDEBUGPC’? > 483 | dbg_data = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PDEBUGDATA); > | ^~~~~~ > ~~~~~~~~ > | DSP_PD > EBUGPC > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:483:56: > note: each undeclared identifier is reported only once for each > function it appears in > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:484:56: > error: ‘DSP_PDEBUGINST’ undeclared (first use in this function); did > you mean ‘DSP_PDEBUGPC’? > 484 | dbg_inst = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PDEBUGINST); > | ^~~~~~ > ~~~~~~~~ > | DSP_PD > EBUGPC > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:485:59: > error: ‘DSP_PDEBUGLS0STAT’ undeclared (first use in this function) > 485 | dbg_ls0stat = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PDEBUGLS0STAT); > | ^~~ > ~~~~~~~~~~~~~~ > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:486:58: > error: ‘DSP_PDEBUGSTATUS’ undeclared (first use in this function); > did you mean ‘DSP_PDEBUGPC’? > 486 | dbg_status = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PDEBUGSTATUS); > | ^~~~ > ~~~~~~~~~~~~ > | DSP_ > PDEBUGPC > /build/stage/linux/sound/soc/sof/mediatek/mt8186/mt8186.c:487:57: > error: ‘DSP_PFAULTINFO’ undeclared (first use in this function) > 487 | faultinfo = snd_sof_dsp_read(sdev, DSP_REG_BAR, > DSP_PFAULTINFO); > | ^~~~~ > ~~~~~~~~~ Sorry, I didn't notice that I missed the header which possibly caused by the wrong format-patch command. I checked the same patch in v1, and the header was included in the series. I will send v3 to resolve the problem. Thanks, Trevor

1 0