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 <[email protected]> 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-8572bf745...@oss.qualcomm.com?part=1
