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 2D7F0C43458 for ; Mon, 13 Jul 2026 13:06:18 +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=qOf5Tb7X9bZq/mFd3qt1DkTaAxnJJXA96AnfrXZkrpE=; b=3izPdWQTdm8Atv ZkokpFNFE3FUfzk6dToKS7mpKDr8PQiOZMsRp10tHmwcP8eOn1LuoiCo9niNg1Yrp5ZUnjh0PtQUp hxs1Wtl22WLnEroo940LgjJrdef5HTAl8BvHMv8WhkiGSE4Ukh4nRymT6XOqa3bv+QpbAKK3aaIO+ TOpFU7fENSUh47UtM3PH92z8B2itDFP0TxtM5EcEpgevfC4TTTmhFfs//Ey3CyN7c8h8FB38mvl+A c3GbC218K8/fp6ZBsRhnbJU5F+A+KbdF91iEIud3L/4ZS44MkrHZoROiWz5aHhj0NOscBJXkA5/eh cFLR//CySRzhEpDhSekg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjGMR-00000009JtW-1hma; Mon, 13 Jul 2026 13:06:15 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjGMP-00000009Jra-3JPg for linux-amlogic@lists.infradead.org; Mon, 13 Jul 2026 13:06:13 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id E8938600AA; Mon, 13 Jul 2026 13:06:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7AF0B1F00A3A; Mon, 13 Jul 2026 13:06:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783947972; bh=EUC4Kd6YeSlx6wPBaTuhucFiR4l8oX10MVHRygNQjxw=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=SHOAH5Psk3uAnsfV3dEJH61I53VGXstqf64GkHVAEAYltLtORB5csZNn9Gu7RFA48 2GMaVqNRGsDZ7zkSgnfK66rd3o5oWLz/v+Fw4Aip8730s8n/JveCrocnnSoy9hacKb vrZQ++qJ9I9h/sXDZkX7rZcTPRXm9fadU6SngXN8WWNcjCQyqLy09J/FoMke5NJuya VwiZchnVfAyEOVyUo/tP7sOu1YtrgHtwkOYsfmrW+yfQvesve4siA9k2koJA66byl+ KrIxm6nqVON5VKd4RG/mNpGWaFsaYu+OIF938SsXMscS9k1Ckm6SesYN+Aoji15LdA jffOHgApZXUsA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 18/19] media: meson: vdec: Increase VIFIFO buffer size to 32 MiB To: "Anand Moon" Cc: linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org In-Reply-To: <20260713120840.17427-19-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-19-linux.amoon@gmail.com> Date: Mon, 13 Jul 2026 13:06:12 +0000 Message-Id: <20260713130612.7AF0B1F00A3A@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 OCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBU aGUgYGVzcGFyc2VyX3F1ZXVlX2FsbF9zcmNgIHdvcmtxdWV1ZSBoYW5kbGVyIGNvbnRhaW5zIGEg ZmF0YWwgaW5maW5pdGUgbG9vcCBkdWUgdG8gaW5jb3JyZWN0IHVzYWdlIG9mIHRoZSBgc2NvcGVk X2d1YXJkYCBtYWNybyBpbiBjb21iaW5hdGlvbiB3aXRoIGBicmVha2Agc3RhdGVtZW50cywgbW9u b3BvbGl6aW5nIDEwMCUgb2YgYSBDUFUgY29yZS4KLSBbSGlnaF0gRG91YmxlIGRlY3JlbWVudCBv ZiB0aGUgYGVzcGFyc2VyX3F1ZXVlZF9idWZzYCBhdG9taWMgY291bnRlciBwZXIgdmlkZW8gZnJh bWUgbGVhZHMgdG8gY291bnRlciB1bmRlcmZsb3cgYW5kIGJ1ZmZlciBvdmVycnVucy4KLSBbSGln aF0gVGhlIDMyIE1pQiBWSUZJRk8gYnVmZmVyIGluY3JlYXNlIGNhdXNlcyB0aGUgYml0c3RyZWFt IHNpemUgdG8gb3ZlcmZsb3cgdGhlIDMyLWJpdCBoYXJkd2FyZSBQQVJTRVJfQ09OVFJPTCByZWdp c3RlciBjYWxjdWxhdGlvbiwgY3Jhc2hpbmcgdGhlIGVzcGFyc2VyIERNQSBlbmdpbmUuCgpQcmUt ZXhpc3RpbmcgaXNzdWVzOgotIFtDcml0aWNhbF0gSW4gYHZwOV91cGRhdGVfaGVhZGVyYCwgYW4g aW50ZWdlciBvdmVyZmxvdyB3aGVuIGRlY29kaW5nIG1hbGljaW91c2x5IGNyYWZ0ZWQgZnJhbWUg bWFnbml0dWRlcyBhbGxvd3MgYGZyYW1lX3NpemVgIHRvIGJlY29tZSBuZWdhdGl2ZSwgYnlwYXNz aW5nIHNpemUgdmFsaWRhdGlvbnMgYW5kIHRyaWdnZXJpbmcgYSBtYXNzaXZlIG91dC1vZi1ib3Vu ZHMgYG1lbW1vdmVgIHRoYXQgcGFuaWNzIHRoZSBrZXJuZWwuCi0gW0hpZ2hdIFBoeXNpY2FsIGFk ZHJlc3MgdHJ1bmNhdGlvbiBmb3IgdGhlIGhhcmR3YXJlIHJpbmcgYnVmZmVyIGVuZCBwb2ludGVy IGNhdXNlcyBpbW1lZGlhdGUgRE1BIGNvcnJ1cHRpb24gd2hlbiBtZW1vcnkgaXMgYWxsb2NhdGVk IG5lYXIgdGhlIHRvcCBvZiB0aGUgMzItYml0IGFkZHJlc3Mgc3BhY2UuCi0gW0hpZ2hdIFVzZS1B ZnRlci1GcmVlIChVQUYpIHZ1bG5lcmFiaWxpdGllcyBpbiBgdmRlY19jbG9zZWAgZHVyaW5nIGRl dmljZSB1bmJpbmQgZHVlIHRvIGBkZXZtX2t6YWxsb2NgIGFuZCBgdjRsMl9tMm1fcmVsZWFzZWAg bGlmZWN5Y2xlIG1pc21hdGNoZXMuCi0gW01lZGl1bV0gVGltZXN0YW1wIHRyYWNraW5nIGFuZCBt YXRjaGluZyBicmVha3Mgc2lsZW50bHkgd2hlbiB0aGUgMzItYml0IGhhcmR3YXJlIG9mZnNldCB3 cmFwcyBhcm91bmQgYXQgdGhlIDQgR0IgYml0c3RyZWFtIGJvdW5kYXJ5LCBkdWUgdG8gYW4gaW1w cm9wZXIgbmFpdmUgdW5zaWduZWQgc2VxdWVuY2UgY29tcGFyaXNvbi4KLSBbTWVkaXVtXSBSYWNl IGNvbmRpdGlvbiBpbiBgZXNwYXJzZXJfd3JpdGVfZGF0YWAgb3ZlcndyaXRlcyB0aGUgY29tcGxl dGlvbiBmbGFnLCBjYXVzaW5nIGZhbHNlIGlucHV0IHBhcnNpbmcgdGltZW91dHMuCi0tCgotLS0g UGF0Y2ggWzE4XTogW1BBVENIIHY3IDE4LzE5XSBtZWRpYTogbWVzb246IHZkZWM6IEluY3JlYXNl IFZJRklGTyBidWZmZXIgc2l6ZSB0byAzMiBNaUIgLS0tCmNvbW1pdCAyYWRkYzdhNDk2MWRjNWZj YzY5ZGZiYjJlOTZkNTdlYjg5ODUzZGU5CkF1dGhvcjogQW5hbmQgTW9vbiA8bGludXguYW1vb25A Z21haWwuY29tPgoKbWVkaWE6IG1lc29uOiB2ZGVjOiBJbmNyZWFzZSBWSUZJRk8gYnVmZmVyIHNp emUgdG8gMzIgTWlCCgpEdXJpbmcgNEsgdmlkZW8gcGxheWJhY2ssIHRoZSBoYXJkd2FyZSBFbGVt ZW50YXJ5IFN0cmVhbSBQYXJzZXIgKGVzcGFyc2VyKQpjYW4gcmFwaWRseSBwdXNoIG1hc3NpdmUg YnVyc3QgZGF0YSBwYXlsb2FkcyBpbnRvIHRoZSBWaWRlbyBJbnB1dCBGSUZPCmZhc3RlciB0aGFu IHRoZSBWUFUgZGVjb2RpbmcgYmxvY2sgY2FuIGNvbnN1bWUgaXQuIFRoaXMgY2F1c2VzIGEgYnVm ZmVyCm92ZXJmbG93IHdoZW4gc3RyZWFtIHVzYWdlIGJyZWFrcyBwYXN0IHRoZSBhbGxvY2F0ZWQg aGFyZHdhcmUgYm91bmRhcnkuClRoaXMgcGF0Y2ggZG91YmxlcyB0aGUgcGFyc2VkIGJpdHN0cmVh bSBzd2FwIGV4Y2hhbmdlIG1lbW9yeSBwb29sIHRvIDMyIE1pQi4KCj4gZGlmZiAtLWdpdCBhL2Ry aXZlcnMvc3RhZ2luZy9tZWRpYS9tZXNvbi92ZGVjL3ZkZWMuYyBiL2RyaXZlcnMvc3RhZ2luZy9t ZWRpYS9tZXNvbi92ZGVjL3ZkZWMuYwo+IGluZGV4IGQzM2NiZWJjNDQ1M2IuLjgyNGUyZjE1NmFk ZWIgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29uL3ZkZWMvdmRlYy5j Cj4gKysrIGIvZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29uL3ZkZWMvdmRlYy5jCj4gQEAgLTI5 LDggKzI5LDggQEAgc3RydWN0IGR1bW15X2J1ZiB7Cj4gIAlzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7 Cj4gIH07Cj4gIAo+IC0vKiAxNiBNaUIgZm9yIHBhcnNlZCBiaXRzdHJlYW0gc3dhcCBleGNoYW5n ZSAqLwo+IC0jZGVmaW5lIFNJWkVfVklGSUZPIFNaXzE2TQo+ICsvKiAzMiBNaUIgZm9yIHBhcnNl ZCBiaXRzdHJlYW0gc3dhcCBleGNoYW5nZSAqLwo+ICsjZGVmaW5lIFNJWkVfVklGSUZPIFNaXzMy TQoKW1NldmVyaXR5OiBIaWdoXQpEb2VzIGluY3JlYXNpbmcgdGhlIGJ1ZmZlciB0byAzMiBNaUIg Y2F1c2UgdGhlIGJpdHN0cmVhbSBzaXplIHRvIG92ZXJmbG93CnRoZSAzMi1iaXQgaGFyZHdhcmUg UEFSU0VSX0NPTlRST0wgcmVnaXN0ZXIgY2FsY3VsYXRpb24/CgpJbiBkcml2ZXJzL3N0YWdpbmcv bWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5jOmVzcGFyc2VyX3dyaXRlX2RhdGEoKToKCglhbXZk ZWNfd3JpdGVfcGFyc2VyKGNvcmUsIFBBUlNFUl9DT05UUk9MLAoJCQkgICAgRVNfV1JJVEUgfAoJ CQkgICAgRVNfUEFSU0VSX1NUQVJUIHwKCQkJICAgIEVTX1NFQVJDSCB8CgkJCSAgICAoc2l6ZSA8 PCBFU19QQUNLX1NJWkVfQklUKSk7CgpXaXRoIEVTX1BBQ0tfU0laRV9CSVQgYmVpbmcgOCwgZm9y IGEgc2l6ZSA+PSAxNiBNaUIgdGhpcyBsZWZ0IHNoaWZ0IHdpbGwKb3ZlcmZsb3cgYSAzMi1iaXQg dW5zaWduZWQgaW50ZWdlci4gVGhpcyBjYW4gcmVzdWx0IGluIHRoZSBETUEgZW5naW5lCnJlY2Vp dmluZyBhIHRydW5jYXRlZCBwYXlsb2FkIHNpemUgYW5kIGNyYXNoaW5nLgoKW1NldmVyaXR5OiBI aWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlzc3VlLCBidXQgZG9lcyBpbmNyZWFzaW5nIHRo ZSBidWZmZXIgc2l6ZSBtYWtlIGl0CmhpZ2hseSBwcm9iYWJsZSB0aGF0IHRoZSBoYXJkd2FyZSBy aW5nIGJ1ZmZlciBlbmQgcG9pbnRlciB0cnVuY2F0ZXMsIGNhdXNpbmcKaW1tZWRpYXRlIERNQSBj b3JydXB0aW9uPwoKSW4gZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29uL3ZkZWMvdmRlY19oZXZj LmM6dmRlY19oZXZjX3N0YnVmX2luaXQoKToKCglhbXZkZWNfd3JpdGVfZG9zKGNvcmUsIEhFVkNf U1RSRUFNX0VORF9BRERSLAoJCQkgc2Vzcy0+dmlmaWZvX3BhZGRyICsgc2Vzcy0+dmlmaWZvX3Np emUpOwoKSWYgdGhlIFZJRklGTyBidWZmZXIgaXMgYWxsb2NhdGVkIG5lYXIgdGhlIGVuZCBvZiB0 aGUgMzItYml0IGFkZHJlc3Mgc3BhY2UsCnRoZSBjYWxjdWxhdGlvbiBzZXNzLT52aWZpZm9fcGFk ZHIgKyBzZXNzLT52aWZpZm9fc2l6ZSBjYW4gZXhjZWVkIDMyIGJpdHMsCnJlc3VsdGluZyBpbiBh IHZhbHVlIGxpa2UgMHgxMDAwMDAwMDAuIFRoaXMgaXMgc2lsZW50bHkgdHJ1bmNhdGVkIHRvIDAg d2hlbgpwYXNzZWQgdG8gYW12ZGVjX3dyaXRlX2RvcygpIHdoaWNoIGFjY2VwdHMgYSAzMi1iaXQg dTMyLgoKW1NldmVyaXR5OiBNZWRpdW1dClRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1 dCBob3cgZG9lcyB0aGUgZHJpdmVyIGhhbmRsZSB0aW1lc3RhbXBzIHdoZW4KdGhlIDMyLWJpdCBo YXJkd2FyZSBvZmZzZXQgd3JhcHMgYXJvdW5kIGF0IHRoZSA0IEdCIGJpdHN0cmVhbSBib3VuZGFy eT8KCkluIGRyaXZlcnMvc3RhZ2luZy9tZWRpYS9tZXNvbi92ZGVjL3ZkZWNfaGVscGVycy5jOmFt dmRlY19kc3RfYnVmX2RvbmVfb2Zmc2V0KCk6CgoJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKHRt cCwgbiwgJnNlc3MtPnRpbWVzdGFtcHMsIGxpc3QpIHsKCQlpZiAodG1wLT5vZmZzZXQgPiBvZmZz ZXQpIHsKCQkJLi4uCgkJCWJyZWFrOwoJCX0KClRoZSBzdHJlYW0gb2Zmc2V0IGFjY3VtdWxhdGVz IGludG8gYSAzMi1iaXQgaW50ZWdlciBpbiBlc3BhcnNlcl9nZXRfb2Zmc2V0KCkKdGhhdCBuYXR1 cmFsbHkgd3JhcHMgYXQgNCBHQi4gVGhlIGxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZSBsb29wIHVz ZXMgYQpub24td3JhcC1zYWZlIHJhdyB1bnNpZ25lZCBjb21wYXJpc29uLiBXaGVuIHRoZSBvZmZz ZXQgd3JhcHMgYXJvdW5kIHRvIDAsCmEgbGFyZ2UgdG1wLT5vZmZzZXQgaW1tZWRpYXRlbHkgZXZh bHVhdGVzIGFzIGdyZWF0ZXIgYW5kIGluY29ycmVjdGx5IGJyZWFrcwp0aGUgbG9vcCwgc3RyYW5k aW5nIG9yIGRyb3BwaW5nIHRpbWVzdGFtcHMuCgpbU2V2ZXJpdHk6IEhpZ2hdCkFyZSB0aGVyZSBV c2UtQWZ0ZXItRnJlZSB2dWxuZXJhYmlsaXRpZXMgaW4gdmRlY19jbG9zZSgpIGR1cmluZyBkZXZp Y2UgdW5iaW5kCmR1ZSB0byBkZXZtX2t6YWxsb2MoKSBhbmQgdjRsMl9tMm1fcmVsZWFzZSgpIGxp ZmVjeWNsZSBtaXNtYXRjaGVzPyBUaGlzIGlzbid0CmEgYnVnIGludHJvZHVjZWQgYnkgdGhpcyBw YXRjaCwgYnV0Li4uCgpJbiBkcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy92ZGVjLmM6 dmRlY19yZW1vdmUoKToKCgl2aWRlb191bnJlZ2lzdGVyX2RldmljZShjb3JlLT52ZGV2X2RlYyk7 Cgl2NGwyX20ybV9yZWxlYXNlKGNvcmUtPm0ybV9kZXYpOwoKVGhlIHVuYmluZCBwYXRoIGZyZWVz IHRoZSBjb3JlIHN0cnVjdHVyZSB3aGlsZSBWNEwyIGZpbGUgZGVzY3JpcHRvcnMgbWF5CnN0aWxs IGJlIGFjdGl2ZWx5IGhlbGQgYnkgdXNlcnNwYWNlLgoKTGF0ZXIsIGlmIGFuIGFwcGxpY2F0aW9u IGNsb3NlcyB0aGUgZmlsZSBkZXNjcmlwdG9yLCB2ZGVjX2Nsb3NlKCkgaXMgaW52b2tlZDoKCglz eW5jaHJvbml6ZV9pcnEoY29yZS0+dmRlY19pcnEpOwoKVGhpcyBjb3VsZCBkZXJlZmVyZW5jZSB0 aGUgZnJlZWQgY29yZSBwb2ludGVyIGFuZCB0aGUgZnJlZWQgbTJtX2Rldi4KCltTZXZlcml0eTog SGlnaF0KRG9lcyB0aGUgZXNwYXJzZXJfcXVldWVfYWxsX3NyYygpIHdvcmtxdWV1ZSBoYW5kbGVy IGNvbnRhaW4gYW4gaW5maW5pdGUgbG9vcAp0aGF0IGNvdWxkIG1vbm9wb2xpemUgYSBDUFUgY29y ZT8KCkluIGRyaXZlcnMvc3RhZ2luZy9tZWRpYS9tZXNvbi92ZGVjL2VzcGFyc2VyLmM6ZXNwYXJz ZXJfcXVldWVfYWxsX3NyYygpOgoKCXdoaWxlICgxKSB7CgkJc3RydWN0IHZiMl92NGwyX2J1ZmZl ciAqdmJ1ZiA9IE5VTEw7CgkJYm9vbCBwcm9jZXNzZWRfZnJhbWUgPSBmYWxzZTsKCgkJc2NvcGVk X2d1YXJkKG11dGV4LCAmc2Vzcy0+bG9jaykgewoJCQkuLi4KCQkJdmJ1ZiA9IHY0bDJfbTJtX25l eHRfc3JjX2J1ZihzZXNzLT5tMm1fY3R4KTsKCQkJaWYgKCF2YnVmKQoJCQkJYnJlYWs7CgkJCS4u LgoJCX0KCgkJaWYgKHByb2Nlc3NlZF9mcmFtZSkKCQkJYnJlYWs7CgkJLi4uCgl9CgpUaGUgYnJl YWsgc3RhdGVtZW50cyBhcmUgaW50ZW5kZWQgdG8gZXhpdCB0aGUgZnVuY3Rpb24gd2hlbiBubyBi dWZmZXJzIGFyZQphdmFpbGFibGUuIEhvd2V2ZXIsIHRoZXkgb25seSBlc2NhcGUgdGhlIHNjb3Bl ZF9ndWFyZCdzIGludGVybmFsIGZvciBsb29wLgpUaGlzIGxlYXZlcyB0aGUgb3V0ZXIgd2hpbGUg KDEpIGxvb3AgaW50YWN0IHNpbmNlIHByb2Nlc3NlZF9mcmFtZSBpcyBmYWxzZSwKd2hpY2ggY291 bGQgcmVzdWx0IGluIGEgbG9ja3VwIG9mIGEga2VybmVsIHdvcmtlciB0aHJlYWQuCgpbU2V2ZXJp dHk6IEhpZ2hdCkRvZXMgdGhpcyBjb2RlIGRvdWJsZSBkZWNyZW1lbnQgdGhlIGVzcGFyc2VyX3F1 ZXVlZF9idWZzIGF0b21pYyBjb3VudGVyPwoKSW4gZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29u L3ZkZWMvdmRlY19oZWxwZXJzLmMsIGRzdF9idWZfZG9uZSgpIGNhbGxzCmF0b21pY19kZWMoJnNl c3MtPmVzcGFyc2VyX3F1ZXVlZF9idWZzKS4gSG93ZXZlciwgaXRzIGNhbGxlcnMgYWxzbyBleGVj dXRlCnRoZWlyIG93biBhdG9taWNfZGVjKCk6CgphbXZkZWNfZHN0X2J1Zl9kb25lKCk6CgoJZHN0 X2J1Zl9kb25lKHNlc3MsIHZidWYsIGZpZWxkLCB0aW1lc3RhbXAsIHRpbWVjb2RlLCB2YnVmX2Zs YWdzKTsKCWF0b21pY19kZWMoJnNlc3MtPmVzcGFyc2VyX3F1ZXVlZF9idWZzKTsKCmFtdmRlY19k c3RfYnVmX2RvbmVfb2Zmc2V0KCk6CgoJZHN0X2J1Zl9kb25lKHNlc3MsIHZidWYsIGZpZWxkLCB0 aW1lc3RhbXAsIHRpbWVjb2RlLCB2YnVmX2ZsYWdzKTsKCWlmIChtYXRjaCkKCQlhdG9taWNfZGVj KCZzZXNzLT5lc3BhcnNlcl9xdWV1ZWRfYnVmcyk7CgpUaGlzIGNvdWxkIGxlYWQgdG8gY291bnRl ciB1bmRlcmZsb3csIGJ5cGFzc2luZyBidWZmZXIgbGltaXQgY2hlY2tzIGFuZApjYXVzaW5nIGhh cmR3YXJlIHF1ZXVlIG92ZXJydW5zLgoKW1NldmVyaXR5OiBNZWRpdW1dClRoaXMgaXMgYSBwcmUt ZXhpc3RpbmcgaXNzdWUsIGJ1dCBkb2VzIGVzcGFyc2VyX3dyaXRlX2RhdGEoKSBjb250YWluIGEg cmFjZQpjb25kaXRpb24gdGhhdCBvdmVyd3JpdGVzIHRoZSBjb21wbGV0aW9uIGZsYWc/CgpJbiBk cml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5jOmVzcGFyc2VyX3dyaXRl X2RhdGEoKToKCglhbXZkZWNfd3JpdGVfcGFyc2VyKGNvcmUsIFBBUlNFUl9GRVRDSF9DTUQsCgkJ CSAgICAoNyA8PCBGRVRDSF9FTkRJQU5fQklUKSB8CgkJCSAgICAoc2l6ZSArIFNFQVJDSF9QQVRU RVJOX0xFTikpOwoKCXNlYXJjaF9kb25lID0gMDsKCXJldHVybiB3YWl0X2V2ZW50X2ludGVycnVw dGlibGVfdGltZW91dCh3cSwgc2VhcmNoX2RvbmUsIChIWiAvIDUpKTsKClRoZSBDUFUgaW5pdGlh dGVzIGhhcmR3YXJlIHByb2Nlc3NpbmcgYnkgd3JpdGluZyB0byBQQVJTRVJfRkVUQ0hfQ01ELCB3 aGljaApjYW4gaW5zdGFudGx5IHRyaWdnZXIgZXNwYXJzZXJfaXNyKCkuIElmIHRoZSBoYXJkd2Fy ZSBpbnRlcnJ1cHQgZmlyZXMKaW1tZWRpYXRlbHksIHRoZSBJU1Igc2V0cyBzZWFyY2hfZG9uZSA9 IDEuIFRoZSBDUFUgc2VxdWVudGlhbGx5IGV4ZWN1dGVzCnNlYXJjaF9kb25lID0gMCBhZnRlcndh cmRzLCB3aGljaCBjb3VsZCBlcmFzZSB0aGUgY29tcGxldGlvbiBzaWduYWwgYmVmb3JlCndhaXRp bmcgb24gaXQuCgpbU2V2ZXJpdHk6IENyaXRpY2FsXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlz c3VlLCBidXQgZG9lcyB2cDlfdXBkYXRlX2hlYWRlcigpIGhhdmUgYW4gaW50ZWdlcgpvdmVyZmxv dyB3aGVuIGRlY29kaW5nIGZyYW1lIG1hZ25pdHVkZXMgdGhhdCBjYW4gYnlwYXNzIHNpemUgdmFs aWRhdGlvbnM/CgpJbiBkcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5j OnZwOV91cGRhdGVfaGVhZGVyKCk6CgoJCQkJZnJhbWVfc2l6ZVtjdXJfZnJhbWVdIHw9CgkJCQkJ KGRwW21hZ19wdHJdIDw8IChjdXJfbWFnICogOCkpOwoKVGhlIG1hZ25pdHVkZSBieXRlIGlzIHBy b21vdGVkIHRvIGEgc2lnbmVkIDMyLWJpdCBpbnRlZ2VyLiBXaGVuIHNoaWZ0ZWQgYnkKMjQgYml0 cywgaXQgY2FuIGJlY29tZSBhIGxhcmdlIG5lZ2F0aXZlIG51bWJlciBpZiB0aGUgbWFsaWNpb3Vz bHkgY3JhZnRlZApwYXlsb2FkIGhhcyBkcFttYWdfcHRyXSA+PSAweDgwLgoKTGF0ZXIsIHRoaXMg bmVnYXRpdmUgZnJhbWUgc2l6ZSBieXBhc3NlcyB0b3RhbF9kYXRhc2l6ZSB2YWxpZGF0aW9ucyBh bmQKdHJpZ2dlcnMgYW4gb3V0LW9mLWJvdW5kcyBjb3B5IGluIG1lbW1vdmU6CgoJCW1lbW1vdmUo ZmRhdGEgKyBWUDlfSEVBREVSX1NJWkUsIG9sZF9mcmFtZWRhdGEsIGZyYW1lc2l6ZSk7CgotLSAK U2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0LzIwMjYw NzEzMTIwODQwLjE3NDI3LTEtbGludXguYW1vb25AZ21haWwuY29tP3BhcnQ9MTgKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFtbG9naWMgbWFp bGluZyBsaXN0CmxpbnV4LWFtbG9naWNAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMu aW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFtbG9naWMK 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 E1154C44501 for ; Mon, 13 Jul 2026 13:06:14 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 292F710E993; Mon, 13 Jul 2026 13:06:14 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="SHOAH5Ps"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id C102110E993 for ; Mon, 13 Jul 2026 13:06:13 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id E8938600AA; Mon, 13 Jul 2026 13:06:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7AF0B1F00A3A; Mon, 13 Jul 2026 13:06:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783947972; bh=EUC4Kd6YeSlx6wPBaTuhucFiR4l8oX10MVHRygNQjxw=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=SHOAH5Psk3uAnsfV3dEJH61I53VGXstqf64GkHVAEAYltLtORB5csZNn9Gu7RFA48 2GMaVqNRGsDZ7zkSgnfK66rd3o5oWLz/v+Fw4Aip8730s8n/JveCrocnnSoy9hacKb vrZQ++qJ9I9h/sXDZkX7rZcTPRXm9fadU6SngXN8WWNcjCQyqLy09J/FoMke5NJuya VwiZchnVfAyEOVyUo/tP7sOu1YtrgHtwkOYsfmrW+yfQvesve4siA9k2koJA66byl+ KrIxm6nqVON5VKd4RG/mNpGWaFsaYu+OIF938SsXMscS9k1Ckm6SesYN+Aoji15LdA jffOHgApZXUsA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 18/19] media: meson: vdec: Increase VIFIFO buffer size to 32 MiB To: "Anand Moon" Cc: linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org In-Reply-To: <20260713120840.17427-19-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-19-linux.amoon@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2026 13:06:12 +0000 Message-Id: <20260713130612.7AF0B1F00A3A@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 8 potential issue(= s) to consider: New issues: - [High] The `esparser_queue_all_src` workqueue handler contains a fatal in= finite loop due to incorrect usage of the `scoped_guard` macro in combinati= on with `break` statements, monopolizing 100% of a CPU core. - [High] Double decrement of the `esparser_queued_bufs` atomic counter per = video frame leads to counter underflow and buffer overruns. - [High] The 32 MiB VIFIFO buffer increase causes the bitstream size to ove= rflow the 32-bit hardware PARSER_CONTROL register calculation, crashing the= esparser DMA engine. Pre-existing issues: - [Critical] In `vp9_update_header`, an integer overflow when decoding mali= ciously crafted frame magnitudes allows `frame_size` to become negative, by= passing size validations and triggering a massive out-of-bounds `memmove` t= hat panics the kernel. - [High] Physical address truncation for the hardware ring buffer end point= er causes immediate DMA corruption when memory is allocated near the top of= the 32-bit address space. - [High] Use-After-Free (UAF) vulnerabilities in `vdec_close` during device= unbind due to `devm_kzalloc` and `v4l2_m2m_release` lifecycle mismatches. - [Medium] Timestamp tracking and matching breaks silently when the 32-bit = hardware offset wraps around at the 4 GB bitstream boundary, due to an impr= oper naive unsigned sequence comparison. - [Medium] Race condition in `esparser_write_data` overwrites the completio= n flag, causing false input parsing timeouts. -- --- Patch [18]: [PATCH v7 18/19] media: meson: vdec: Increase VIFIFO buffer= size to 32 MiB --- commit 2addc7a4961dc5fcc69dfbb2e96d57eb89853de9 Author: Anand Moon media: meson: vdec: Increase VIFIFO buffer size to 32 MiB During 4K video playback, the hardware Elementary Stream Parser (esparser) can rapidly push massive burst data payloads into the Video Input FIFO faster than the VPU decoding block can consume it. This causes a buffer overflow when stream usage breaks past the allocated hardware boundary. This patch doubles the parsed bitstream swap exchange memory pool to 32 MiB. > diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/me= dia/meson/vdec/vdec.c > index d33cbebc4453b..824e2f156adeb 100644 > --- a/drivers/staging/media/meson/vdec/vdec.c > +++ b/drivers/staging/media/meson/vdec/vdec.c > @@ -29,8 +29,8 @@ struct dummy_buf { > struct list_head list; > }; > =20 > -/* 16 MiB for parsed bitstream swap exchange */ > -#define SIZE_VIFIFO SZ_16M > +/* 32 MiB for parsed bitstream swap exchange */ > +#define SIZE_VIFIFO SZ_32M [Severity: High] Does increasing the buffer to 32 MiB cause the bitstream size to overflow the 32-bit hardware PARSER_CONTROL register calculation? In drivers/staging/media/meson/vdec/esparser.c:esparser_write_data(): amvdec_write_parser(core, PARSER_CONTROL, ES_WRITE | ES_PARSER_START | ES_SEARCH | (size << ES_PACK_SIZE_BIT)); With ES_PACK_SIZE_BIT being 8, for a size >=3D 16 MiB this left shift will overflow a 32-bit unsigned integer. This can result in the DMA engine receiving a truncated payload size and crashing. [Severity: High] This is a pre-existing issue, but does increasing the buffer size make it highly probable that the hardware ring buffer end pointer truncates, causing immediate DMA corruption? In drivers/staging/media/meson/vdec/vdec_hevc.c:vdec_hevc_stbuf_init(): amvdec_write_dos(core, HEVC_STREAM_END_ADDR, sess->vififo_paddr + sess->vififo_size); If the VIFIFO buffer is allocated near the end of the 32-bit address space, the calculation sess->vififo_paddr + sess->vififo_size can exceed 32 bits, resulting in a value like 0x100000000. This is silently truncated to 0 when passed to amvdec_write_dos() which accepts a 32-bit u32. [Severity: Medium] This is a pre-existing issue, but how does the driver handle timestamps when the 32-bit hardware offset wraps around at the 4 GB bitstream boundary? In drivers/staging/media/meson/vdec/vdec_helpers.c:amvdec_dst_buf_done_offs= et(): list_for_each_entry_safe(tmp, n, &sess->timestamps, list) { if (tmp->offset > offset) { ... break; } The stream offset accumulates into a 32-bit integer in esparser_get_offset() that naturally wraps at 4 GB. The list_for_each_entry_safe loop uses a non-wrap-safe raw unsigned comparison. When the offset wraps around to 0, a large tmp->offset immediately evaluates as greater and incorrectly breaks the loop, stranding or dropping timestamps. [Severity: High] Are there Use-After-Free vulnerabilities in vdec_close() during device unbi= nd due to devm_kzalloc() and v4l2_m2m_release() lifecycle mismatches? This isn= 't a bug introduced by this patch, but... In drivers/staging/media/meson/vdec/vdec.c:vdec_remove(): video_unregister_device(core->vdev_dec); v4l2_m2m_release(core->m2m_dev); The unbind path frees the core structure while V4L2 file descriptors may still be actively held by userspace. Later, if an application closes the file descriptor, vdec_close() is invoke= d: synchronize_irq(core->vdec_irq); This could dereference the freed core pointer and the freed m2m_dev. [Severity: High] Does the esparser_queue_all_src() workqueue handler contain an infinite loop that could monopolize a CPU core? In drivers/staging/media/meson/vdec/esparser.c:esparser_queue_all_src(): while (1) { struct vb2_v4l2_buffer *vbuf =3D NULL; bool processed_frame =3D false; scoped_guard(mutex, &sess->lock) { ... vbuf =3D v4l2_m2m_next_src_buf(sess->m2m_ctx); if (!vbuf) break; ... } if (processed_frame) break; ... } The break statements are intended to exit the function when no buffers are available. However, they only escape the scoped_guard's internal for loop. This leaves the outer while (1) loop intact since processed_frame is false, which could result in a lockup of a kernel worker thread. [Severity: High] Does this code double decrement the esparser_queued_bufs atomic counter? In drivers/staging/media/meson/vdec/vdec_helpers.c, dst_buf_done() calls atomic_dec(&sess->esparser_queued_bufs). However, its callers also execute their own atomic_dec(): amvdec_dst_buf_done(): dst_buf_done(sess, vbuf, field, timestamp, timecode, vbuf_flags); atomic_dec(&sess->esparser_queued_bufs); amvdec_dst_buf_done_offset(): dst_buf_done(sess, vbuf, field, timestamp, timecode, vbuf_flags); if (match) atomic_dec(&sess->esparser_queued_bufs); This could lead to counter underflow, bypassing buffer limit checks and causing hardware queue overruns. [Severity: Medium] This is a pre-existing issue, but does esparser_write_data() contain a race condition that overwrites the completion flag? In drivers/staging/media/meson/vdec/esparser.c:esparser_write_data(): amvdec_write_parser(core, PARSER_FETCH_CMD, (7 << FETCH_ENDIAN_BIT) | (size + SEARCH_PATTERN_LEN)); search_done =3D 0; return wait_event_interruptible_timeout(wq, search_done, (HZ / 5)); The CPU initiates hardware processing by writing to PARSER_FETCH_CMD, which can instantly trigger esparser_isr(). If the hardware interrupt fires immediately, the ISR sets search_done =3D 1. The CPU sequentially executes search_done =3D 0 afterwards, which could erase the completion signal before waiting on it. [Severity: Critical] This is a pre-existing issue, but does vp9_update_header() have an integer overflow when decoding frame magnitudes that can bypass size validations? In drivers/staging/media/meson/vdec/esparser.c:vp9_update_header(): frame_size[cur_frame] |=3D (dp[mag_ptr] << (cur_mag * 8)); The magnitude byte is promoted to a signed 32-bit integer. When shifted by 24 bits, it can become a large negative number if the maliciously crafted payload has dp[mag_ptr] >=3D 0x80. Later, this negative frame size bypasses total_datasize validations and triggers an out-of-bounds copy in memmove: memmove(fdata + VP9_HEADER_SIZE, old_framedata, framesize); --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260713120840.1742= 7-1-linux.amoon@gmail.com?part=3D18