From nobody Fri Aug 14 15:51:32 2026 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A94B8470450 for ; Fri, 14 Aug 2026 13:29:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786714184; cv=none; b=p12E+vJQ7/6/fE00cu5P7DfR+gHgaN38/FJ381zOcqPi0ADaeWCqJDlDL/V6iigJUx2CxHGLGXoUWXfce7q2STZLDkDZ3paACazgh9LyAuKbAPYJuaMXRCKdTHbvlYXkXmNA++yULpU5XluFVEvB6DwrBH+G8nBH50tTkF79ohw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786714184; c=relaxed/simple; bh=bAEWJXpWzPUhQYzyuDT8PPZLPevp6bNC7oyuUisHQ4M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CJxtT/eDejE3ihhbRgMgjADFjgkkC9+Wg2FcHp9G0hdGYEgxgmRj9L8+BfOKrFEOCtlg5UR289vvp/5Qm2pduAxbMp2q6DcuCfXzZl/YyzTtVQdPMtOKwlLJ4NPbardTRn2FPljFhmB3G6bM0kMJLh8PJwvAGbwjCMcUX4Gep/w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=soundtrack.io; spf=pass smtp.mailfrom=soundtrack.io; dkim=pass (2048-bit key) header.d=soundtrack.io header.i=@soundtrack.io header.b=KdnhGeAk; arc=none smtp.client-ip=209.85.208.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=soundtrack.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soundtrack.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soundtrack.io header.i=@soundtrack.io header.b="KdnhGeAk" Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-69edc72e513so120592a12.3 for ; Fri, 14 Aug 2026 06:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soundtrack.io; s=google; t=1786714181; x=1787318981; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=7YukWWHI9wYIN19FTJID+eUyg7sERpWkqr51k3rjwMM=; b=KdnhGeAkNTx7+k+h24Eo8EURKnbYW0NimO2PY5sC2V6IJzQYCYb+2nuoolLM81XhGT ul3Z0zOxzVMq2JOCXgCjrJbATa6MoAqan2PqzewZ0MTUiFP2hg1T/Be5ZEmEFdqPhxaG jUthOK+70LiCok/5/89QsoPnCrVtpffjaerLIB4VemLOhyaBVCpVGgwPJ0GCKkT3hSR5 5XatUcfnW7toY8WT0+Qr7R1p0HFa9iqYYsRSTUCKFsQNOBdwVu4bI8b78aeU0a01Na72 SamZnWWcGVnQhWATeWhS2N95M8OFU7tWPA2m84sWGkTU93vwHGX4jjmVlc4pzgiCSEYg uv8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786714181; x=1787318981; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7YukWWHI9wYIN19FTJID+eUyg7sERpWkqr51k3rjwMM=; b=mOh42ysJhb1lLJcDdbbdQYTbJgm5gluV7OU6Ol/2k+5KaRbBMuK65YKaKCtz9MpX4h X0xSU+DcDAktw1rt+B7vq7szDa+UAET++7Vm73mdu/7c8g7gpDOAx4dhpt8wQO2j3+XH rIAqwE0CNB/2Ojp3JyoY1NGc1rYmpkvZzf0argMKWdZhDtbtDEGzyCD+t2D59iztDJp+ 1JfUlfhG/790fnhsNVJhqcNWDQTIHAyKOOiGN1ht9TNNTDjnuOJriBBqVDSnH3M3aMqH eI4D6CCdLU0xKIdJkE6l0B1u15aQKQD3/TEavE8rma0HHIlD34Sd0BpJup29gJo9c5QB 38yw== X-Forwarded-Encrypted: i=1; AHgh+Rr//bha7tKmH7JHJkKkotKuip2gWXLAUoL3JCGOPw909ssR+ZGRe04ZubFjf4FYra6ThFJaifYPmLbtq1w=@vger.kernel.org X-Gm-Message-State: AOJu0YxnWyeGDKGxVJmujBNKfqmsI6quopbV146DVz9d14brfnJNOs08 ++2AGR6kNGtDn1ISo87NKi0uTTL0lW7dnhk7qew7N9gI4clQjRP5+rtvpJnTXoiZLeA= X-Gm-Gg: AR+sD10THJ+T3dUO8+/87TJlU/hfRc3rtYePvyoUmH0aMVrucxA7ugjTjf8A04QBstv MLRMyYvMsHN/XgI0Rnug9Lw+/sokgtszt7gwALD6BXdYR3VOe5xXzLEH13Qyr8c5P2aOAZZA/Ie fAiznFtvsXcl3fZX+Qf/gi52iTYSRPw8/USIQiXw73A0RVyzXye4SF3ggTqL0qyvKQn/tHkkPI8 gxywpBS4pvAfX4ctCzdCjIWz9UgjwjjnE1i03BnFFldi7HMH/Ms4T3/vpF4iV2V8amUVN+WYvSv MuTiW5xH934IjA6Haim2Rkjy3uB/+Zz9ckhQTDgQdQyIPaPBbNdGp2vA6fPkEUmAPgfUIdQdvA1 jcsj/eyHjPu9Wky84iMxvE8eWUWivCG2ULEs7fI8rf+1zVl4AuXgpeRbiKX8Pm4Q4nRFQuNrEqu NmIgRVaimQAXF7yVJpXbyx7y8hLRUX8+vFVL+QnqWdRkztZ7MCJLLHyFDyTIDn2aSeyZi4P8a87 pwDjl2Rk4YQz0isFBfIWrzWj62boBnjctQ/ZSAdwa6eFdG5YypyuVhS4A== X-Received: by 2002:a05:6402:1cc4:b0:6a1:d68:338a with SMTP id 4fb4d7f45d1cf-6a38a83ce95mr1450030a12.0.1786714180850; Fri, 14 Aug 2026 06:29:40 -0700 (PDT) Received: from Christians-MBP (31-209-40-223.cust.bredband2.com. [31.209.40.223]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a38c9d5eb2sm841941a12.5.2026.08.14.06.29.38 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 14 Aug 2026 06:29:40 -0700 (PDT) From: Christian Lugnberg To: vkoul@kernel.org Cc: Frank.Li@kernel.org, wens@kernel.org, jernej.skrabec@gmail.com, samuel@sholland.org, dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Christian Lugnberg , stable@vger.kernel.org Subject: [PATCH 1/2] dmaengine: sun6i: fix non-atomic read of DMA position registers Date: Fri, 14 Aug 2026 15:28:29 +0200 Message-ID: <20260814132906.70322-2-christian.lugnberg@soundtrack.io> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260814132906.70322-1-christian.lugnberg@soundtrack.io> References: <20260814132906.70322-1-christian.lugnberg@soundtrack.io> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable sun6i_get_chan_size() reads DMA_CHAN_LLI_ADDR and DMA_CHAN_CUR_CNT in two separate readl() calls with no synchronisation between them: pos =3D readl(pchan->base + DMA_CHAN_LLI_ADDR); bytes =3D readl(pchan->base + DMA_CHAN_CUR_CNT); DMA_CHAN_LLI_ADDR holds the physical address of the *next* descriptor the engine will load once the current one completes. DMA_CHAN_CUR_CNT holds the remaining byte count for the *current* descriptor. If the DMA engine advances to the next LLI entry between the two reads, pos becomes stale: it still points to what was the next descriptor at the time of the first read, but that descriptor is now the current one and CUR_CNT reflects its initial (full) byte count. The subsequent virtual-chain walk starts one entry too early and accumulates an extra full period's worth of bytes into the residue estimate. For ALSA cyclic buffers the over-counted residue can reach the full buffer size, causing the computed playback position to appear to jump backward to near zero. The ALSA PCM core treats such a backward discontinuity in hw_ptr as evidence that the buffer has underrun and declares an xrun. On the Barix IPAM400 (Allwinner H3, kernel 6.12) this manifests as audible glitches accompanied by spurious xrun log entries, confirmed by two independent observations: First, the ALSA buffer in the affected configuration is 2 seconds deep with a 500 ms refill period (the interval at which the player software wakes up to top up the buffer). For a real underrun to occur the player would have to stall for the full 2 seconds without writing any audio =E2=80=94 effecti= vely impossible under normal scheduling conditions. Yet xruns are observed regularly. Second, the underrun duration reported by the kernel at xrun time is ~30 =C2=B5s, roughly one audio sample at 44100 Hz. A genuine drain of a 2 second buffer cannot resolve in 30 =C2=B5s; only a phantom position jump caused by a register read race can produce such a number. Observed on a 44100 Hz stereo S16_LE stream: $ cat /proc/asound/Codec/pcm0p/sub0/status state: XRUN delay: 0 avail: 88200 avail_max: 22514 The avail_max of 22514 frames (511 ms) matches exactly one ALSA period =E2= =80=94 the amount added by starting the LLI chain walk one entry too early. The race window itself is narrow. Each DMA descriptor covers approximately 88 samples (~2 ms at 44100 Hz), so the engine advances to a new descriptor roughly every 2 ms. The two readl() calls must straddle that exact boundary for the corruption to occur, which explains why the bug is intermittent. The bug is further confirmed by the xrun_debug bit 2 toggle (jiffies position validation). With it enabled xruns cease immediately and do not return; clearing it causes xruns to reappear within minutes. This on/off reproducibility isolates the fault to the hw_ptr position reporting path; the DMA engine itself is functioning correctly, as evidenced by hw_ptr advancing at a steady 44100 frames/sec between events: $ echo 4 > /proc/asound/Codec/pcm0p/xrun_debug # xruns stop $ echo 0 > /proc/asound/Codec/pcm0p/xrun_debug # xruns return Fix this by re-reading DMA_CHAN_LLI_ADDR after DMA_CHAN_CUR_CNT and retrying if the value changed. This double-read pattern guarantees that both registers were sampled during the same descriptor interval. The cost is at most one extra readl() pair per call in the racy case, which occurs only at descriptor boundaries (~every 2 ms) and is negligible. Fixes: a90e173f3faf ("dmaengine: sun6i: Add cyclic capability") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg --- drivers/dma/sun6i-dma.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c index f47a326dd7ff..04fe1f5042e9 100644 --- a/drivers/dma/sun6i-dma.c +++ b/drivers/dma/sun6i-dma.c @@ -354,8 +354,10 @@ static size_t sun6i_get_chan_size(struct sun6i_pchan *= pchan) size_t bytes; dma_addr_t pos; =20 - pos =3D readl(pchan->base + DMA_CHAN_LLI_ADDR); - bytes =3D readl(pchan->base + DMA_CHAN_CUR_CNT); + do { + pos =3D readl(pchan->base + DMA_CHAN_LLI_ADDR); + bytes =3D readl(pchan->base + DMA_CHAN_CUR_CNT); + } while (pos !=3D readl(pchan->base + DMA_CHAN_LLI_ADDR)); =20 if (pos =3D=3D LLI_LAST_ITEM) return bytes; --=20 2.54.0 (Apple Git-156) From nobody Fri Aug 14 15:51:32 2026 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5A1EE471428 for ; Fri, 14 Aug 2026 13:29:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786714188; cv=none; b=hV/xeTKUmuP84NwmLW7ScYEp/tAjUL8RI1mAEQyFufM4y+YxnQNzUD+ZhhGZUaogljwshf33Emweotnk5w2cbahoPxytSVY3utYqWlugCC9K0F3+xkxf3r0R7W6xyguYooEaImswOaE0+hGcigbpRORObbdAc4n+PM7ZzCOS2D0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786714188; c=relaxed/simple; bh=Z0VrxfrQOACZu83EOUXJrOYZAwJOj58+oO60WgCClXg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NKUXGUtl+yqReQQuNa2sI2FdmuUa2lgLCocqT3DU/Q3CuId7uhP34eM9sv3ilOra41XR4XBIm5v2woIKVyC01u+WRmthw9wlVJA2aEr0tLyjfIxgAEai568ssikdHOqk/Vehvdm0ReO9AFECmeG7LYGI4CCvhrDLjZqbPKtL6/o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=soundtrack.io; spf=pass smtp.mailfrom=soundtrack.io; dkim=pass (2048-bit key) header.d=soundtrack.io header.i=@soundtrack.io header.b=mkkNGFOR; arc=none smtp.client-ip=209.85.208.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=soundtrack.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soundtrack.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soundtrack.io header.i=@soundtrack.io header.b="mkkNGFOR" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-6a18ef236ecso192410a12.2 for ; Fri, 14 Aug 2026 06:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soundtrack.io; s=google; t=1786714185; x=1787318985; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Ctx57rLzTDeEjtgOib9aUyoQxqr6yVBe4ltDl2pGqk0=; b=mkkNGFOREuXai3iI7Q06uuOc15j2r4vG61uOPFAIYtI8yZB2T47KxbOcw4FDz6pTAF TaOdLVTF4M3XBR/FxDvITpIrIvbxrSjddeJTjUi0SmGKBxzeFmkJWiGyQC2QCD+DcqHK plsneJVBV5sS2+i/0lQc4HpVp0+qxwDDVFNb34/0mcCIhR7xfFroabVmxsdC+qHPRZpR N0+6UxoS3E1XgXZbo2NqUrcirUo7X9kcUB8SSkYiB4INVDDqvpnHJYXekpiHfcZ/iYqK zPcfBP3otkr1deRzp7sUuaIVly6D0J3xSuRU3MjYc5yAL4c6p2otrJ7jhtZ6kbV/2jOL Bd0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786714185; x=1787318985; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Ctx57rLzTDeEjtgOib9aUyoQxqr6yVBe4ltDl2pGqk0=; b=oDrMZa6wJAyc9UhZtfV4Zer5kMmEugvHp1+4T72IGnO27JfU5Xya5HDEfNXFHDi9Gv yxzqE+2n1TqFPWP5rWrhdRsg/F7V8spu/rEbuMpzINh1BzhxbOJ3E9iq6NsuryP8ypnf no8WbqF1P0hvLMitzwUkU2V/sFw+UxLXEmpnHwsXOla4GTJfdUdoLjDoZUULUoWLlM3Z Wwx0NJ7caddxVpEvuGj5MgSLC7S31EGufJuJo0D0v1EBlAlwqsNcpVZAtAtvXmGmJBIJ QPmNnlHcG9o7vfPgLpDBv1F/EMU5CZcP+3HhmWpPjOqAL8AIIl49VtQDSHMR1+z0++I2 OepQ== X-Forwarded-Encrypted: i=1; AHgh+RryjBY6TRDM0CIMBSgf1jGSFxPt45FH4hL4ptncB6xAodOM150m+e52mxlmOyTNyuZdZ8c4r4ZMAIyey8w=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5CzvFy8wxRwhp6ekWw/e+M3OcrLy611rSKa9qxY4VxU2IUrHs HcxLFwiulcj0OrZHrAwE+dfBU3lLkOFWZELIsCzic65WZMuC5QbaB20NliJlO3q2zXFQiYQzTes 2RvS28MU= X-Gm-Gg: AR+sD11w1xAhiqZXTIUmdozQDogzMMKZn7rAWeMlKbnZVdek+35U1ZdP0oOrnW98B2q y+9baAxeRwhWMaZpKcJj809PHUI2JspbEtUN4bIdHD2I8ju/Edb1Qr3A0r/QvGIrvO0AA0s9Bpf F3NzS2KILW6xgjV+7ATYJ5pNCd4kWbww8RwmYix76wwonk7daZRc6kZouRoGqmc62hTw07NVonU eKbvMejAtWi98RjZl3IKk8xEAbQkd9hhxjpWgIJMQTCfRQHBR6PLNokOrFVbeD74suTZX4Pa25g ppghj4Vu8sUoioIyTGFGaI7Lfa313DGHyVKIlsQcDRgmpiGXygMEIhQDNwxg9o5GITlUeqqnz9a FurKPPzSnj9yUiYVV3ldWJ1M4Qhu6xUGiDRa1qu/eHK2pxWC0VIQnhiPsm3HEqzOWRATx5xCAAT 4LyyMEouOTtU/7rnOsZ6v2eNZV6tEkAy9UooguRcTX01nDunGFIToywjfrrY6hQPpOCOG898UTS M2rUmJRZRmN3FpMDow6yoHTw3rmzO40PycSXsuK7DHe4L6xHl+gDk4NJ4tKiZA8Fvfr X-Received: by 2002:a05:6402:3881:b0:6a1:faeb:c519 with SMTP id 4fb4d7f45d1cf-6a38a97752amr1392217a12.3.1786714184680; Fri, 14 Aug 2026 06:29:44 -0700 (PDT) Received: from Christians-MBP (31-209-40-223.cust.bredband2.com. [31.209.40.223]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a38c9d5eb2sm841941a12.5.2026.08.14.06.29.42 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 14 Aug 2026 06:29:44 -0700 (PDT) From: Christian Lugnberg To: vkoul@kernel.org Cc: Frank.Li@kernel.org, wens@kernel.org, jernej.skrabec@gmail.com, samuel@sholland.org, dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Christian Lugnberg , stable@vger.kernel.org Subject: [PATCH 2/2] dmaengine: sun6i: fix null pointer dereference in sun6i_dma_tx_status Date: Fri, 14 Aug 2026 15:28:30 +0200 Message-ID: <20260814132906.70322-3-christian.lugnberg@soundtrack.io> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260814132906.70322-1-christian.lugnberg@soundtrack.io> References: <20260814132906.70322-1-christian.lugnberg@soundtrack.io> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" sun6i_dma_tx_status() calls vchan_find_desc() to look up the virtual descriptor for a given cookie, then unconditionally dereferences the result via to_sun6i_desc() before checking whether the pointer is NULL: vd =3D vchan_find_desc(&vchan->vc, cookie); txd =3D to_sun6i_desc(&vd->tx); /* vd may be NULL here */ if (vd) { for (lli =3D txd->v_lli; ...) vchan_find_desc() returns NULL when the descriptor has already been completed or is in-flight on a physical channel and no longer present in the virtual channel's descriptor list. Dereferencing NULL via to_sun6i_desc() in that case is undefined behaviour and will oops on any architecture that faults on NULL pointer access. Move the to_sun6i_desc() call inside the if (vd) block so it is only reached when vd is known to be non-NULL: vd =3D vchan_find_desc(&vchan->vc, cookie); if (vd) { struct sun6i_desc *txd =3D to_sun6i_desc(&vd->tx); for (lli =3D txd->v_lli; ...) Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DM= A controller") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg --- drivers/dma/sun6i-dma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c index 04fe1f5042e9..7704b016aed8 100644 --- a/drivers/dma/sun6i-dma.c +++ b/drivers/dma/sun6i-dma.c @@ -981,7 +981,6 @@ static enum dma_status sun6i_dma_tx_status(struct dma_c= han *chan, struct sun6i_pchan *pchan =3D vchan->phy; struct sun6i_dma_lli *lli; struct virt_dma_desc *vd; - struct sun6i_desc *txd; enum dma_status ret; unsigned long flags; size_t bytes =3D 0; @@ -993,9 +992,9 @@ static enum dma_status sun6i_dma_tx_status(struct dma_c= han *chan, spin_lock_irqsave(&vchan->vc.lock, flags); =20 vd =3D vchan_find_desc(&vchan->vc, cookie); - txd =3D to_sun6i_desc(&vd->tx); =20 if (vd) { + struct sun6i_desc *txd =3D to_sun6i_desc(&vd->tx); for (lli =3D txd->v_lli; lli !=3D NULL; lli =3D lli->v_lli_next) bytes +=3D lli->len; } else if (!pchan || !pchan->desc) { --=20 2.54.0 (Apple Git-156)