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 CCA1DC43458 for ; Mon, 13 Jul 2026 12:55:16 +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=WUGMZksky8cw+xxAeI/Xnd2uymu+1KUzLCp8l4+p/Wg=; b=MqCxcyVL2AIQ3E LtT5hRjmFoeMlrGgib37gGVTTBWpLAATzboXnkqYWS9ppPTvybra1YwSbn+xACXiZLi9/1BGbGCRd 55nWibcSUiZnknADkCHXmffHEynyxxaRopz4/doi2NKE0UyM2fjdLXUaUv/tpCF5/jXXc83BAGHUA lFgAQjWx4BxzFowHe1LkrL2UE450/lVWgMp5JLil8NiwMJpXzzn3/oN9Uw05cktcANJfupFv1FPYe oeQjahZR5thTsHuaSp8gjnRv59NyodhdGqx9pJZwzzOaTIV8IQAnLt08AljHxcJ0SxvYCN6QvNpTc keGpOdDCrzhCa+JIuP/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjGBn-00000009G0y-0J7P; Mon, 13 Jul 2026 12:55: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 1wjGBl-00000009G09-0o0a for linux-amlogic@lists.infradead.org; Mon, 13 Jul 2026 12:55:13 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 840ED600AA; Mon, 13 Jul 2026 12:55:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F8621F000E9; Mon, 13 Jul 2026 12:55:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783947312; bh=eDcr8g8qLo8wZ1+lxgJhIOeDMv3ri/NFrDyckCjdkLw=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=CFofveuWoQZvwOzWotTUe7SuqOU/rkOhXu6pRVPSeuDTD36pr5K3Qnl0Dy//1umU9 eMknIQPwaaNtDBZ9hCAn3oNLXOVipPsk+dcQHJRsTggQEDxUg4aGqXuhIye7E4nwAP h0DjhS8ZN+Z4uGUTl/mVnRFJEYUyb5iq5mCODYzDBxNDhDVzUuf1kxE6dYntk7hQ9u EyU9a78mieYUM3JI/6QCjcolWREhPOCxX+hkdeZzXO9RKfGSSnTxw8hifMWIfp2R6Z Ou+uHGZS/jo00TMBPuI3S0KaY4ODmjemehsZjExZRnLvcNcvz8qrksSBebgQTuGJVy VdE28PWCMBTBA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 16/19] media: meson: vdec: Configure DMA mask and segment size in probe To: "Anand Moon" Cc: neil.armstrong@linaro.org, dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org In-Reply-To: <20260713120840.17427-17-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-17-linux.amoon@gmail.com> Date: Mon, 13 Jul 2026 12:55:10 +0000 Message-Id: <20260713125511.5F8621F000E9@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 NiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBI YXJkd2FyZSBpbnRlcnJ1cHRzIGFyZSBub3QgbWFza2VkIHByaW9yIHRvIGNhbGxpbmcgYHN5bmNo cm9uaXplX2lycSgpYCwgbGVhZGluZyB0byBhIHJhY2UgY29uZGl0aW9uIHRoYXQgY2F1c2VzIGEg VXNlLUFmdGVyLUZyZWUgb2YgYHNlc3MtPnByaXZgLgotIFtIaWdoXSBNaXN1c2Ugb2YgYHNjb3Bl ZF9ndWFyZGAgaW5zaWRlIGEgYHdoaWxlICgxKWAgbG9vcCBjb21iaW5lZCB3aXRoIGludmVydGVk IGxvZ2ljIGNhdXNlcyB0aGUgd29ya3F1ZXVlIHRvIGJ1c3ktd2FpdCBpbmZpbml0ZWx5IHdoZW4g bm8gZGF0YSBpcyBhdmFpbGFibGUuCi0gW01lZGl1bV0gTWlzc2luZyByZWxlYXNlIGJhcnJpZXJz IHdoZW4gcHVibGlzaGluZyBgY29yZS0+Y3VyX3Nlc3NgIGFsbG93cyB0aGUgbG9ja2xlc3MgSVNS IHRvIG9ic2VydmUgYW4gdW5pbml0aWFsaXplZCBvciBzdGFsZSBzZXNzaW9uIHN0YXRlLgoKUHJl LWV4aXN0aW5nIGlzc3VlczoKLSBbQ3JpdGljYWxdIHZwOV91cGRhdGVfaGVhZGVyIHRydXN0cyB1 c2VyLXByb3ZpZGVkIGZyYW1lIHNpemVzIHRvIGNhbGN1bGF0ZSBvZmZzZXRzLCBsZWFkaW5nIHRv IGludGVnZXIgb3ZlcmZsb3dzIGFuZCBtYXNzaXZlIG91dC1vZi1ib3VuZHMgbWVtb3J5IGFjY2Vz c2VzIHZpYSBtZW1tb3ZlLgotIFtIaWdoXSBgbWVzb25fY2FudmFzX2dldGAgcmV0cmlldmVzIGEg cG9pbnRlciB0byB0aGUgcHJvdmlkZXIncyBwcml2YXRlIGRhdGEgYnV0IGltbWVkaWF0ZWx5IGRy b3BzIGl0cyByZWZlcmVuY2UgdG8gdGhlIHByb3ZpZGVyIGRldmljZSwgbGVhZGluZyB0byBhIFVz ZS1BZnRlci1GcmVlIGlmIHRoZSBwcm92aWRlciBkcml2ZXIgaXMgdW5ib3VuZC4KLSBbTWVkaXVt XSBQb3RlbnRpYWwgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlIGlmIHRoZSBkcml2ZXIgaXMgcHJv YmVkIHdpdGhvdXQgYSBkZXZpY2UgdHJlZSBub2RlLgotLQoKLS0tIFBhdGNoIFsxNl06IFtQQVRD SCB2NyAxNi8xOV0gbWVkaWE6IG1lc29uOiB2ZGVjOiBDb25maWd1cmUgRE1BIG1hc2sgYW5kIHNl Z21lbnQgc2l6ZSBpbiBwcm9iZSAtLS0KY29tbWl0IDhkZDM2OWQ5OTRiN2UyYTZhMWZiMGRiNWRj YmExMGEzMmY0NmJlYWEKQXV0aG9yOiBBbmFuZCBNb29uIDxsaW51eC5hbW9vbkBnbWFpbC5jb20+ CgptZWRpYTogbWVzb246IHZkZWM6IENvbmZpZ3VyZSBETUEgbWFzayBhbmQgc2VnbWVudCBzaXpl IGluIHByb2JlCgpUaGlzIGNvbW1pdCBhZGRyZXNzZXMgbWlzc2luZyBleHBsaWNpdCBETUEgY29u c3RyYWludHMgaW4gdGhlIHZkZWMgcHJvYmUKcm91dGluZS4gSXQgZW5mb3JjZXMgYSAzMi1iaXQg Y29oZXJlbnQgRE1BIGFsbG9jYXRpb24gd2luZG93IGFuZCBtYXhpbWl6ZXMKdGhlIGNvbnRpZ3Vv dXMgYWxsb2NhdGlvbiBzZWdtZW50IGJvdW5kYXJ5IGNvbnN0cmFpbnQgdG8gVUlOVF9NQVguCgo+ IGRpZmYgLS1naXQgYS9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy92ZGVjLmMgYi9k cml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy92ZGVjLmMKPiAtLS0gYS9kcml2ZXJzL3N0 YWdpbmcvbWVkaWEvbWVzb24vdmRlYy92ZGVjLmMKPiArKysgYi9kcml2ZXJzL3N0YWdpbmcvbWVk aWEvbWVzb24vdmRlYy92ZGVjLmMKPiBAQCAtMTE4Niw2ICsxMTg2LDE2IEBAIHN0YXRpYyBpbnQg dmRlY19wcm9iZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQo+ICAJaWYgKElTX0VSUihj b3JlLT5jYW52YXMpKQo+ICAJCXJldHVybiBQVFJfRVJSKGNvcmUtPmNhbnZhcyk7Cj4gIAo+ICsJ LyogRW5mb3JjZSBzdHJpY3QgMzItYml0IERNQSBsaW1pdCB0byBtYXRjaCBoYXJkd2FyZSBjYXBh YmlsaXRpZXMgKi8KPiArCXJldCA9IGRtYV9zZXRfbWFza19hbmRfY29oZXJlbnQoZGV2LCBETUFf QklUX01BU0soMzIpKTsKPiArCWlmIChyZXQpCj4gKwkJcmV0dXJuIGRldl9lcnJfcHJvYmUoZGV2 LCByZXQsICJGYWlsZWQgdG8gc2V0IDMyLWJpdCBETUEgbWFza1xuIik7Cj4gKwo+ICsJcmV0ID0g dmIyX2RtYV9jb250aWdfc2V0X21heF9zZWdfc2l6ZShkZXYsIFVJTlRfTUFYKTsKPiArCWlmIChy ZXQpCj4gKwkJcmV0dXJuIGRldl9lcnJfcHJvYmUoZGV2LCByZXQsCj4gKwkJCQkgICAgICJGYWls ZWQgdG8gc2V0IERNQSBtYXggc2VnbWVudCBzaXplXG4iKTsKPiArCj4gIAlvZl9pZCA9IG9mX21h dGNoX25vZGUodmRlY19kdF9tYXRjaCwgZGV2LT5vZl9ub2RlKTsKPiAgCWNvcmUtPnBsYXRmb3Jt ID0gb2ZfaWQtPmRhdGE7CgpbU2V2ZXJpdHk6IE1lZGl1bV0KVGhpcyBpc24ndCBhIGJ1ZyBpbnRy b2R1Y2VkIGJ5IHRoaXMgcGF0Y2gsIGJ1dCBjYW4gdGhpcyBsZWFkIHRvIGEgTlVMTCBwb2ludGVy CmRlcmVmZXJlbmNlIGlmIHRoZSBkcml2ZXIgaXMgcHJvYmVkIHdpdGhvdXQgYSBkZXZpY2UgdHJl ZSBub2RlPyBJZiBhIHVzZXIKd2l0aCBwcml2aWxlZ2VzIGJpbmRzIHRoZSBkcml2ZXIgbWFudWFs bHkgdmlhIHN5c2ZzIHdpdGhvdXQgYW4gYXNzb2NpYXRlZApkZXZpY2UgdHJlZSBub2RlLCBkZXYt Pm9mX25vZGUgaXMgTlVMTC4gVGhlIG9mX21hdGNoX25vZGUoKSBjYWxsIHdpbGwKcmV0dXJuIE5V TEwsIGNhdXNpbmcgb2ZfaWQtPmRhdGEgdG8gYmUgZGVyZWZlcmVuY2VkIGJsaW5kbHkuCgpbU2V2 ZXJpdHk6IEhpZ2hdCkNhbiB0aGlzIHJlZ3Jlc3Npb24gY2F1c2UgYSB1c2UtYWZ0ZXItZnJlZSBv ZiBzZXNzLT5wcml2IGluIHRoZSBpbnRlcnJ1cHQKaGFuZGxlcj8KCmRyaXZlcnMvc3RhZ2luZy9t ZWRpYS9tZXNvbi92ZGVjL3ZkZWMuYzp2ZGVjX3N0b3Bfc3RyZWFtaW5nKCkgewouLi4KCQkvKiBT eW5jaHJvbml6ZSBhbmQgZmx1c2ggcGVuZGluZyBoYXJkd2FyZSBpbnRlcnJ1cHQgc2VydmljZSBy b3V0aW5lcyAqLwoJCXN5bmNocm9uaXplX2lycShjb3JlLT52ZGVjX2lycSk7CgkJLyogRW5zdXJl IGVzcGFyc2VyIElTUiBmaW5pc2hlcyBleGVjdXRpbmcgKi8KCQlzeW5jaHJvbml6ZV9pcnEoY29y ZS0+ZXNwYXJzZXJfaXJxKTsKCgkJY2FuY2VsX3dvcmtfc3luYygmc2Vzcy0+ZXNwYXJzZXJfcXVl dWVfd29yayk7CgkJbXV0ZXhfbG9jaygmY29yZS0+bG9jayk7CgoJCWlmIChjb3JlLT5jdXJfc2Vz cyA9PSBzZXNzKSB7CgkJCXZkZWNfcG93ZXJvZmYoc2Vzcyk7Ci4uLgp9CgpJdCBhcHBlYXJzIGhh cmR3YXJlIGludGVycnVwdHMgYXJlIG5vdCBtYXNrZWQgcHJpb3IgdG8gY2FsbGluZwpzeW5jaHJv bml6ZV9pcnEoKSwgd2hpY2ggY291bGQgYWxsb3cgYW4gaW50ZXJydXB0IHRvIGZpcmUgaW1tZWRp YXRlbHkKYWZ0ZXIgc3luY2hyb25pemVfaXJxKCkgcmV0dXJucy4gQmVjYXVzZSB2ZGVjX3Bvd2Vy b2ZmKCkgaXMgcmVzcG9uc2libGUKZm9yIG1hc2tpbmcgdGhlIGhhcmR3YXJlIGludGVycnVwdHMs IGNvdWxkIHRoZSBtYWluIHRocmVhZCB0aGVuIGZyZWUKc2Vzcy0+cHJpdiB3aGlsZSB0aGUgY29u Y3VycmVudGx5IGV4ZWN1dGluZyBJU1IgZGVyZWZlcmVuY2VzIGl0PwoKW1NldmVyaXR5OiBIaWdo XQpEb2VzIHRoaXMgbG9vcCBjb3JyZWN0bHkgcHJvY2VzcyB0aGUgYnVmZmVyIHF1ZXVlIG9yIGRv ZXMgaXQgc3BpbiBpbmZpbml0ZWx5PwoKZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29uL3ZkZWMv ZXNwYXJzZXIuYzplc3BhcnNlcl9xdWV1ZV9hbGxfc3JjKCkgewouLi4KCXdoaWxlICgxKSB7CgkJ c3RydWN0IHZiMl92NGwyX2J1ZmZlciAqdmJ1ZiA9IE5VTEw7CgkJYm9vbCBwcm9jZXNzZWRfZnJh bWUgPSBmYWxzZTsKCgkJc2NvcGVkX2d1YXJkKG11dGV4LCAmc2Vzcy0+bG9jaykgewoJCQkvKiBT YWZlIGF0b21pYyB0cmFja2luZyBjaGVjazogZXhpdCBsb29wIGlmIHNlc3Npb24gaXMgc2h1dHRp bmcgZG93biAqLwoJCQlpZiAoUkVBRF9PTkNFKHNlc3MtPnNob3VsZF9zdG9wKSkKCQkJCXJldHVy bjsKCgkJCS8qIFF1ZXVlIGNvbXBsZXRlbHkgZW1wdHk6IGV4aXQgd29yayBsb29wIGNsZWFubHkg Ki8KCQkJdmJ1ZiA9IHY0bDJfbTJtX25leHRfc3JjX2J1ZihzZXNzLT5tMm1fY3R4KTsKCQkJaWYg KCF2YnVmKQoJCQkJYnJlYWs7Ci4uLgp9CgpXaGVuIHY0bDJfbTJtX25leHRfc3JjX2J1ZigpIHJl dHVybnMgTlVMTCwgdGhlIGJyZWFrIHN0YXRlbWVudCBzZWVtcyB0byBvbmx5CmV4aXQgdGhlIGlu bmVyIGZvciBsb29wIGNyZWF0ZWQgYnkgdGhlIHNjb3BlZF9ndWFyZCBtYWNyby4gVGhpcyBieXBh c3NlcyB0aGUKc3Vic2VxdWVudCBsb29wIGV4aXQgY29uZGl0aW9ucyBhbmQgcmVwZWF0cyB0aGUg d2hpbGUgKDEpIGxvb3AgZW5kbGVzc2x5LApwb3RlbnRpYWxseSBjYXVzaW5nIGEgQ1BVIGxvY2t1 cCBvbiB0aGUgd29ya3F1ZXVlIHRocmVhZC4gQWRkaXRpb25hbGx5LCBpZiBhCmJ1ZmZlciBpcyBw cmVzZW50LCBjb3VsZCB0aGlzIGJyZWFrIG91dCBvZiB0aGUgbG9vcCBjb21wbGV0ZWx5IGluc3Rl YWQgb2YKcHJvY2Vzc2luZyB0aGUgcXVldWU/CgpbU2V2ZXJpdHk6IE1lZGl1bV0KQ2FuIHRoZSBs b2NrbGVzcyBJU1Igb2JzZXJ2ZSBhbiB1bmluaXRpYWxpemVkIG9yIHN0YWxlIHNlc3Npb24gc3Rh dGUgZHVlIHRvCm1pc3NpbmcgcmVsZWFzZSBiYXJyaWVycz8KCmRyaXZlcnMvc3RhZ2luZy9tZWRp YS9tZXNvbi92ZGVjL3ZkZWMuYzp2ZGVjX3N0YXJ0X3N0cmVhbWluZygpIHsKLi4uCgkvKiBJZiBh bHJlYWR5IGhhbGYtaW5pdGlhbGl6ZWQsIGRvIG5vdCByZS1pbml0aWFsaXplICovCglpZiAoc2Vz cy0+c3RhdHVzID09IFNUQVRVU19JTklUKSB7CgkJbXV0ZXhfdW5sb2NrKCZjb3JlLT5sb2NrKTsK CQlyZXR1cm4gMDsKCX0KCglzZXNzLT5zdGF0dXMgPSBTVEFUVVNfSU5JVDsKCWNvcmUtPmN1cl9z ZXNzID0gc2VzczsKCW11dGV4X3VubG9jaygmY29yZS0+bG9jayk7Ci4uLgp9CgpCZWNhdXNlIGNv cmUtPmN1cl9zZXNzIGlzIGFzc2lnbmVkIHVzaW5nIGEgcGxhaW4gc3RvcmUsIGNvdWxkIHRoZSBj b21waWxlciBvcgpDUFUgcmVvcmRlciB0aGlzIHN0b3JlIGJlZm9yZSBlYXJsaWVyIGluaXRpYWxp emF0aW9uIHN0ZXBzIGxpa2UKc2Vzcy0+c3RhdHVzID0gU1RBVFVTX0lOSVQ/IElmIHRoZSBsb2Nr bGVzcyBJU1IgdXNlcyBzbXBfbG9hZF9hY3F1aXJlKCksIGl0Cm1pZ2h0IG9ic2VydmUgdGhlIG5l dyBzZXNzaW9uIHBvaW50ZXIgYnV0IHRoZSBvbGQgbWVtb3J5IHN0YXRlLgoKW1NldmVyaXR5OiBI aWdoXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5nIGlzc3VlLCBidXQgZG9lcyB0aGlzIGNvZGUgY2F1 c2UgYSB1c2UtYWZ0ZXItZnJlZSBpZiB0aGUKcHJvdmlkZXIgZHJpdmVyIGlzIHVuYm91bmQ/Cgpk cml2ZXJzL3NvYy9hbWxvZ2ljL21lc29uLWNhbnZhcy5jOm1lc29uX2NhbnZhc19nZXQoKSB7Ci4u LgoJY2FudmFzX3BkZXYgPSBvZl9maW5kX2RldmljZV9ieV9ub2RlKGNhbnZhc19ub2RlKTsKCW9m X25vZGVfcHV0KGNhbnZhc19ub2RlKTsKCWlmICghY2FudmFzX3BkZXYpCgkJcmV0dXJuIEVSUl9Q VFIoLUVQUk9CRV9ERUZFUik7Ci4uLgoJY2FudmFzID0gZGV2X2dldF9kcnZkYXRhKCZjYW52YXNf cGRldi0+ZGV2KTsKCXB1dF9kZXZpY2UoJmNhbnZhc19wZGV2LT5kZXYpOwoJaWYgKCFjYW52YXMp CgkJcmV0dXJuIEVSUl9QVFIoLUVJTlZBTCk7CgoJcmV0dXJuIGNhbnZhczsKfQoKVGhlIHB1dF9k ZXZpY2UoKSBjYWxsIGltbWVkaWF0ZWx5IGRyb3BzIHRoZSBkZXZpY2UgcmVmZXJlbmNlIGJlZm9y ZSByZXR1cm5pbmcKdGhlIHBvaW50ZXIuIFNpbmNlIG5vIGRldmljZSBsaW5rIGlzIG1haW50YWlu ZWQsIGNvdWxkIGFuIGFkbWluIG9yCnVucHJpdmlsZWdlZCB1c2VyIHdpdGggc3lzZnMgYWNjZXNz IHVuYmluZCB0aGUgYW1sb2dpYy1jYW52YXMgZHJpdmVyLApmcmVlaW5nIHRoZSBtZW1vcnkgd2hp bGUgdGhlIHZkZWMgZHJpdmVyIHN0aWxsIGhvbGRzIGFuZCB1c2VzIHRoZQpkYW5nbGluZyBwb2lu dGVyPwoKW1NldmVyaXR5OiBDcml0aWNhbF0KVGhpcyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwg YnV0IGRvZXMgdGhpcyBzaXplIGNhbGN1bGF0aW9uIHByZXZlbnQgaW50ZWdlcgpvdmVyZmxvd3Mg YW5kIG91dC1vZi1ib3VuZHMgbWVtb3J5IGFjY2Vzc2VzPwoKZHJpdmVycy9zdGFnaW5nL21lZGlh L21lc29uL3ZkZWMvZXNwYXJzZXIuYzp2cDlfdXBkYXRlX2hlYWRlcigpIHsKLi4uCgkJZm9yIChj dXJfZnJhbWUgPSAwOyBjdXJfZnJhbWUgPCBudW1fZnJhbWVzOyBjdXJfZnJhbWUrKykgewoJCQlm cmFtZV9zaXplW2N1cl9mcmFtZV0gPSAwOwoJCQlmb3IgKGN1cl9tYWcgPSAwOyBjdXJfbWFnIDwg bWFnOyBjdXJfbWFnKyspIHsKCQkJCWlmIChtYWdfcHRyID49IGRzaXplKQoJCQkJCXJldHVybiAt RUlOVkFMOwoKCQkJCWZyYW1lX3NpemVbY3VyX2ZyYW1lXSB8PQoJCQkJCShkcFttYWdfcHRyXSA8 PCAoY3VyX21hZyAqIDgpKTsKCQkJCW1hZ19wdHIrKzsKCQkJfQoJCQlpZiAoY3VyX2ZyYW1lID09 IDApCgkJCQl0b3RfZnJhbWVfc2l6ZVtjdXJfZnJhbWVdID0KCQkJCQlmcmFtZV9zaXplW2N1cl9m cmFtZV07CgkJCWVsc2UKCQkJCXRvdF9mcmFtZV9zaXplW2N1cl9mcmFtZV0gPQoJCQkJCXRvdF9m cmFtZV9zaXplW2N1cl9mcmFtZSAtIDFdICsKCQkJCQlmcmFtZV9zaXplW2N1cl9mcmFtZV07CgkJ CXRvdGFsX2RhdGFzaXplICs9IGZyYW1lX3NpemVbY3VyX2ZyYW1lXTsKCQl9Ci4uLgp9CgpJdCBh cHBlYXJzIHVzZXItcHJvdmlkZWQgZnJhbWUgc2l6ZXMgYXJlIGFkZGVkIGJsaW5kbHkgd2l0aG91 dCBvdmVyZmxvdwpwcm90ZWN0aW9uLiBJZiBhIHVzZXIgY3JhZnRzIGEgVjRMMiBWUDkgYnVmZmVy IHBheWxvYWQgd2l0aCB0d28gZnJhbWVzCnNwZWNpZnlpbmcgc2l6ZXMgdGhhdCBzdW0gdG8gMCAo ZS5nLiwgMHg0MDAwMDAwMCBhbmQgMHhDMDAwMDAwMCksIGNvdWxkCnRoaXMgYnlwYXNzIHRoZSBu ZXdfZnJhbWVfc2l6ZSBib3VuZHMgY2hlY2s/IFRoZSBkcml2ZXIgbWlnaHQgdGhlbiB1c2UKb25l IG9mIHRoZSBodWdlIGZyYW1lIHNpemVzIGluIGEgbWVtbW92ZSBvcGVyYXRpb24sIGxlYWRpbmcg dG8Kb3V0LW9mLWJvdW5kcyByZWFkcyBhbmQgd3JpdGVzIG9uIHRoZSBrZXJuZWwgaGVhcC4KCi0t IApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAy NjA3MTMxMjA4NDAuMTc0MjctMS1saW51eC5hbW9vbkBnbWFpbC5jb20/cGFydD0xNgoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYW1sb2dpYyBt YWlsaW5nIGxpc3QKbGludXgtYW1sb2dpY0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0 cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYW1sb2dpYwo= 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 377E9C44501 for ; Mon, 13 Jul 2026 12:55:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9D1AE10E5C5; Mon, 13 Jul 2026 12:55:16 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="CFofveuW"; 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 4AA4A10E5C5 for ; Mon, 13 Jul 2026 12:55: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 840ED600AA; Mon, 13 Jul 2026 12:55:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F8621F000E9; Mon, 13 Jul 2026 12:55:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783947312; bh=eDcr8g8qLo8wZ1+lxgJhIOeDMv3ri/NFrDyckCjdkLw=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=CFofveuWoQZvwOzWotTUe7SuqOU/rkOhXu6pRVPSeuDTD36pr5K3Qnl0Dy//1umU9 eMknIQPwaaNtDBZ9hCAn3oNLXOVipPsk+dcQHJRsTggQEDxUg4aGqXuhIye7E4nwAP h0DjhS8ZN+Z4uGUTl/mVnRFJEYUyb5iq5mCODYzDBxNDhDVzUuf1kxE6dYntk7hQ9u EyU9a78mieYUM3JI/6QCjcolWREhPOCxX+hkdeZzXO9RKfGSSnTxw8hifMWIfp2R6Z Ou+uHGZS/jo00TMBPuI3S0KaY4ODmjemehsZjExZRnLvcNcvz8qrksSBebgQTuGJVy VdE28PWCMBTBA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 16/19] media: meson: vdec: Configure DMA mask and segment size in probe To: "Anand Moon" Cc: neil.armstrong@linaro.org, dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org In-Reply-To: <20260713120840.17427-17-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-17-linux.amoon@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2026 12:55:10 +0000 Message-Id: <20260713125511.5F8621F000E9@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 6 potential issue(= s) to consider: New issues: - [High] Hardware interrupts are not masked prior to calling `synchronize_i= rq()`, leading to a race condition that causes a Use-After-Free of `sess->p= riv`. - [High] Misuse of `scoped_guard` inside a `while (1)` loop combined with i= nverted logic causes the workqueue to busy-wait infinitely when no data is = available. - [Medium] Missing release barriers when publishing `core->cur_sess` allows= the lockless ISR to observe an uninitialized or stale session state. Pre-existing issues: - [Critical] vp9_update_header trusts user-provided frame sizes to calculat= e offsets, leading to integer overflows and massive out-of-bounds memory ac= cesses via memmove. - [High] `meson_canvas_get` retrieves a pointer to the provider's private d= ata but immediately drops its reference to the provider device, leading to = a Use-After-Free if the provider driver is unbound. - [Medium] Potential NULL pointer dereference if the driver is probed witho= ut a device tree node. -- --- Patch [16]: [PATCH v7 16/19] media: meson: vdec: Configure DMA mask and= segment size in probe --- commit 8dd369d994b7e2a6a1fb0db5dcba10a32f46beaa Author: Anand Moon media: meson: vdec: Configure DMA mask and segment size in probe This commit addresses missing explicit DMA constraints in the vdec probe routine. It enforces a 32-bit coherent DMA allocation window and maximizes the contiguous allocation segment boundary constraint to UINT_MAX. > diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/me= dia/meson/vdec/vdec.c > --- a/drivers/staging/media/meson/vdec/vdec.c > +++ b/drivers/staging/media/meson/vdec/vdec.c > @@ -1186,6 +1186,16 @@ static int vdec_probe(struct platform_device *pdev) > if (IS_ERR(core->canvas)) > return PTR_ERR(core->canvas); > =20 > + /* Enforce strict 32-bit DMA limit to match hardware capabilities */ > + ret =3D dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)); > + if (ret) > + return dev_err_probe(dev, ret, "Failed to set 32-bit DMA mask\n"); > + > + ret =3D vb2_dma_contig_set_max_seg_size(dev, UINT_MAX); > + if (ret) > + return dev_err_probe(dev, ret, > + "Failed to set DMA max segment size\n"); > + > of_id =3D of_match_node(vdec_dt_match, dev->of_node); > core->platform =3D of_id->data; [Severity: Medium] This isn't a bug introduced by this patch, but can this lead to a NULL poin= ter dereference if the driver is probed without a device tree node? If a user with privileges binds the driver manually via sysfs without an associated device tree node, dev->of_node is NULL. The of_match_node() call will return NULL, causing of_id->data to be dereferenced blindly. [Severity: High] Can this regression cause a use-after-free of sess->priv in the interrupt handler? drivers/staging/media/meson/vdec/vdec.c:vdec_stop_streaming() { ... /* Synchronize and flush pending hardware interrupt service routines */ synchronize_irq(core->vdec_irq); /* Ensure esparser ISR finishes executing */ synchronize_irq(core->esparser_irq); cancel_work_sync(&sess->esparser_queue_work); mutex_lock(&core->lock); if (core->cur_sess =3D=3D sess) { vdec_poweroff(sess); ... } It appears hardware interrupts are not masked prior to calling synchronize_irq(), which could allow an interrupt to fire immediately after synchronize_irq() returns. Because vdec_poweroff() is responsible for masking the hardware interrupts, could the main thread then free sess->priv while the concurrently executing ISR dereferences it? [Severity: High] Does this loop correctly process the buffer queue or does it spin infinitel= y? 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) { /* Safe atomic tracking check: exit loop if session is shutting down */ if (READ_ONCE(sess->should_stop)) return; /* Queue completely empty: exit work loop cleanly */ vbuf =3D v4l2_m2m_next_src_buf(sess->m2m_ctx); if (!vbuf) break; ... } When v4l2_m2m_next_src_buf() returns NULL, the break statement seems to only exit the inner for loop created by the scoped_guard macro. This bypasses the subsequent loop exit conditions and repeats the while (1) loop endlessly, potentially causing a CPU lockup on the workqueue thread. Additionally, if a buffer is present, could this break out of the loop completely instead of processing the queue? [Severity: Medium] Can the lockless ISR observe an uninitialized or stale session state due to missing release barriers? drivers/staging/media/meson/vdec/vdec.c:vdec_start_streaming() { ... /* If already half-initialized, do not re-initialize */ if (sess->status =3D=3D STATUS_INIT) { mutex_unlock(&core->lock); return 0; } sess->status =3D STATUS_INIT; core->cur_sess =3D sess; mutex_unlock(&core->lock); ... } Because core->cur_sess is assigned using a plain store, could the compiler = or CPU reorder this store before earlier initialization steps like sess->status =3D STATUS_INIT? If the lockless ISR uses smp_load_acquire(), = it might observe the new session pointer but the old memory state. [Severity: High] This is a pre-existing issue, but does this code cause a use-after-free if = the provider driver is unbound? drivers/soc/amlogic/meson-canvas.c:meson_canvas_get() { ... canvas_pdev =3D of_find_device_by_node(canvas_node); of_node_put(canvas_node); if (!canvas_pdev) return ERR_PTR(-EPROBE_DEFER); ... canvas =3D dev_get_drvdata(&canvas_pdev->dev); put_device(&canvas_pdev->dev); if (!canvas) return ERR_PTR(-EINVAL); return canvas; } The put_device() call immediately drops the device reference before returni= ng the pointer. Since no device link is maintained, could an admin or unprivileged user with sysfs access unbind the amlogic-canvas driver, freeing the memory while the vdec driver still holds and uses the dangling pointer? [Severity: Critical] This is a pre-existing issue, but does this size calculation prevent integer overflows and out-of-bounds memory accesses? drivers/staging/media/meson/vdec/esparser.c:vp9_update_header() { ... for (cur_frame =3D 0; cur_frame < num_frames; cur_frame++) { frame_size[cur_frame] =3D 0; for (cur_mag =3D 0; cur_mag < mag; cur_mag++) { if (mag_ptr >=3D dsize) return -EINVAL; frame_size[cur_frame] |=3D (dp[mag_ptr] << (cur_mag * 8)); mag_ptr++; } if (cur_frame =3D=3D 0) tot_frame_size[cur_frame] =3D frame_size[cur_frame]; else tot_frame_size[cur_frame] =3D tot_frame_size[cur_frame - 1] + frame_size[cur_frame]; total_datasize +=3D frame_size[cur_frame]; } ... } It appears user-provided frame sizes are added blindly without overflow protection. If a user crafts a V4L2 VP9 buffer payload with two frames specifying sizes that sum to 0 (e.g., 0x40000000 and 0xC0000000), could this bypass the new_frame_size bounds check? The driver might then use one of the huge frame sizes in a memmove operation, leading to out-of-bounds reads and writes on the kernel heap. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260713120840.1742= 7-1-linux.amoon@gmail.com?part=3D16