From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C682BC624D4 for ; Thu, 3 Sep 2026 07:54:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: References:In-Reply-To:Cc:To:Subject:From:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=c8T2Njzyz3yEJP1R/mNABjPhthHC1+HDoQboRIddQ28=; b=BEKO8pE1t5HmeZ JID/l3/Vt9Gap31omM4Z27IaEIFqPX+LKtOmIS8vjTLG89lte0yslk4XIw8m6xa20pI4rOn4wKom7 CE6IkqSxgKiwToJWW7mwlnVIOKRuwFTuCWxOk6zW+dFvtrsS+4XIpDGBYWcQ32HmE+xtWZrBjP60a h8ks/BMtnTSMRU2NgnUAebPlwL03QSCFDjha4NOxOhYz8kfJGIfPf8OK2JAM7pSwgZau7YsYhX9X2 2QKtROekm5AlnlxQHGXf1tLaobEDlXCYwQ7B3S6HoW1Ju5mOX6jdSpRHURU+Ok5w3R6kKMZlGNasA o3tZ+X3ymu63wAr/266A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x22HF-0000000Ghph-0tIN; Thu, 03 Sep 2026 07:54:29 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x22HD-0000000GhpM-3fyA for linux-amlogic@lists.infradead.org; Thu, 03 Sep 2026 07:54:27 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 780C2410A3; Thu, 3 Sep 2026 07:54:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D582A1F000E9; Thu, 3 Sep 2026 07:54:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788422067; bh=qf9Tn+bVBs74GFd2TUZ1Wsh5sBVkHOm+fXWdGHGqv9Q=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=epOJbXewM2oIGJOfQXzUoAdm4SBtuIgW4+jz9lSKy2UT1+8pmxh5k+9PMaXBze3Ep cQc+qiwXogyuPLG8nn3YrOClAPt9aMsDZZg1o0xnJv0tjNtiYl135/O3hTIWZ7hvaQ SNECD/RcFg3uGfUMTQjrH3DiHeF/hJGEVUyUCcTK7vyay6FTHt7fi96YHZ2nqPflfo Irae/ZyzB71gRQqAAC+MZ8o69ddzy0dwY+liXOKOLfiir1QkJkQOjmh/ZAJXqoStec vfYyu5rMo/5Kw9UJjvO2N6KuxfU7pYAIADbeDM/0Wwa5Ak2MVNIefnZg1StbSFgS+u /FYceF5PJRkFA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v12 2/3] dmaengine: amlogic: Add general DMA driver for A9 To: "Xianwei Zhao" Cc: conor+dt@kernel.org, neil.armstrong@linaro.org, devicetree@vger.kernel.org, Frank.Li@kernel.org, robh@kernel.org, dmaengine@vger.kernel.org, linux-amlogic@lists.infradead.org, vkoul@kernel.org In-Reply-To: <20260903-amlogic-dma-v12-2-f769bc344056@amlogic.com> References: <20260903-amlogic-dma-v12-0-f769bc344056@amlogic.com> <20260903-amlogic-dma-v12-2-f769bc344056@amlogic.com> Date: Thu, 03 Sep 2026 07:54:26 +0000 Message-Id: <20260903075426.D582A1F000E9@smtp.kernel.org> X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg OCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIFVubWFuYWdlZCB3b3Jr cXVldWUgYGZyZWVfd3FgIGxlYWtzIG9uIHByb2JlIGVycm9ycywgYW5kIHByZW1hdHVyZSB0YXNr bGV0IHRlcm1pbmF0aW9uIGluIGByZW1vdmUoKWAgY2F1c2VzIFVzZS1BZnRlci1GcmVlIGR1ZSB0 byBkZXZyZXMgb3JkZXJpbmcuCi0gW0hpZ2hdIEJpdHdpc2UgT1JpbmcgYSBob3N0LWVuZGlhbiBj b25zdGFudCBpbnRvIGEgbGl0dGxlLWVuZGlhbiAoYF9fbGUzMmApIHZhcmlhYmxlIGNhdXNlcyBk YXRhIGNvcnJ1cHRpb24gb24gYmlnLWVuZGlhbiBhcmNoaXRlY3R1cmVzLgotIFtIaWdoXSBGYWls dXJlIHRvIGNoZWNrIGBwbGF0Zm9ybV9nZXRfaXJxKClgIHJldHVybiB2YWx1ZSBicmVha3MgZGVm ZXJyZWQgcHJvYmluZy4KLSBbSGlnaF0gYGFtbF9jaGFuLT5zdGF0dXNgIGFuZCBgYW1sX2NoYW4t PmVycl9udW1gIGFyZSB1cGRhdGVkIG91dHNpZGUgdGhlIGNoYW5uZWwgbG9jayBpbiBgYW1sX2Rt YV90ZXJtaW5hdGVfYWxsKClgLgotIFtIaWdoXSBgYW1sX2RtYV9jaGFuX3Jlc3VtZSgpYCBmYWls cyB0byBzdGFydCBkZXNjcmlwdG9ycyB0aGF0IHdlcmUgaXNzdWVkIHdoaWxlIHRoZSBjaGFubmVs IHdhcyBwYXVzZWQuCi0gW01lZGl1bV0gYGFtbF9kbWFfdHhfc3RhdHVzKClgIGZhaWxzIHRvIGNo ZWNrIHRoZSBgZGVzY19zdWJtaXR0ZWRgIGxpc3QsIGxlYWRpbmcgdG8gZmFsc2UgZXJyb3JzIGFu ZCBpbmNvcnJlY3QgcmVzaWR1ZS4KLSBbTWVkaXVtXSBUaGUgaW50ZXJydXB0IGhhbmRsZXIgdW5j b25kaXRpb25hbGx5IHJldHVybnMgYElSUV9IQU5ETEVEYCwgZGVmZWF0aW5nIHNwdXJpb3VzIGlu dGVycnVwdCBkZXRlY3Rpb24uCi0gW0xvd10gVGFraW5nIHRoZSBhZGRyZXNzIG9mIGEgbWVtYmVy IG9mIGEgcG90ZW50aWFsbHkgTlVMTCBwb2ludGVyIGluIGBhbWxfZG1hX3Rlcm1pbmF0ZV9hbGwo KWAuCi0tCgpjb21taXQgMDM4ZTM3MmI2NjIyN2ViYjZkMjRhMzg0OWM5OGQ1ODhmZjBlZGNkNwpB dXRob3I6IFhpYW53ZWkgWmhhbyA8eGlhbndlaS56aGFvQGFtbG9naWMuY29tPgoKZG1hZW5naW5l OiBhbWxvZ2ljOiBBZGQgZ2VuZXJhbCBETUEgZHJpdmVyIGZvciBBOQoKQW1sb2dpYyBBOSBTb0Nz IGluY2x1ZGUgYSBnZW5lcmFsLXB1cnBvc2UgRE1BIGNvbnRyb2xsZXIgdGhhdCBjYW4gYmUgdXNl ZApieSBtdWx0aXBsZSBwZXJpcGhlcmFscywgc3VjaCBhcyBJMkMgUElPIGFuZCBJM0MuIEVhY2gg cGVyaXBoZXJhbCBncm91cAppcyBhc3NvY2lhdGVkIHdpdGggYSBkZWRpY2F0ZWQgRE1BIGNoYW5u ZWwgaW4gaGFyZHdhcmUuCgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2RtYS9hbWxvZ2ljLWRtYS5j IGIvZHJpdmVycy9kbWEvYW1sb2dpYy1kbWEuYwo+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0Cj4gaW5k ZXggMDAwMDAwMDAwMDAwMC4uYjY2ODdkOTgwOTZjMwo+IC0tLSAvZGV2L251bGwKPiArKysgYi9k cml2ZXJzL2RtYS9hbWxvZ2ljLWRtYS5jCgpbIC4uLiBdCgo+ICtzdGF0aWMgZW51bSBkbWFfc3Rh dHVzIGFtbF9kbWFfdHhfc3RhdHVzKHN0cnVjdCBkbWFfY2hhbiAqY2hhbiwKPiArCQkJCQkgZG1h X2Nvb2tpZV90IGNvb2tpZSwKPiArCQkJCQkgc3RydWN0IGRtYV90eF9zdGF0ZSAqdHhzdGF0ZSkK PiArewo+ICsJc3RydWN0IGFtbF9kbWFfY2hhbiAqYW1sX2NoYW4gPSB0b19hbWxfZG1hX2NoYW4o Y2hhbik7Cj4gKwlzdHJ1Y3QgYW1sX2RtYV9kZXYgKmFtbF9kbWEgPSBhbWxfY2hhbi0+YW1sX2Rt YTsKPiArCXN0cnVjdCBhbWxfZG1hX2Rlc2MgKmFtbF9kZXNjID0gTlVMTDsKPiArCXN0cnVjdCB2 aXJ0X2RtYV9kZXNjICp2ZDsKPiArCXUzMiByZXNpZHVlID0gMCwgZG9uZSA9IDA7Cj4gKwl1bnNp Z25lZCBsb25nIGZsYWdzOwo+ICsJZW51bSBkbWFfc3RhdHVzIHJldDsKPiArCj4gKwlyZXQgPSBk bWFfY29va2llX3N0YXR1cyhjaGFuLCBjb29raWUsIHR4c3RhdGUpOwo+ICsJaWYgKHJldCA9PSBE TUFfQ09NUExFVEUpCj4gKwkJcmV0dXJuIHJldDsKPiArCj4gKwlpZiAoYW1sX2NoYW4tPnN0YXR1 cyA9PSBETUFfUEFVU0VEKQo+ICsJCXJldCA9IERNQV9QQVVTRUQ7Cj4gKwlpZiAoIXR4c3RhdGUp Cj4gKwkJcmV0dXJuIHJldDsKPiArCj4gKwlzcGluX2xvY2tfaXJxc2F2ZSgmYW1sX2NoYW4tPnZj aGFuLmxvY2ssIGZsYWdzKTsKPiArCXZkID0gdmNoYW5fZmluZF9kZXNjKCZhbWxfY2hhbi0+dmNo YW4sIGNvb2tpZSk7Cj4gKwlpZiAodmQpIHsKPiArCQlhbWxfZGVzYyA9IHRvX2FtbF9kbWFfZGVz Yyh2ZCk7Cj4gKwkJcmVzaWR1ZSA9IGFtbF9kZXNjLT5kYXRhX2xlbjsKPiArCX0gZWxzZSBpZiAo YW1sX2NoYW4tPmN1cl9kZXNjICYmIGFtbF9jaGFuLT5jdXJfZGVzYy0+dmQudHguY29va2llID09 IGNvb2tpZSkgewoKW1NldmVyaXR5OiBNZWRpdW1dCkRvZXMgdGhpcyBza2lwIGNoZWNraW5nIHRo ZSBkZXNjX3N1Ym1pdHRlZCBsaXN0PwoKV2hlbiBhIERNQSBjbGllbnQgc3VibWl0cyBhIGRlc2Ny aXB0b3IgdmlhIHR4X3N1Ym1pdCgpIGJ1dCBoYXMgbm90IHlldAppc3N1ZWQgaXQgdmlhIGlzc3Vl X3BlbmRpbmcoKSwgdGhlIGRlc2NyaXB0b3IgcmVzaWRlcyBpbiBkZXNjX3N1Ym1pdHRlZC4KU2lu Y2UgdmNoYW5fZmluZF9kZXNjKCkgb25seSBzZWFyY2hlcyB0aGUgZGVzY19pc3N1ZWQgbGlzdCwg Y2FsbGluZwpkbWFfdHhfc3RhdHVzKCkgZHVyaW5nIHRoaXMgd2luZG93IHdpbGwgZmFpbCB0byBm aW5kIHRoZSBkZXNjcmlwdG9yLgpUaGlzIGNhdXNlcyB0aGUgZHJpdmVyIHRvIGluY29ycmVjdGx5 IGxvZyBhICJjb29raWUgZXJyb3IiIGFuZCByZXR1cm4gYQpyZXNpZHVlIG9mIDAgaW5zdGVhZCBv ZiB0aGUgZnVsbCB0cmFuc2ZlciBsZW5ndGguCgo+ICsJCWFtbF9kZXNjID0gYW1sX2NoYW4tPmN1 cl9kZXNjOwo+ICsJCXJlZ21hcF9yZWFkKGFtbF9kbWEtPnJlZ21hcCwgYW1sX2NoYW4tPnJlZ19v ZmZzICsgUkNIX1JEX0xFTiwgJmRvbmUpOwo+ICsJCXJlc2lkdWUgPSBhbWxfZGVzYy0+ZGF0YV9s ZW4gLSBkb25lOwo+ICsJfSBlbHNlIHsKPiArCQlkZXZfZXJyKGFtbF9kbWEtPmRtYV9kZXZpY2Uu ZGV2LCAiY29va2llIGVycm9yXG4iKTsKPiArCX0KPiArCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUo JmFtbF9jaGFuLT52Y2hhbi5sb2NrLCBmbGFncyk7Cj4gKwlkbWFfc2V0X3Jlc2lkdWUodHhzdGF0 ZSwgcmVzaWR1ZSk7Cj4gKwo+ICsJcmV0dXJuIHJldDsKPiArfQoKWyAuLi4gXQoKPiArc3RhdGlj IHN0cnVjdCBkbWFfYXN5bmNfdHhfZGVzY3JpcHRvciAqYW1sX2RtYV9wcmVwX3NsYXZlX3NnCj4g KwkJKHN0cnVjdCBkbWFfY2hhbiAqY2hhbiwgc3RydWN0IHNjYXR0ZXJsaXN0ICpzZ2wsCj4gKwkJ dW5zaWduZWQgaW50IHNnX2xlbiwgZW51bSBkbWFfdHJhbnNmZXJfZGlyZWN0aW9uIGRpcmVjdGlv biwKPiArCQl1bnNpZ25lZCBsb25nIGZsYWdzLCB2b2lkICpjb250ZXh0KQo+ICt7CgpbIC4uLiBd Cgo+ICsJCS8qIHNldCBkbWEgYWRkcmVzcyBhbmQgbGVuIHRvIHNnbGluayovCj4gKwkJc2dfbGlu ay0+YWRkcl9sb3cgPSBjcHVfdG9fbGUzMihsb3dlcl8zMl9iaXRzKHBhZGRyKSk7Cj4gKwkJc2df bGluay0+YWRkcl9oaWdoID0gY3B1X3RvX2xlMzIodXBwZXJfMzJfYml0cyhwYWRkcikpOwo+ICsJ CXNnX2xpbmstPmN0bCA9IGNwdV90b19sZTMyKEZJRUxEX1BSRVAoTElOS19MRU4sIGF2YWlsKSk7 Cj4gKwo+ICsJCWFtbF9kZXNjLT5kYXRhX2xlbiArPSBzZ19kbWFfbGVuKHNnKTsKPiArCQlzZ19s aW5rKys7Cj4gKwl9Cj4gKwo+ICsJLyogdGhlIGxhc3Qgc2cgc2V0IGVvYyBmbGFnICovCj4gKwlz Z19saW5rLS07Cj4gKwlzZ19saW5rLT5jdGwgfD0gTElOS19FT0M7CgpbU2V2ZXJpdHk6IEhpZ2hd CkNhbiB0aGlzIGNhdXNlIGRhdGEgY29ycnVwdGlvbiBvbiBiaWctZW5kaWFuIGFyY2hpdGVjdHVy ZXM/CgpUaGUgc2dfbGluay0+Y3RsIGZpZWxkIGlzIHBvcHVsYXRlZCBhcyBhbiBfX2xlMzIsIGJ1 dCB0aGUgTElOS19FT0MgZmxhZwood2hpY2ggZXZhbHVhdGVzIHRvIGEgaG9zdC1lbmRpYW4gQklU KDI4KSkgaXMgYml0d2lzZSBPUidkIGRpcmVjdGx5IGludG8gaXQuCk9uIGJpZy1lbmRpYW4gc3lz dGVtcywgdGhpcyB3aWxsIHNldCB0aGUgd3JvbmcgYml0IGluIHRoZSBtZW1vcnktYmFja2VkCmRl c2NyaXB0b3IsIG1lYW5pbmcgdGhlIGhhcmR3YXJlIHdvbid0IHNlZSB0aGUgRW5kLU9mLUNoYWlu IGZsYWcgYW5kIG1heQpmZXRjaCB1bmluaXRpYWxpemVkIG1lbW9yeS4gV3JhcHBpbmcgaXQgd2l0 aCBjcHVfdG9fbGUzMihMSU5LX0VPQykgd291bGQKcHJldmVudCB0aGlzLgoKPiArCj4gKwlyZXR1 cm4gdmNoYW5fdHhfcHJlcCgmYW1sX2NoYW4tPnZjaGFuLCAmYW1sX2Rlc2MtPnZkLCBmbGFncyk7 Cj4gK30KClsgLi4uIF0KCj4gK3N0YXRpYyBpbnQgYW1sX2RtYV9jaGFuX3Jlc3VtZShzdHJ1Y3Qg ZG1hX2NoYW4gKmNoYW4pCj4gK3sKPiArCXN0cnVjdCBhbWxfZG1hX2NoYW4gKmFtbF9jaGFuID0g dG9fYW1sX2RtYV9jaGFuKGNoYW4pOwo+ICsJc3RydWN0IGFtbF9kbWFfZGV2ICphbWxfZG1hID0g YW1sX2NoYW4tPmFtbF9kbWE7Cj4gKwl1bnNpZ25lZCBsb25nIGZsYWdzOwo+ICsKPiArCXNwaW5f bG9ja19pcnFzYXZlKCZhbWxfY2hhbi0+dmNoYW4ubG9jaywgZmxhZ3MpOwo+ICsJcmVnbWFwX2Ns ZWFyX2JpdHMoYW1sX2RtYS0+cmVnbWFwLCBhbWxfY2hhbi0+cmVnX29mZnMgKyBSQ0hfQ0ZHLCBD RkdfUEFVU0UpOwo+ICsJYW1sX2NoYW4tPnN0YXR1cyA9IGFtbF9jaGFuLT5wcmVfc3RhdHVzOwo+ ICsJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmYW1sX2NoYW4tPnZjaGFuLmxvY2ssIGZsYWdzKTsK CltTZXZlcml0eTogSGlnaF0KRG9lcyBhbWxfZG1hX2NoYW5fcmVzdW1lKCkgZmFpbCB0byBzdGFy dCBkZXNjcmlwdG9ycyB0aGF0IHdlcmUgaXNzdWVkIHdoaWxlCnRoZSBjaGFubmVsIHdhcyBwYXVz ZWQ/CgpXaGVuIGEgY2hhbm5lbCBpcyBwYXVzZWQsIGFtbF9jaGFuLT5zdGF0dXMgaXMgc2V0IHRv IERNQV9QQVVTRUQuIEFueQpzdWJzZXF1ZW50IGNhbGxzIHRvIGFtbF9kbWFfaXNzdWVfcGVuZGlu ZygpIGFwcGVuZCBkZXNjcmlwdG9ycyB0byB0aGUKZGVzY19pc3N1ZWQgbGlzdCBidXQgcmV0dXJu IGltbWVkaWF0ZWx5IGZyb20gYW1sX2RtYV9zdGFydCgpIHdpdGhvdXQKdHJpZ2dlcmluZyB0aGUg aGFyZHdhcmUuCgpCZWNhdXNlIGFtbF9kbWFfY2hhbl9yZXN1bWUoKSByZXN0b3JlcyBhbWxfY2hh bi0+c3RhdHVzIHRvIERNQV9DT01QTEVURSBidXQKZG9lcyBub3QgY2hlY2sgaWYgdGhlIHBlbmRp bmcgcXVldWUgaXMgbm9uLWVtcHR5LCBkZXNjcmlwdG9ycyBxdWV1ZWQgZHVyaW5nCnRoZSBwYXVz ZSB3aWxsIHN0YWxsIGluZGVmaW5pdGVseS4KCj4gKwo+ICsJcmV0dXJuIDA7Cj4gK30KPiArCj4g K3N0YXRpYyBpbnQgYW1sX2RtYV90ZXJtaW5hdGVfYWxsKHN0cnVjdCBkbWFfY2hhbiAqY2hhbikK PiArewo+ICsJc3RydWN0IGFtbF9kbWFfY2hhbiAqYW1sX2NoYW4gPSB0b19hbWxfZG1hX2NoYW4o Y2hhbik7Cj4gKwlzdHJ1Y3QgYW1sX2RtYV9kZXYgKmFtbF9kbWEgPSBhbWxfY2hhbi0+YW1sX2Rt YTsKPiArCWludCBjaGFuX2lkID0gYW1sX2NoYW4tPmNoYW5faWQ7Cj4gKwlzdHJ1Y3QgdmlydF9k bWFfZGVzYyAqY3VyX3ZkOwo+ICsJdW5zaWduZWQgbG9uZyBmbGFnczsKPiArCUxJU1RfSEVBRCho ZWFkKTsKPiArCj4gKwlzcGluX2xvY2tfaXJxc2F2ZSgmYW1sX2NoYW4tPnZjaGFuLmxvY2ssIGZs YWdzKTsKPiArCXJlZ21hcF9zZXRfYml0cyhhbWxfZG1hLT5yZWdtYXAsIGFtbF9jaGFuLT5yZWdf b2ZmcyArIFJDSF9DRkcsIENGR19QQVVTRSk7Cj4gKwlyZWdtYXBfc2V0X2JpdHMoYW1sX2RtYS0+ cmVnbWFwLCBhbWxfY2hhbi0+cmVnX29mZnMgKyBSQ0hfQ0ZHLCBDRkdfQ0xFQVIpOwo+ICsKPiAr CWlmIChhbWxfY2hhbi0+ZGlyZWN0aW9uID09IERNQV9NRU1fVE9fREVWKQo+ICsJCXJlZ21hcF9z ZXRfYml0cyhhbWxfZG1hLT5yZWdtYXAsIFJDSF9JTlRfTUFTSywgQklUKGNoYW5faWQpKTsKPiAr CWVsc2UgaWYgKGFtbF9jaGFuLT5kaXJlY3Rpb24gPT0gRE1BX0RFVl9UT19NRU0pCj4gKwkJcmVn bWFwX3NldF9iaXRzKGFtbF9kbWEtPnJlZ21hcCwgV0NIX0lOVF9NQVNLLCBCSVQoY2hhbl9pZCkp Owo+ICsKPiArCXJlZ21hcF9jbGVhcl9iaXRzKGFtbF9kbWEtPnJlZ21hcCwgYW1sX2NoYW4tPnJl Z19vZmZzICsgUkNIX0NGRywgQ0ZHX1BBVVNFKTsKPiArCXJlZ21hcF9jbGVhcl9iaXRzKGFtbF9k bWEtPnJlZ21hcCwgYW1sX2NoYW4tPnJlZ19vZmZzICsgUkNIX0NGRywgQ0ZHX0NMRUFSKTsKPiAr Cj4gKwl2Y2hhbl9nZXRfYWxsX2Rlc2NyaXB0b3JzKCZhbWxfY2hhbi0+dmNoYW4sICZoZWFkKTsK PiArCWN1cl92ZCA9ICZhbWxfY2hhbi0+Y3VyX2Rlc2MtPnZkOwo+ICsJYW1sX2NoYW4tPmN1cl9k ZXNjID0gTlVMTDsKPiArCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmFtbF9jaGFuLT52Y2hhbi5s b2NrLCBmbGFncyk7CgpbU2V2ZXJpdHk6IExvd10KSXMgdGhpcyB0YWtpbmcgdGhlIGFkZHJlc3Mg b2YgYSBtZW1iZXIgZnJvbSBhIHBvdGVudGlhbGx5IE5VTEwgcG9pbnRlcj8KCklmIHRoZXJlIGlz IG5vIGFjdGl2ZSB0cmFuc2ZlciwgYW1sX2NoYW4tPmN1cl9kZXNjIGlzIE5VTEwuIENhbGN1bGF0 aW5nCiZhbWxfY2hhbi0+Y3VyX2Rlc2MtPnZkIGJlZm9yZSBjaGVja2luZyBmb3IgTlVMTCBpcyB1 bmRlZmluZWQgYmVoYXZpb3IgaW4Kc3RhbmRhcmQgQy4gV2hpbGUgaXQgc2FmZWx5IGV2YWx1YXRl cyB0byBOVUxMIGluIHRoZSBrZXJuZWwgYmVjYXVzZSB2ZCBpcwphdCBvZmZzZXQgMCBhbmQgR0ND IGlzIGludm9rZWQgd2l0aCAtZm5vLWRlbGV0ZS1udWxsLXBvaW50ZXItY2hlY2tzLCB0aGlzCmRp dmVyZ2VzIGZyb20gdGhlIGNvcnJlY3QgcGF0dGVybiB1c2VkIGVsc2V3aGVyZSBpbiB0aGUgZHJp dmVyLgoKPiArCWlmIChjdXJfdmQpCj4gKwkJYW1sX2RtYV9mcmVlX2Rlc2MoY3VyX3ZkKTsKPiAr Cj4gKwl2Y2hhbl9kbWFfZGVzY19mcmVlX2xpc3QoJmFtbF9jaGFuLT52Y2hhbiwgJmhlYWQpOwo+ ICsKPiArCWFtbF9jaGFuLT5zdGF0dXMgPSBETUFfQ09NUExFVEU7Cj4gKwlhbWxfY2hhbi0+ZXJy X251bSA9IDA7CgpbU2V2ZXJpdHk6IEhpZ2hdCklzIHRoZXJlIGEgcmFjZSBjb25kaXRpb24gaGVy ZSBzaW5jZSBhbWxfY2hhbi0+c3RhdHVzIGFuZCBlcnJfbnVtIGFyZQp1cGRhdGVkIG91dHNpZGUg b2YgdGhlIHZjaGFuLmxvY2s/CgpJZiBhIGNvbmN1cnJlbnQgYW1sX2RtYV9pc3N1ZV9wZW5kaW5n KCkgYWNxdWlyZXMgdGhlIGxvY2sgaW1tZWRpYXRlbHkgYWZ0ZXIKaXQgaXMgZHJvcHBlZCBoZXJl LCBpdCB3aWxsIHNlZSB0aGUgc3RhbGUgYW1sX2NoYW4tPnN0YXR1cyAoZS5nLiwKRE1BX1BBVVNF RCkuIGFtbF9kbWFfc3RhcnQoKSB3aWxsIHRoZW4gcmV0dXJuIHdpdGhvdXQgdG91Y2hpbmcgdGhl IGhhcmR3YXJlLgp0ZXJtaW5hdGVfYWxsIHdpbGwgc3Vic2VxdWVudGx5IHNldCB0aGUgc3RhdHVz IHRvIERNQV9DT01QTEVURSwgYnV0IHRoZQpuZXdseSBxdWV1ZWQgdHJhbnNmZXIgd2lsbCBiZSBw ZXJtYW5lbnRseSBzdHVjay4KCj4gKwo+ICsJcmV0dXJuIDA7Cj4gK30KClsgLi4uIF0KCj4gK3N0 YXRpYyBpcnFyZXR1cm5fdCBhbWxfZG1hX2ludGVycnVwdF9oYW5kbGVyKGludCBpcnEsIHZvaWQg KmRldl9pZCkKPiArewoKWyAuLi4gXQoKPiArCQl2Y2hhbl9jb29raWVfY29tcGxldGUoJmFtbF9k ZXNjLT52ZCk7Cj4gKwkJYW1sX2NoYW4tPmN1cl9kZXNjID0gTlVMTDsKPiArCQlhbWxfZG1hX3N0 YXJ0KGFtbF9jaGFuKTsKPiArCQlzcGluX3VubG9jaygmYW1sX2NoYW4tPnZjaGFuLmxvY2spOwo+ ICsJfQo+ICsKPiArCXJldHVybiBJUlFfSEFORExFRDsKCltTZXZlcml0eTogTWVkaXVtXQpEb2Vz IHRoaXMgdW5jb25kaXRpb25hbGx5IHJldHVybiBJUlFfSEFORExFRCBldmVuIHdoZW4gbm8gaGFy ZHdhcmUgYml0cwp3ZXJlIHNldD8KCklmIHRoZSBpbnRlcnJ1cHQgaGFuZGxlciBpcyBpbnZva2Vk IGJ1dCB0aGUgaGFyZHdhcmUgZGlkIG5vdCBhc3NlcnQgdGhlCmludGVycnVwdCwgdGhlIHByb2Nl c3NpbmcgbG9vcHMgYXJlIHNraXBwZWQsIGJ1dCB0aGUgZnVuY3Rpb24gc3RpbGwgcmV0dXJucwpJ UlFfSEFORExFRC4gVGhpcyB2aW9sYXRlcyB0aGUgSVJRIEFQSSBjb250cmFjdCAod2hpY2ggcmVx dWlyZXMgcmV0dXJuaW5nCklSUV9OT05FKSBhbmQgcHJldmVudHMgdGhlIGNvcmUgSVJRIHN1YnN5 c3RlbSBmcm9tIGRldGVjdGluZyBhbmQgZGlzYWJsaW5nCnNwdXJpb3VzIGludGVycnVwdCBzdG9y bXMuCgo+ICt9CgpbIC4uLiBdCgo+ICtzdGF0aWMgaW50IGFtbF9kbWFfcHJvYmUoc3RydWN0IHBs YXRmb3JtX2RldmljZSAqcGRldikKPiArewo+ICsJc3RydWN0IGRldmljZV9ub2RlICpucCA9IHBk ZXYtPmRldi5vZl9ub2RlOwo+ICsJc3RydWN0IGRtYV9kZXZpY2UgKmRtYV9kZXY7Cj4gKwlzdHJ1 Y3QgYW1sX2RtYV9kZXYgKmFtbF9kbWE7Cj4gKwlpbnQgcmV0LCBpLCBsZW47Cj4gKwl1MzIgY2hh bl9ucjsKPiArCj4gKwljb25zdCBzdHJ1Y3QgcmVnbWFwX2NvbmZpZyBhbWxfcmVnbWFwX2NvbmZp ZyA9IHsKPiArCQkucmVnX2JpdHMgPSAzMiwKPiArCQkudmFsX2JpdHMgPSAzMiwKPiArCQkucmVn X3N0cmlkZSA9IDQsCj4gKwkJLm1heF9yZWdpc3RlciA9IDB4MzAwMCwKPiArCX07Cj4gKwo+ICsJ cmV0ID0gb2ZfcHJvcGVydHlfcmVhZF91MzIobnAsICJkbWEtY2hhbm5lbHMiLCAmY2hhbl9ucik7 Cj4gKwlpZiAocmV0KQo+ICsJCXJldHVybiBkZXZfZXJyX3Byb2JlKCZwZGV2LT5kZXYsIHJldCwg ImZhaWxlZCB0byByZWFkIGRtYS1jaGFubmVsc1xuIik7Cj4gKwlpZiAoY2hhbl9uciA+IChNQVhf Q0hBTl9JRCAqIDIpKQo+ICsJCXJldHVybiBkZXZfZXJyX3Byb2JlKCZwZGV2LT5kZXYsIC1FSU5W QUwsICJkbWEtY2hhbm5lbHMgdW51c3VhbFxuIik7Cj4gKwo+ICsJbGVuID0gc2l6ZW9mKHN0cnVj dCBhbWxfZG1hX2RldikgKyBzaXplb2Yoc3RydWN0IGFtbF9kbWFfY2hhbikgKiBjaGFuX25yOwo+ ICsJYW1sX2RtYSA9IGRldm1fa3phbGxvYygmcGRldi0+ZGV2LCBsZW4sIEdGUF9LRVJORUwpOwo+ ICsJaWYgKCFhbWxfZG1hKQo+ICsJCXJldHVybiAtRU5PTUVNOwo+ICsKPiArCWFtbF9kbWEtPmZy ZWVfd3EgPSBhbGxvY19vcmRlcmVkX3dvcmtxdWV1ZSgiYW1sX2RtYV9mcmVlIiwgMCk7Cj4gKwlp ZiAoIWFtbF9kbWEtPmZyZWVfd3EpCj4gKwkJcmV0dXJuIC1FTk9NRU07Cj4gKwo+ICsJYW1sX2Rt YS0+Y2hhbl9uciA9IGNoYW5fbnI7Cj4gKwo+ICsJYW1sX2RtYS0+YmFzZSA9IGRldm1fcGxhdGZv cm1faW9yZW1hcF9yZXNvdXJjZShwZGV2LCAwKTsKPiArCWlmIChJU19FUlIoYW1sX2RtYS0+YmFz ZSkpCj4gKwkJcmV0dXJuIFBUUl9FUlIoYW1sX2RtYS0+YmFzZSk7CgpbU2V2ZXJpdHk6IEhpZ2hd CkRvZXMgdGhpcyBsZWFrIGZyZWVfd3Egb24gcHJvYmUgZXJyb3JzPwoKSWYgZGV2bV9wbGF0Zm9y bV9pb3JlbWFwX3Jlc291cmNlKCkgb3IgYW55IHN1YnNlcXVlbnQgcmVnaXN0cmF0aW9uIGZhaWxz CmR1cmluZyBwcm9iZSwgdGhlIGZ1bmN0aW9uIHJldHVybnMgYW4gZXJyb3Igd2l0aG91dCBjYWxs aW5nCmRlc3Ryb3lfd29ya3F1ZXVlKGFtbF9kbWEtPmZyZWVfd3EpLCBsZWFraW5nIHRoZSB3b3Jr cXVldWUgbWVtb3J5LgoKPiArCj4gKwlhbWxfZG1hLT5yZWdtYXAgPSBkZXZtX3JlZ21hcF9pbml0 X21taW8oJnBkZXYtPmRldiwgYW1sX2RtYS0+YmFzZSwKPiArCQkJCQkJJmFtbF9yZWdtYXBfY29u ZmlnKTsKPiArCWlmIChJU19FUlJfT1JfTlVMTChhbWxfZG1hLT5yZWdtYXApKQo+ICsJCXJldHVy biBQVFJfRVJSKGFtbF9kbWEtPnJlZ21hcCk7Cj4gKwo+ICsJYW1sX2RtYS0+Y2xrID0gZGV2bV9j bGtfZ2V0X2VuYWJsZWQoJnBkZXYtPmRldiwgTlVMTCk7Cj4gKwlpZiAoSVNfRVJSKGFtbF9kbWEt PmNsaykpCj4gKwkJcmV0dXJuIFBUUl9FUlIoYW1sX2RtYS0+Y2xrKTsKPiArCj4gKwlhbWxfZG1h LT5pcnEgPSBwbGF0Zm9ybV9nZXRfaXJxKHBkZXYsIDApOwo+ICsKPiArCWFtbF9kbWEtPnBkZXYg PSBwZGV2Owo+ICsJYW1sX2RtYS0+ZG1hX2RldmljZS5kZXYgPSAmcGRldi0+ZGV2OwoKW1NldmVy aXR5OiBIaWdoXQpEb2VzIHRoaXMgYnJlYWsgZGVmZXJyZWQgcHJvYmluZyBieSBtaXNzaW5nIGEg Ym91bmRzIGNoZWNrIG9uIHRoZSByZXR1cm5lZApJUlEgdmFsdWU/CgpwbGF0Zm9ybV9nZXRfaXJx KCkgY2FuIHJldHVybiBhIG5lZ2F0aXZlIGVycm9yIGNvZGUgc3VjaCBhcyAtRVBST0JFX0RFRkVS LgpCeSB1bmNvbmRpdGlvbmFsbHkgYXNzaWduaW5nIGl0IHRvIGFtbF9kbWEtPmlycSBhbmQgcGFz c2luZyBpdCB0bwpkZXZtX3JlcXVlc3RfaXJxKCksIHRoZSBJUlEgY29yZSB3aWxsIHJlamVjdCB0 aGUgbmVnYXRpdmUgSVJRIHZhbHVlIGFuZApyZXR1cm4gLUVJTlZBTC4gVGhpcyBvdmVyd3JpdGVz IHRoZSAtRVBST0JFX0RFRkVSIGVycm9yIGFuZCBjYXVzZXMgYQpwZXJtYW5lbnQgZmFpbHVyZSB0 byBwcm9iZS4KCj4gKwo+ICsJZG1hX2RldiA9ICZhbWxfZG1hLT5kbWFfZGV2aWNlOwoKWyAuLi4g XQoKPiArc3RhdGljIHZvaWQgYW1sX2RtYV9yZW1vdmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAq cGRldikKPiArewo+ICsJc3RydWN0IGFtbF9kbWFfZGV2ICphbWxfZG1hID0gcGxhdGZvcm1fZ2V0 X2RydmRhdGEocGRldik7Cj4gKwlzdHJ1Y3QgYW1sX2RtYV9jaGFuICphbWxfY2hhbiA9IE5VTEw7 Cj4gKwlpbnQgaTsKPiArCj4gKwlvZl9kbWFfY29udHJvbGxlcl9mcmVlKCgmcGRldi0+ZGV2KS0+ b2Zfbm9kZSk7Cj4gKwo+ICsJcmVnbWFwX3dyaXRlKGFtbF9kbWEtPnJlZ21hcCwgUkNIX0lOVF9N QVNLLCBJTlRfTUFTSyk7Cj4gKwlyZWdtYXBfd3JpdGUoYW1sX2RtYS0+cmVnbWFwLCBXQ0hfSU5U X01BU0ssIElOVF9NQVNLKTsKPiArCj4gKwlmb3IgKGkgPSAwOyBpIDwgTUFYX0NIQU5fSUQ7IGkr Kykgewo+ICsJCWFtbF9jaGFuID0gYW1sX2RtYS0+YW1sX3JjaFtpXTsKPiArCQlpZiAoYW1sX2No YW4pCj4gKwkJCXRhc2tsZXRfa2lsbCgmYW1sX2NoYW4tPnZjaGFuLnRhc2spOwo+ICsJCWFtbF9j aGFuID0gYW1sX2RtYS0+YW1sX3djaFtpXTsKPiArCQlpZiAoYW1sX2NoYW4pCj4gKwkJCXRhc2ts ZXRfa2lsbCgmYW1sX2NoYW4tPnZjaGFuLnRhc2spOwo+ICsJfQo+ICsJZGVzdHJveV93b3JrcXVl dWUoYW1sX2RtYS0+ZnJlZV93cSk7Cj4gK30KCltTZXZlcml0eTogSGlnaF0KSXMgdGhlcmUgYSB1 c2UtYWZ0ZXItZnJlZSByYWNlIGNvbmRpdGlvbiBkdXJpbmcgZHJpdmVyIHVuYmluZD8KClRoZSB0 YXNrbGV0cyBhcmUga2lsbGVkIGhlcmUsIGJ1dCBiZWNhdXNlIGRldm1fcmVxdWVzdF9pcnEoKSB3 YXMgdXNlZApkdXJpbmcgcHJvYmUsIHRoZSBJUlEgbGluZSByZW1haW5zIGFjdGl2ZSB1bnRpbCBk ZXZyZXMgcnVucyBhZnRlcgphbWxfZG1hX3JlbW92ZSgpIHJldHVybnMuCgpXaXRob3V0IGEgY2Fs bCB0byBzeW5jaHJvbml6ZV9pcnEoKSwgYW4gaW4tZmxpZ2h0IGludGVycnVwdCBvbiBhbm90aGVy IENQVQpjb3VsZCBzY2hlZHVsZSB0aGUgdGFza2xldCBhZ2FpbiBhZnRlciB0YXNrbGV0X2tpbGwo KSBoYXMgZmluaXNoZWQuIFdoZW4KZGV2cmVzIHN1YnNlcXVlbnRseSBmcmVlcyB0aGUgZHJpdmVy J3MgbWVtb3J5LCB0aGUgZGVsYXllZCB0YXNrbGV0IHdpbGwKZXhlY3V0ZSBvbiBmcmVlZCBtZW1v cnkuCgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNo c2V0LzIwMjYwOTAzLWFtbG9naWMtZG1hLXYxMi0wLWY3NjliYzM0NDA1NkBhbWxvZ2ljLmNvbT9w YXJ0PTIKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxp bnV4LWFtbG9naWMgbWFpbGluZyBsaXN0CmxpbnV4LWFtbG9naWNAbGlzdHMuaW5mcmFkZWFkLm9y ZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFtbG9n aWMK From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC1AC375F88; Thu, 3 Sep 2026 07:54:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788422069; cv=none; b=Bpov6wfVp5Q5WvPJ1rEiMZ/aAbgMVD0dbqPOkBJNnb7oSco1M69DangtTI4hhFhRt9TwV7cl3miUxjpp3ddAkQ6IY6ZDLQ74eeI+U+oh9158X6Yp3TOt1YS90MzXloG1jvqfuL0hGWHq4WDMiWtDTHywZ7G5PPaDBjTq7EXF1mA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788422069; c=relaxed/simple; bh=5teIvxg5u9K0ClCWiNOyZr1F6owUQ7BEZazX5JMuq/8=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=TZBbGkomxuZ1hm6HUu0mwT/X7A7lWrOQgWcFjb6RZk58UvvfmMlgqTE85VIT3Nb8moVcv9mmgXtyXreqWf3OpmTuz7yk6Vlb4SUaxnvSpzFWn8Nn2FMl3zk5TLMqDCNKEMeZMLbXhg/TviYV9LPa8M74seHcHa5fMytEA5GX2b8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=epOJbXew; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="epOJbXew" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D582A1F000E9; Thu, 3 Sep 2026 07:54:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788422067; bh=qf9Tn+bVBs74GFd2TUZ1Wsh5sBVkHOm+fXWdGHGqv9Q=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=epOJbXewM2oIGJOfQXzUoAdm4SBtuIgW4+jz9lSKy2UT1+8pmxh5k+9PMaXBze3Ep cQc+qiwXogyuPLG8nn3YrOClAPt9aMsDZZg1o0xnJv0tjNtiYl135/O3hTIWZ7hvaQ SNECD/RcFg3uGfUMTQjrH3DiHeF/hJGEVUyUCcTK7vyay6FTHt7fi96YHZ2nqPflfo Irae/ZyzB71gRQqAAC+MZ8o69ddzy0dwY+liXOKOLfiir1QkJkQOjmh/ZAJXqoStec vfYyu5rMo/5Kw9UJjvO2N6KuxfU7pYAIADbeDM/0Wwa5Ak2MVNIefnZg1StbSFgS+u /FYceF5PJRkFA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v12 2/3] dmaengine: amlogic: Add general DMA driver for A9 Reply-To: sashiko-reviews@lists.linux.dev To: "Xianwei Zhao" Cc: conor+dt@kernel.org, neil.armstrong@linaro.org, devicetree@vger.kernel.org, Frank.Li@kernel.org, robh@kernel.org, dmaengine@vger.kernel.org, linux-amlogic@lists.infradead.org, vkoul@kernel.org In-Reply-To: <20260903-amlogic-dma-v12-2-f769bc344056@amlogic.com> References: <20260903-amlogic-dma-v12-0-f769bc344056@amlogic.com> <20260903-amlogic-dma-v12-2-f769bc344056@amlogic.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 03 Sep 2026 07:54:26 +0000 Message-Id: <20260903075426.D582A1F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 8 potential issue(= s) to consider: - [High] Unmanaged workqueue `free_wq` leaks on probe errors, and premature= tasklet termination in `remove()` causes Use-After-Free due to devres orde= ring. - [High] Bitwise ORing a host-endian constant into a little-endian (`__le32= `) variable causes data corruption on big-endian architectures. - [High] Failure to check `platform_get_irq()` return value breaks deferred= probing. - [High] `aml_chan->status` and `aml_chan->err_num` are updated outside the= channel lock in `aml_dma_terminate_all()`. - [High] `aml_dma_chan_resume()` fails to start descriptors that were issue= d while the channel was paused. - [Medium] `aml_dma_tx_status()` fails to check the `desc_submitted` list, = leading to false errors and incorrect residue. - [Medium] The interrupt handler unconditionally returns `IRQ_HANDLED`, def= eating spurious interrupt detection. - [Low] Taking the address of a member of a potentially NULL pointer in `am= l_dma_terminate_all()`. -- commit 038e372b66227ebb6d24a3849c98d588ff0edcd7 Author: Xianwei Zhao dmaengine: amlogic: Add general DMA driver for A9 Amlogic A9 SoCs include a general-purpose DMA controller that can be used by multiple peripherals, such as I2C PIO and I3C. Each peripheral group is associated with a dedicated DMA channel in hardware. > diff --git a/drivers/dma/amlogic-dma.c b/drivers/dma/amlogic-dma.c > new file mode 100644 > index 0000000000000..b6687d98096c3 > --- /dev/null > +++ b/drivers/dma/amlogic-dma.c [ ... ] > +static enum dma_status aml_dma_tx_status(struct dma_chan *chan, > + dma_cookie_t cookie, > + struct dma_tx_state *txstate) > +{ > + struct aml_dma_chan *aml_chan =3D to_aml_dma_chan(chan); > + struct aml_dma_dev *aml_dma =3D aml_chan->aml_dma; > + struct aml_dma_desc *aml_desc =3D NULL; > + struct virt_dma_desc *vd; > + u32 residue =3D 0, done =3D 0; > + unsigned long flags; > + enum dma_status ret; > + > + ret =3D dma_cookie_status(chan, cookie, txstate); > + if (ret =3D=3D DMA_COMPLETE) > + return ret; > + > + if (aml_chan->status =3D=3D DMA_PAUSED) > + ret =3D DMA_PAUSED; > + if (!txstate) > + return ret; > + > + spin_lock_irqsave(&aml_chan->vchan.lock, flags); > + vd =3D vchan_find_desc(&aml_chan->vchan, cookie); > + if (vd) { > + aml_desc =3D to_aml_dma_desc(vd); > + residue =3D aml_desc->data_len; > + } else if (aml_chan->cur_desc && aml_chan->cur_desc->vd.tx.cookie =3D= =3D cookie) { [Severity: Medium] Does this skip checking the desc_submitted list? When a DMA client submits a descriptor via tx_submit() but has not yet issued it via issue_pending(), the descriptor resides in desc_submitted. Since vchan_find_desc() only searches the desc_issued list, calling dma_tx_status() during this window will fail to find the descriptor. This causes the driver to incorrectly log a "cookie error" and return a residue of 0 instead of the full transfer length. > + aml_desc =3D aml_chan->cur_desc; > + regmap_read(aml_dma->regmap, aml_chan->reg_offs + RCH_RD_LEN, &done); > + residue =3D aml_desc->data_len - done; > + } else { > + dev_err(aml_dma->dma_device.dev, "cookie error\n"); > + } > + spin_unlock_irqrestore(&aml_chan->vchan.lock, flags); > + dma_set_residue(txstate, residue); > + > + return ret; > +} [ ... ] > +static struct dma_async_tx_descriptor *aml_dma_prep_slave_sg > + (struct dma_chan *chan, struct scatterlist *sgl, > + unsigned int sg_len, enum dma_transfer_direction direction, > + unsigned long flags, void *context) > +{ [ ... ] > + /* set dma address and len to sglink*/ > + sg_link->addr_low =3D cpu_to_le32(lower_32_bits(paddr)); > + sg_link->addr_high =3D cpu_to_le32(upper_32_bits(paddr)); > + sg_link->ctl =3D cpu_to_le32(FIELD_PREP(LINK_LEN, avail)); > + > + aml_desc->data_len +=3D sg_dma_len(sg); > + sg_link++; > + } > + > + /* the last sg set eoc flag */ > + sg_link--; > + sg_link->ctl |=3D LINK_EOC; [Severity: High] Can this cause data corruption on big-endian architectures? The sg_link->ctl field is populated as an __le32, but the LINK_EOC flag (which evaluates to a host-endian BIT(28)) is bitwise OR'd directly into it. On big-endian systems, this will set the wrong bit in the memory-backed descriptor, meaning the hardware won't see the End-Of-Chain flag and may fetch uninitialized memory. Wrapping it with cpu_to_le32(LINK_EOC) would prevent this. > + > + return vchan_tx_prep(&aml_chan->vchan, &aml_desc->vd, flags); > +} [ ... ] > +static int aml_dma_chan_resume(struct dma_chan *chan) > +{ > + struct aml_dma_chan *aml_chan =3D to_aml_dma_chan(chan); > + struct aml_dma_dev *aml_dma =3D aml_chan->aml_dma; > + unsigned long flags; > + > + spin_lock_irqsave(&aml_chan->vchan.lock, flags); > + regmap_clear_bits(aml_dma->regmap, aml_chan->reg_offs + RCH_CFG, CFG_PA= USE); > + aml_chan->status =3D aml_chan->pre_status; > + spin_unlock_irqrestore(&aml_chan->vchan.lock, flags); [Severity: High] Does aml_dma_chan_resume() fail to start descriptors that were issued while the channel was paused? When a channel is paused, aml_chan->status is set to DMA_PAUSED. Any subsequent calls to aml_dma_issue_pending() append descriptors to the desc_issued list but return immediately from aml_dma_start() without triggering the hardware. Because aml_dma_chan_resume() restores aml_chan->status to DMA_COMPLETE but does not check if the pending queue is non-empty, descriptors queued during the pause will stall indefinitely. > + > + return 0; > +} > + > +static int aml_dma_terminate_all(struct dma_chan *chan) > +{ > + struct aml_dma_chan *aml_chan =3D to_aml_dma_chan(chan); > + struct aml_dma_dev *aml_dma =3D aml_chan->aml_dma; > + int chan_id =3D aml_chan->chan_id; > + struct virt_dma_desc *cur_vd; > + unsigned long flags; > + LIST_HEAD(head); > + > + spin_lock_irqsave(&aml_chan->vchan.lock, flags); > + regmap_set_bits(aml_dma->regmap, aml_chan->reg_offs + RCH_CFG, CFG_PAUS= E); > + regmap_set_bits(aml_dma->regmap, aml_chan->reg_offs + RCH_CFG, CFG_CLEA= R); > + > + if (aml_chan->direction =3D=3D DMA_MEM_TO_DEV) > + regmap_set_bits(aml_dma->regmap, RCH_INT_MASK, BIT(chan_id)); > + else if (aml_chan->direction =3D=3D DMA_DEV_TO_MEM) > + regmap_set_bits(aml_dma->regmap, WCH_INT_MASK, BIT(chan_id)); > + > + regmap_clear_bits(aml_dma->regmap, aml_chan->reg_offs + RCH_CFG, CFG_PA= USE); > + regmap_clear_bits(aml_dma->regmap, aml_chan->reg_offs + RCH_CFG, CFG_CL= EAR); > + > + vchan_get_all_descriptors(&aml_chan->vchan, &head); > + cur_vd =3D &aml_chan->cur_desc->vd; > + aml_chan->cur_desc =3D NULL; > + spin_unlock_irqrestore(&aml_chan->vchan.lock, flags); [Severity: Low] Is this taking the address of a member from a potentially NULL pointer? If there is no active transfer, aml_chan->cur_desc is NULL. Calculating &aml_chan->cur_desc->vd before checking for NULL is undefined behavior in standard C. While it safely evaluates to NULL in the kernel because vd is at offset 0 and GCC is invoked with -fno-delete-null-pointer-checks, this diverges from the correct pattern used elsewhere in the driver. > + if (cur_vd) > + aml_dma_free_desc(cur_vd); > + > + vchan_dma_desc_free_list(&aml_chan->vchan, &head); > + > + aml_chan->status =3D DMA_COMPLETE; > + aml_chan->err_num =3D 0; [Severity: High] Is there a race condition here since aml_chan->status and err_num are updated outside of the vchan.lock? If a concurrent aml_dma_issue_pending() acquires the lock immediately after it is dropped here, it will see the stale aml_chan->status (e.g., DMA_PAUSED). aml_dma_start() will then return without touching the hardware. terminate_all will subsequently set the status to DMA_COMPLETE, but the newly queued transfer will be permanently stuck. > + > + return 0; > +} [ ... ] > +static irqreturn_t aml_dma_interrupt_handler(int irq, void *dev_id) > +{ [ ... ] > + vchan_cookie_complete(&aml_desc->vd); > + aml_chan->cur_desc =3D NULL; > + aml_dma_start(aml_chan); > + spin_unlock(&aml_chan->vchan.lock); > + } > + > + return IRQ_HANDLED; [Severity: Medium] Does this unconditionally return IRQ_HANDLED even when no hardware bits were set? If the interrupt handler is invoked but the hardware did not assert the interrupt, the processing loops are skipped, but the function still returns IRQ_HANDLED. This violates the IRQ API contract (which requires returning IRQ_NONE) and prevents the core IRQ subsystem from detecting and disabling spurious interrupt storms. > +} [ ... ] > +static int aml_dma_probe(struct platform_device *pdev) > +{ > + struct device_node *np =3D pdev->dev.of_node; > + struct dma_device *dma_dev; > + struct aml_dma_dev *aml_dma; > + int ret, i, len; > + u32 chan_nr; > + > + const struct regmap_config aml_regmap_config =3D { > + .reg_bits =3D 32, > + .val_bits =3D 32, > + .reg_stride =3D 4, > + .max_register =3D 0x3000, > + }; > + > + ret =3D of_property_read_u32(np, "dma-channels", &chan_nr); > + if (ret) > + return dev_err_probe(&pdev->dev, ret, "failed to read dma-channels\n"); > + if (chan_nr > (MAX_CHAN_ID * 2)) > + return dev_err_probe(&pdev->dev, -EINVAL, "dma-channels unusual\n"); > + > + len =3D sizeof(struct aml_dma_dev) + sizeof(struct aml_dma_chan) * chan= _nr; > + aml_dma =3D devm_kzalloc(&pdev->dev, len, GFP_KERNEL); > + if (!aml_dma) > + return -ENOMEM; > + > + aml_dma->free_wq =3D alloc_ordered_workqueue("aml_dma_free", 0); > + if (!aml_dma->free_wq) > + return -ENOMEM; > + > + aml_dma->chan_nr =3D chan_nr; > + > + aml_dma->base =3D devm_platform_ioremap_resource(pdev, 0); > + if (IS_ERR(aml_dma->base)) > + return PTR_ERR(aml_dma->base); [Severity: High] Does this leak free_wq on probe errors? If devm_platform_ioremap_resource() or any subsequent registration fails during probe, the function returns an error without calling destroy_workqueue(aml_dma->free_wq), leaking the workqueue memory. > + > + aml_dma->regmap =3D devm_regmap_init_mmio(&pdev->dev, aml_dma->base, > + &aml_regmap_config); > + if (IS_ERR_OR_NULL(aml_dma->regmap)) > + return PTR_ERR(aml_dma->regmap); > + > + aml_dma->clk =3D devm_clk_get_enabled(&pdev->dev, NULL); > + if (IS_ERR(aml_dma->clk)) > + return PTR_ERR(aml_dma->clk); > + > + aml_dma->irq =3D platform_get_irq(pdev, 0); > + > + aml_dma->pdev =3D pdev; > + aml_dma->dma_device.dev =3D &pdev->dev; [Severity: High] Does this break deferred probing by missing a bounds check on the returned IRQ value? platform_get_irq() can return a negative error code such as -EPROBE_DEFER. By unconditionally assigning it to aml_dma->irq and passing it to devm_request_irq(), the IRQ core will reject the negative IRQ value and return -EINVAL. This overwrites the -EPROBE_DEFER error and causes a permanent failure to probe. > + > + dma_dev =3D &aml_dma->dma_device; [ ... ] > +static void aml_dma_remove(struct platform_device *pdev) > +{ > + struct aml_dma_dev *aml_dma =3D platform_get_drvdata(pdev); > + struct aml_dma_chan *aml_chan =3D NULL; > + int i; > + > + of_dma_controller_free((&pdev->dev)->of_node); > + > + regmap_write(aml_dma->regmap, RCH_INT_MASK, INT_MASK); > + regmap_write(aml_dma->regmap, WCH_INT_MASK, INT_MASK); > + > + for (i =3D 0; i < MAX_CHAN_ID; i++) { > + aml_chan =3D aml_dma->aml_rch[i]; > + if (aml_chan) > + tasklet_kill(&aml_chan->vchan.task); > + aml_chan =3D aml_dma->aml_wch[i]; > + if (aml_chan) > + tasklet_kill(&aml_chan->vchan.task); > + } > + destroy_workqueue(aml_dma->free_wq); > +} [Severity: High] Is there a use-after-free race condition during driver unbind? The tasklets are killed here, but because devm_request_irq() was used during probe, the IRQ line remains active until devres runs after aml_dma_remove() returns. Without a call to synchronize_irq(), an in-flight interrupt on another CPU could schedule the tasklet again after tasklet_kill() has finished. When devres subsequently frees the driver's memory, the delayed tasklet will execute on freed memory. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260903-amlogic-dm= a-v12-0-f769bc344056@amlogic.com?part=3D2