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 4F224C44507 for ; Mon, 13 Jul 2026 12:56:56 +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=r6GGRc47jP2dqwQ+TFwSgmKM/jIaOIMjL7US3bkoyMk=; b=hy/YyOOVK4EObO XDPWePo9p8+aArTkHeBVez8ywCAbSlQapfdyNcNYbmhsjdrSU2vtblO0hPxMjUUqlJj2eMTwiqokq u3VKyhZut1srz5Blzk7ob9rWiOnTvfmQd7ldvsN7c8zAS+a2Orm+U7zFzl0TiCiaA7Y0XS3cAEEaJ f6fYvQpyKOhw4yxwYm8mCxB0mu1w0u9WlBxmppSjJcFVV/lgq01yExdikHNYyGZEpDSUl0ORX9CTN AB6/3H93E6l16wi8Ne/H5dtKT/+ii25VYUbBrGYKSzl0b/CnBsb6J+B8rMTnogIrsKrCjtPJkwWay JAeFfxco5e/EcAFR6zpQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjGDN-00000009GCY-11xS; Mon, 13 Jul 2026 12:56:53 +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 1wjGDJ-00000009GC7-3Csq for linux-amlogic@lists.infradead.org; Mon, 13 Jul 2026 12:56:49 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 86719438C4; Mon, 13 Jul 2026 12:56:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33B151F000E9; Mon, 13 Jul 2026 12:56:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783947409; bh=AeQ88YsTKdvbi/FZj6zWrkktdBCLQi9tblRYaaxcv5M=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=kwYS+p1jTVI9LOI9quB/Y8P7rFD6RH+HbNoOScM6AD9qDNMl+ATQ1lULwKOcXYDGJ 3tPCbAMmyQCJ8mBsFD1mj6FPsNoEh9qojnuD5wLhFAIv1RaffRKQbPgd15jkunLb13 xPFBdA7IYsmcOm4PUnoaLWvS/t7gKjreMk6prjjSTMT8qbTKr5oLyobGlsVmik/8Qc ofyjtWR5BV4dB0HgBOpfJY+pBidXf+vjUPE1yxSa1qLy7WOmcu/vM9cDqzrOFeNJTz vPUoFBZfgzH7LmczLOOdRqKgRFhoOcIyE42OGMvTtAFQgyh2lWfu5T5py1rmgquJKA PryksvLinumgA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 15/19] media: meson: vdec: Fix concurrent firmware loading race and hardware timeout To: "Anand Moon" Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org In-Reply-To: <20260713120840.17427-16-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-16-linux.amoon@gmail.com> Date: Mon, 13 Jul 2026 12:56:48 +0000 Message-Id: <20260713125649.33B151F000E9@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 NCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtMb3ddIFN1 Ym9wdGltYWwgdXNlIG9mIGF0b21pYyBwb2xsaW5nIGluIGEgc2xlZXBhYmxlIGNvbnRleHQuCgpQ cmUtZXhpc3RpbmcgaXNzdWVzOgotIFtIaWdoXSBNaXNzaW5nIG1lbW9yeSBiYXJyaWVyIGJldHdl ZW4gZmlybXdhcmUgbWVtY3B5IGFuZCBETUEgc3RhcnQuCi0gW0hpZ2hdIEluY29tcGxldGUgZml4 OiBpZGVudGljYWwgYnVncyAoc3RhdGljIHZhcmlhYmxlcyBhbmQgcmF3IGRlY3JlbWVudCBsb29w KSByZW1haW4gaW4gSEVWQyBmaXJtd2FyZSBsb2FkZXIuCi0gW0hpZ2hdIFBvdGVudGlhbCBETUEg VXNlLUFmdGVyLUZyZWUgaWYgZmlybXdhcmUgRE1BIHRyYW5zZmVyIHRpbWVzIG91dC4KLS0KCi0t LSBQYXRjaCBbMTVdOiBbUEFUQ0ggdjcgMTUvMTldIG1lZGlhOiBtZXNvbjogdmRlYzogRml4IGNv bmN1cnJlbnQgZmlybXdhcmUgbG9hZGluZyByYWNlIGFuZCBoYXJkd2FyZSB0aW1lb3V0IC0tLQpj b21taXQgN2FjZjI0NGQ1OThiMWQxYTE1ZmJlMjE5YjZjZWFlYWQzMWIyMjEwYgpBdXRob3I6IEFu YW5kIE1vb24gPGxpbnV4LmFtb29uQGdtYWlsLmNvbT4KCm1lZGlhOiBtZXNvbjogdmRlYzogRml4 IGNvbmN1cnJlbnQgZmlybXdhcmUgbG9hZGluZyByYWNlIGFuZCBoYXJkd2FyZSB0aW1lb3V0CgpU aGlzIGNvbW1pdCBmaXhlcyBhIGNvbmN1cnJlbnQgZmlybXdhcmUgbG9hZGluZyByYWNlIGNvbmRp dGlvbiBieSByZXBsYWNpbmcKc3RhdGljIHZhcmlhYmxlcyB3aXRoIGxvY2FsIG9uZXMgaW4gdmRl Y18xX2xvYWRfZmlybXdhcmUoKS4gSXQgYWxzbyBhZGRyZXNzZXMKaGFyZHdhcmUgRE1BIGhhbmcg dGltZW91dHMgYnkgcmVwbGFjaW5nIGEgZmFzdCBkZWNyZW1lbnQgbG9vcCB3aXRoCnJlYWRsX3Bv bGxfdGltZW91dF9hdG9taWMoKS4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvc3RhZ2luZy9tZWRp YS9tZXNvbi92ZGVjL3ZkZWNfMS5jIGIvZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29uL3ZkZWMv dmRlY18xLmMKPiAtLS0gYS9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy92ZGVjXzEu Ywo+ICsrKyBiL2RyaXZlcnMvc3RhZ2luZy9tZWRpYS9tZXNvbi92ZGVjL3ZkZWNfMS5jCgpbIC4u LiBdCgo+IEBAIC02MywxMSArNjMsMTEgQEAgdmRlY18xX2xvYWRfZmlybXdhcmUoc3RydWN0IGFt dmRlY19zZXNzaW9uICpzZXNzLCBjb25zdCBjaGFyICpmd25hbWUpCj4gIAlhbXZkZWNfd3JpdGVf ZG9zKGNvcmUsIElNRU1fRE1BX0NPVU5ULCBNQ19TSVpFIC8gNCk7Cj4gIAlhbXZkZWNfd3JpdGVf ZG9zKGNvcmUsIElNRU1fRE1BX0NUUkwsICgweDgwMDAgfCAoNyA8PCAxNikpKTsKCltTZXZlcml0 eTogSGlnaF0KVGhpcyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGlzIHRoZXJlIGEgbWlz c2luZyBtZW1vcnkgYmFycmllciBiZXR3ZWVuCnRoZSBmaXJtd2FyZSBtZW1jcHkgYW5kIHRoZSBE TUEgc3RhcnQ/CgpFYXJsaWVyIGluIHZkZWNfMV9sb2FkX2Zpcm13YXJlKCksIHRoZSBmaXJtd2Fy ZSBpcyBjb3BpZWQgdG8gYSBETUEtY29oZXJlbnQKYnVmZmVyOgoKICAgIG1lbWNweShtY19hZGRy LCBmdy0+ZGF0YSwgTUNfU0laRSk7CgpTaW5jZSBhbXZkZWNfd3JpdGVfZG9zKCkgbWFwcyB0byB3 cml0ZWxfcmVsYXhlZCgpLCB0aGVyZSBpcyBubyBtZW1vcnktdG8tSS9PCm9yZGVyaW5nIGd1YXJh bnRlZS4gQ291bGQgdGhlIENQVSBpc3N1ZSB0aGUgTU1JTyB3cml0ZSB0byBzdGFydCB0aGUgRE1B CmJlZm9yZSB0aGUgZmlybXdhcmUgZGF0YSBpcyBmbHVzaGVkIHRvIG1haW4gbWVtb3J5LCBjYXVz aW5nIHRoZSBoYXJkd2FyZSB0bwpyZWFkIHN0YWxlIGRhdGE/Cgo+IC0Jd2hpbGUgKC0taSAmJiBh bXZkZWNfcmVhZF9kb3MoY29yZSwgSU1FTV9ETUFfQ1RSTCkgJiAweDgwMDApOwo+IC0KPiAtCWlm IChpID09IDApIHsKPiArCXJldCA9IHJlYWRsX3BvbGxfdGltZW91dF9hdG9taWMoY29yZS0+ZG9z X2Jhc2UgKyBJTUVNX0RNQV9DVFJMLCB2YWwsCj4gKwkJCQkJISh2YWwgJiAweDgwMDApLCAxMCwg MTAwMDApOwoKW1NldmVyaXR5OiBMb3ddCkRvZXMgdGhpcyBuZWVkIHRvIHVzZSB0aGUgYXRvbWlj IHBvbGxpbmcgdmFyaWFudD8KClNpbmNlIHZkZWNfMV9sb2FkX2Zpcm13YXJlKCkgcnVucyBpbiBh IHNsZWVwYWJsZSBjb250ZXh0IChpdCBzdWNjZXNzZnVsbHkKY2FsbHMgcmVxdWVzdF9maXJtd2Fy ZSgpIGFuZCBhbGxvY2F0ZXMgbWVtb3J5IHdpdGggR0ZQX0tFUk5FTCBqdXN0IHByaW9yKSwKY291 bGQgdGhpcyB1c2UgdGhlIG5vbi1hdG9taWMgcmVhZGxfcG9sbF90aW1lb3V0KCkgbWFjcm8gaW5z dGVhZD8KClVzaW5nIHRoZSBhdG9taWMgdmFyaWFudCBmb3JjZXMgdGhlIENQVSB0byBidXN5LXdh aXQgaW4gYSB1ZGVsYXkoKSBsb29wIGZvcgp1cCB0byAxMG1zLCB3aGljaCBtaWdodCBiZSBpbmVm ZmljaWVudC4KCj4gKwlpZiAocmV0KSB7Cj4gIAkJZGV2X2VycihkZXYsICJGaXJtd2FyZSBsb2Fk IGZhaWwgKERNQSBoYW5nPylcbiIpOwo+IC0JCXJldCA9IC1FSU5WQUw7Cj4gKwkJcmV0ID0gLUVU SU1FRE9VVDsKPiAgCQlnb3RvIGZyZWVfbWM7CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYSBw cmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2VzIHRoaXMgY3JlYXRlIGEgRE1BIHVzZS1hZnRlci1m cmVlIGlmCnRoZSBmaXJtd2FyZSBETUEgdHJhbnNmZXIgdGltZXMgb3V0PwoKV2hlbiBhIHRpbWVv dXQgb2NjdXJzLCB0aGUgY29kZSBqdW1wcyB0byBmcmVlX21jOgoKZnJlZV9tYzoKICAgIGRtYV9m cmVlX2NvaGVyZW50KGNvcmUtPmRldiwgTUNfU0laRSwgbWNfYWRkciwgbWNfYWRkcl9tYXApOwoK SWYgdGhlIGhhcmR3YXJlIGlzIG1lcmVseSBzbG93IGFuZCBzdGlsbCBleGVjdXRpbmcgdGhlIERN QSB0cmFuc2Zlciwgd2lsbCBpdApjb250aW51ZSB0byByZWFkIGZyb20gdGhlc2UgZnJlZWQgbWVt b3J5IHBhZ2VzPyBTaG91bGQgdGhlIERNQSBjb250cm9sbGVyIGJlCmV4cGxpY2l0bHkgaGFsdGVk IChmb3IgZXhhbXBsZSwgYnkgY2xlYXJpbmcgdGhlIElNRU1fRE1BX0NUUkwgcmVnaXN0ZXIpCmJl Zm9yZSByZWxlYXNpbmcgdGhlIGJ1ZmZlcj8KCj4gIAl9CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMg aXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2VzIHRoZSBzYW1lIHByb2JsZW0gc3RpbGwg ZXhpc3QgaW4gdGhlCkhFVkMgZmlybXdhcmUgbG9hZGVyPwoKTG9va2luZyBhdCB2ZGVjX2hldmNf bG9hZF9maXJtd2FyZSgpIGluIHZkZWNfaGV2Yy5jLCBpdCB1c2VzIHRoZSBleGFjdCBzYW1lCnN0 YXRpYyB2YXJpYWJsZXMgYW5kIGZhc3QgZGVjcmVtZW50IGxvb3AgdGhhdCB0aGlzIHBhdGNoIGZp eGVzIGluIHZkZWNfMS5jOgoKc3RhdGljIGludCB2ZGVjX2hldmNfbG9hZF9maXJtd2FyZSguLi4p CnsKICAgIC4uLgogICAgc3RhdGljIHZvaWQgKm1jX2FkZHI7CiAgICBzdGF0aWMgZG1hX2FkZHJf dCBtY19hZGRyX21hcDsKICAgIC4uLgogICAgd2hpbGUgKGkgJiYgKHJlYWRsKGNvcmUtPmRvc19i YXNlICsgSEVWQ19JTUVNX0RNQV9DVFJMKSAmIDB4ODAwMCkpCiAgICAgICAgaS0tOwogICAgLi4u Cn0KCldpbGwgSEVWQyBkZWNvZGluZyBhbHNvIGZhaWwgY29uc2lzdGVudGx5IG9uIG1vZGVybiBD UFVzIGR1ZSB0byBmYWxzZSBETUEKdGltZW91dHM/IEFuZCBjb3VsZCBtdWx0aXBsZSBIRVZDIGRl Y29kaW5nIHNlc3Npb25zIGNvcnJ1cHQgc3RhdGUgYnkgc2hhcmluZwp0aGVzZSBzdGF0aWMgdmFy aWFibGVzPwoKLS0gClNhc2hpa28gQUkgcmV2aWV3IMK3IGh0dHBzOi8vc2FzaGlrby5kZXYvIy9w YXRjaHNldC8yMDI2MDcxMzEyMDg0MC4xNzQyNy0xLWxpbnV4LmFtb29uQGdtYWlsLmNvbT9wYXJ0 PTE1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51 eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51eC1hbWxvZ2ljQGxpc3RzLmluZnJhZGVhZC5vcmcK aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hbWxvZ2lj Cg== 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 427EBC43458 for ; Mon, 13 Jul 2026 12:56:51 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A18AB10E5CA; Mon, 13 Jul 2026 12:56:50 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="kwYS+p1j"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id A0A1610E5CA for ; Mon, 13 Jul 2026 12:56:49 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 86719438C4; Mon, 13 Jul 2026 12:56:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33B151F000E9; Mon, 13 Jul 2026 12:56:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783947409; bh=AeQ88YsTKdvbi/FZj6zWrkktdBCLQi9tblRYaaxcv5M=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=kwYS+p1jTVI9LOI9quB/Y8P7rFD6RH+HbNoOScM6AD9qDNMl+ATQ1lULwKOcXYDGJ 3tPCbAMmyQCJ8mBsFD1mj6FPsNoEh9qojnuD5wLhFAIv1RaffRKQbPgd15jkunLb13 xPFBdA7IYsmcOm4PUnoaLWvS/t7gKjreMk6prjjSTMT8qbTKr5oLyobGlsVmik/8Qc ofyjtWR5BV4dB0HgBOpfJY+pBidXf+vjUPE1yxSa1qLy7WOmcu/vM9cDqzrOFeNJTz vPUoFBZfgzH7LmczLOOdRqKgRFhoOcIyE42OGMvTtAFQgyh2lWfu5T5py1rmgquJKA PryksvLinumgA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 15/19] media: meson: vdec: Fix concurrent firmware loading race and hardware timeout To: "Anand Moon" Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org In-Reply-To: <20260713120840.17427-16-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-16-linux.amoon@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2026 12:56:48 +0000 Message-Id: <20260713125649.33B151F000E9@smtp.kernel.org> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Thank you for your contribution! Sashiko AI review found 4 potential issue(= s) to consider: New issues: - [Low] Suboptimal use of atomic polling in a sleepable context. Pre-existing issues: - [High] Missing memory barrier between firmware memcpy and DMA start. - [High] Incomplete fix: identical bugs (static variables and raw decrement= loop) remain in HEVC firmware loader. - [High] Potential DMA Use-After-Free if firmware DMA transfer times out. -- --- Patch [15]: [PATCH v7 15/19] media: meson: vdec: Fix concurrent firmwar= e loading race and hardware timeout --- commit 7acf244d598b1d1a15fbe219b6ceaead31b2210b Author: Anand Moon media: meson: vdec: Fix concurrent firmware loading race and hardware timeo= ut This commit fixes a concurrent firmware loading race condition by replacing static variables with local ones in vdec_1_load_firmware(). It also address= es hardware DMA hang timeouts by replacing a fast decrement loop with readl_poll_timeout_atomic(). > diff --git a/drivers/staging/media/meson/vdec/vdec_1.c b/drivers/staging/= media/meson/vdec/vdec_1.c > --- a/drivers/staging/media/meson/vdec/vdec_1.c > +++ b/drivers/staging/media/meson/vdec/vdec_1.c [ ... ] > @@ -63,11 +63,11 @@ vdec_1_load_firmware(struct amvdec_session *sess, con= st char *fwname) > amvdec_write_dos(core, IMEM_DMA_COUNT, MC_SIZE / 4); > amvdec_write_dos(core, IMEM_DMA_CTRL, (0x8000 | (7 << 16))); [Severity: High] This is a pre-existing issue, but is there a missing memory barrier between the firmware memcpy and the DMA start? Earlier in vdec_1_load_firmware(), the firmware is copied to a DMA-coherent buffer: memcpy(mc_addr, fw->data, MC_SIZE); Since amvdec_write_dos() maps to writel_relaxed(), there is no memory-to-I/O ordering guarantee. Could the CPU issue the MMIO write to start the DMA before the firmware data is flushed to main memory, causing the hardware to read stale data? > - while (--i && amvdec_read_dos(core, IMEM_DMA_CTRL) & 0x8000); > - > - if (i =3D=3D 0) { > + ret =3D readl_poll_timeout_atomic(core->dos_base + IMEM_DMA_CTRL, val, > + !(val & 0x8000), 10, 10000); [Severity: Low] Does this need to use the atomic polling variant? Since vdec_1_load_firmware() runs in a sleepable context (it successfully calls request_firmware() and allocates memory with GFP_KERNEL just prior), could this use the non-atomic readl_poll_timeout() macro instead? Using the atomic variant forces the CPU to busy-wait in a udelay() loop for up to 10ms, which might be inefficient. > + if (ret) { > dev_err(dev, "Firmware load fail (DMA hang?)\n"); > - ret =3D -EINVAL; > + ret =3D -ETIMEDOUT; > goto free_mc; [Severity: High] This is a pre-existing issue, but does this create a DMA use-after-free if the firmware DMA transfer times out? When a timeout occurs, the code jumps to free_mc: free_mc: dma_free_coherent(core->dev, MC_SIZE, mc_addr, mc_addr_map); If the hardware is merely slow and still executing the DMA transfer, will it continue to read from these freed memory pages? Should the DMA controller be explicitly halted (for example, by clearing the IMEM_DMA_CTRL register) before releasing the buffer? > } [Severity: High] This is a pre-existing issue, but does the same problem still exist in the HEVC firmware loader? Looking at vdec_hevc_load_firmware() in vdec_hevc.c, it uses the exact same static variables and fast decrement loop that this patch fixes in vdec_1.c: static int vdec_hevc_load_firmware(...) { ... static void *mc_addr; static dma_addr_t mc_addr_map; ... while (i && (readl(core->dos_base + HEVC_IMEM_DMA_CTRL) & 0x8000)) i--; ... } Will HEVC decoding also fail consistently on modern CPUs due to false DMA timeouts? And could multiple HEVC decoding sessions corrupt state by sharing these static variables? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260713120840.1742= 7-1-linux.amoon@gmail.com?part=3D15