Re: [PATCH v3 1/2] dmaengine: qcom: gpi: Add trace event support
flat view
From: sashiko-bot@kernel.org
Date: 2026-09-25 21:02:34
Also in:
dmaengine
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
@@ -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