Re: [PATCH v3 1/2] dmaengine: qcom: gpi: Add trace event support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dmaengine: gpi: dropped trace events for coalesced interrupts
--

commit 0bb8d8f2455ccff160b2666b22bf4854db9eb970
Author: Praveen Talari <praveen.talari@oss.qualcomm.com>

dmaengine: qcom: gpi: Add trace event support

This commit adds tracepoint support to the Qualcomm GPI DMA engine driver
for structured runtime visibility into GPI DMA behavior. The events cover
channel command dispatch, IRQ type handling, and state transitions among
other details.

> diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
> index c41bfac65ddf3..fafe6ac848d94 100644
> --- a/drivers/dma/qcom/gpi.c
> +++ b/drivers/dma/qcom/gpi.c

[ ... ]

> @@ -841,6 +846,7 @@ static irqreturn_t gpi_handle_irq(int irq, void *data)
>  
>  	offset = GPII_n_CNTXT_TYPE_IRQ_OFFS(gpii->gpii_id);
>  	type = gpi_read_reg(gpii, gpii->regs + offset);
> +	trace_gpi_irq_status(gpii->gpi_dev->dev, gpii_id, type);

[Severity: Medium]
Will this miss tracing coalesced interrupts?

Because trace_gpi_irq_status() is placed strictly before the
do { ... } while (type); loop in gpi_handle_irq(), when new interrupts 
arrive during the handler execution and the loop re-reads the type 
register, the tracepoint is not called again for the newly read type.

Should the tracepoint be moved inside the loop, or placed iteratively
after every register read?

>  
>  	do {
>  		/* global gpii error */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926-add-trace-support-gpio-v3-0-8572bf7456b2@oss.qualcomm.com?part=1