lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z_dwaEMoavqsGOEw@hovoldconsulting.com>
Date: Thu, 10 Apr 2025 09:16:56 +0200
From: Johan Hovold <johan@...nel.org>
To: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc: broonie@...nel.org, perex@...ex.cz, tiwai@...e.com,
	krzysztof.kozlowski@...aro.org, linux-sound@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	dmitry.baryshkov@...aro.org, johan+linaro@...nel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH v5 2/5] ASoC: q6apm: add q6apm_get_hw_pointer helper

On Tue, Apr 08, 2025 at 09:07:27AM +0100, Srinivas Kandagatla wrote:
> On 07/04/2025 12:25, Johan Hovold wrote:
> > On Fri, Mar 14, 2025 at 05:47:57PM +0000, Srinivas Kandagatla wrote:
> >> From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
> >>
> >> Implement an helper function in q6apm to be able to read the current
> >> hardware pointer for both read and write buffers.
> >>
> >> This should help q6apm-dai to get the hardware pointer consistently
> >> without it doing manual calculation, which could go wrong in some race
> >> conditions.

> >> @@ -553,6 +567,8 @@ static int graph_callback(struct gpr_resp_pkt *data, void *priv, int op)
> >>   		rd_done = data->payload;
> >>   		phys = graph->tx_data.buf[hdr->token].phys;
> >>   		mutex_unlock(&graph->lock);
> >> +		/* token numbering starts at 0 */
> >> +		atomic_set(&graph->tx_data.hw_ptr, hdr->token + 1);
> >>   
> >>   		if (upper_32_bits(phys) == rd_done->buf_addr_msw &&
> >>   		    lower_32_bits(phys) == rd_done->buf_addr_lsw) {
> > 
> > 			graph->result.opcode = hdr->opcode;
> >                          graph->result.status = rd_done->status;
> >                          if (graph->cb)
> >                                  graph->cb(client_event, hdr->token, data->payload, graph->priv);
> >                  } else {
> >                          dev_err(dev, "RD BUFF Unexpected addr %08x-%08x\n", rd_done->buf_addr_lsw,
> >                                  rd_done->buf_addr_msw);
> >                  }
> > 
> > I just hit the following error on the T14s with 6.15-rc1 that I've never
> > seen before and which looks like it could be related to this series:

> Its unlikely, but the timings have changed here.
> I have not seen it either, but I will try to reproduce this with 6.15-rc1.
> > 
> > 	q6apm-dai 6800000.remoteproc:glink-edge:gpr:service@1:dais: RD BUFF Unexpected addr ffe0d200-00000001
> > 
> > Any ideas about what may be causing this?

> How easy is this to reproduce?

I've only noticed this error once on the first boot of 6.15-rc1, and it
does not seem to show up again now.

I did a fair bit of testing with this series on 6.14-rcs, but did not
check the logs while doing so (and there's nothing in the logs I still
have).

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ