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 3CEF6C44501 for ; Mon, 13 Jul 2026 12:28: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=sWXo/5RuOl1/32pcmHBv2bGm9RYXSci2s5QZ3WiD+HI=; b=YNGL3uPHCzY3mr i98cHke7/nwivLbYmewmiKBcdMPdjBjBw4aZwQqWfzAao7+B+khnJHSTYDLnhV6ffOKL5xLL4SL6V nRoBRc0Pb9sSe4FQSSQWNje8pJwXlDw1qP5fmObU/eAWM46UsXsiP6eDWmhWg6q/xfyKBofzcc01o 67GfhErZ4qDBoCihTj5/YmCO0GrLnm63zdNwjd2QqUpSAgUeDRONooB8hPdbIRZPGxje+jLRGGQwF EjijqHG9e6ICeTf7OAzRx5NsyA4/F8TBNgFvZcuW4ZuIRlZAwAtJC1rRPkn8RD8Bd5aC83va3Y58/ jszE5DEDqYcts0L14wWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjFmH-00000009CAe-2uRl; Mon, 13 Jul 2026 12:28: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 1wjFmG-00000009CAW-0NBS for linux-amlogic@lists.infradead.org; Mon, 13 Jul 2026 12:28:52 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 4B932402BF; Mon, 13 Jul 2026 12:28:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E21031F000E9; Mon, 13 Jul 2026 12:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783945731; bh=6Uc3VVn8Aq1XfnvrCkubgMWGnVvS2e+ZwNlccy7alJk=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=c57OCsU53v9OHqwVSxShevXigL8VD5yLQBODqmpacHUhMeRXdVn7c8E8kRLc0/Q44 uub4rYoAahxEuKfJ48itSmOZhne0Aw2lAwms3JSlJ2/2hAwQ7hSR4DyhONv2FUeCg0 sbDygiuHzupQjBOEGlBnG+2YpfQlpDrQrjzYVPLjtq9o6jtht3Bt/z1o3wvSi12pY8 Z8ECWOuNgs6CEz87ndCNr9Vx5wt0ORVzDX1qTKypdqWdvzZilQ+A8V5nXyrRVM/90a /Nokrx6SojZYaeWPK6tLSX/Esxt/PgxNBFxwqIQqpQWpFsknwsK1uv7P+z0hf828Sq jh1D2/AWEhgTA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 05/19] media: meson: vdec: Fix race condition and synchronize esparser IRQ To: "Anand Moon" Cc: linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org In-Reply-To: <20260713120840.17427-6-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-6-linux.amoon@gmail.com> Date: Mon, 13 Jul 2026 12:28:50 +0000 Message-Id: <20260713122850.E21031F000E9@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 NCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBU aGUgbmV3bHkgYWRkZWQgZWFybHkgcmV0dXJuIHBhdGggaW4gYGVzcGFyc2VyX2lzcigpYCBpbmNv cnJlY3RseSByZXR1cm5zIGBJUlFfSEFORExFRGAgd2l0aG91dCBjbGVhcmluZyB0aGUgaGFyZHdh cmUgaW50ZXJydXB0IHN0YXR1cywgbGVhZGluZyB0byBhbiBpbnRlcnJ1cHQgc3Rvcm0gYW5kIHZp b2xhdGluZyBzaGFyZWQgSVJRIHNlbWFudGljcy4KLSBbTWVkaXVtXSBUaGUgY29tbWl0IG1lc3Nh Z2UgZmFsc2VseSBjbGFpbXMgdG8gZml4IGEgcmFjZSBjb25kaXRpb24gd2hlcmUgdGhlIElTUiAn YXR0ZW1wdHMgdG8gaGFuZGxlIHN0cmVhbSBkYXRhIGFuZCBhbGxvY2F0ZSBpbnRlcm5hbCB0cmFj a2luZyBzdGF0ZSBzdHJ1Y3R1cmVzJywgd2hpY2ggZG9lcyBub3QgZXhpc3QgaW4gdGhlIGNvZGUu CgpQcmUtZXhpc3RpbmcgaXNzdWVzOgotIFtIaWdoXSBUaGUgc3luY2hyb25pemF0aW9uIGFuZCBl YXJseS1leGl0IGxvZ2ljIGludHJvZHVjZWQgYnkgdGhlIHBhdGNoIGlzIGluZWZmZWN0aXZlIGFu ZCBsZWF2ZXMgdGhlIHN5c3RlbSB2dWxuZXJhYmxlIHRvIHN5bmNocm9ub3VzIGJ1cyBmYXVsdHMg ZHVyaW5nIHRlYXJkb3duLgotIFtIaWdoXSBVbmNvbmRpdGlvbmFsIGV4ZWN1dGlvbiBvZiBgdmRl Y19wb3dlcm9mZigpYCBpbiBgdmRlY19jbG9zZSgpYCBjYXVzZXMgY2xvY2sgdW5kZXJmbG93cy4K LS0KCi0tLSBQYXRjaCBbNV06IFtQQVRDSCB2NyAwNS8xOV0gbWVkaWE6IG1lc29uOiB2ZGVjOiBG aXggcmFjZSBjb25kaXRpb24gYW5kIHN5bmNocm9uaXplIGVzcGFyc2VyIElSUSAtLS0KY29tbWl0 IDJmN2U1NTllMzJiNDNkMDY4ZjFlNTM5MGYwMjNmYmY3Zjc1ZjEyNjIKQXV0aG9yOiBBbmFuZCBN b29uIDxsaW51eC5hbW9vbkBnbWFpbC5jb20+CgptZWRpYTogbWVzb246IHZkZWM6IEZpeCByYWNl IGNvbmRpdGlvbiBhbmQgc3luY2hyb25pemUgZXNwYXJzZXIgSVJRCgpUaGlzIGNvbW1pdCBhdHRl bXB0cyB0byBmaXggYSByYWNlIGNvbmRpdGlvbiBkdXJpbmcgc2Vzc2lvbiB0ZWFyZG93biBzZXF1 ZW5jZXMKYnkgc3luY2hyb25pemluZyB0aGUgZXNwYXJzZXIgSVJRIGFuZCBhZGRpbmcgYSBOVUxM IGNoZWNrIGZvciB0aGUgc2Vzc2lvbgpwb2ludGVyIGluIHRoZSBJU1IuIEl0IGFpbXMgdG8gcHJl dmVudCB0aGUgaW50ZXJydXB0IGhhbmRsZXIgZnJvbSBydW5uaW5nCndoaWxlIGNvbnRleHQgc3Ry dWN0dXJlcyBhcmUgZGlzbWFudGxlZC4KCkNsb3NlczogaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcv YWxsLzIwMjYwNTIxMDkwOTQ0LkYzNTQwMUYwMEEzREBzbXRwLmtlcm5lbC5vcmcvCgo+IER1cmlu ZyBzZXNzaW9uIHRlYXJkb3duIHNlcXVlbmNlcyBpbiB2ZGVjX3N0b3Bfc3RyZWFtaW5nKCkgYW5k Cj4gdmRlY19jbG9zZSgpLCB0aGUgJ2VzcGFyc2VyJyBoYXJkd2FyZSBpbnRlcnJ1cHQgaGFuZGxl ciBjYW4gc3RpbGwgYmUKPiBhY3RpdmVseSB0cmlnZ2VyZWQgb3IgZXhlY3V0aW5nIG9uIGFub3Ro ZXIgQ1BVIGNvcmUuIFRoaXMgY3JlYXRlcyBhCj4gdHJhbnNpZW50IHJhY2UgY29uZGl0aW9uIHdo ZXJlIHRoZSBJU1IgYXR0ZW1wdHMgdG8gaGFuZGxlIHN0cmVhbSBkYXRhIGFuZAo+IGFsbG9jYXRl IGludGVybmFsIHRyYWNraW5nIHN0YXRlIHN0cnVjdHVyZXMgYWZ0ZXIgc2Vzc2lvbiBjb250ZXh0 cyBoYXZlCj4gYmVlbiBtb2RpZmllZCBvciBmcmVlZC4KCltTZXZlcml0eTogTWVkaXVtXQpEb2Vz IHRoZSBJU1IgYWN0dWFsbHkgYWxsb2NhdGUgdHJhY2tpbmcgc3RhdGUgb3IgaGFuZGxlIHN0cmVh bSBkYXRhPwoKTG9va2luZyBhdCBlc3BhcnNlcl9pc3IoKSwgdGhlIHNlc3MgcG9pbnRlciBpcyBy ZXRyaWV2ZWQgYW5kIGNoZWNrZWQgZm9yIE5VTEwsCmJ1dCB0aGUgcmVzdCBvZiB0aGUgSVNSIGRv ZXMgbm90IGFwcGVhciB0byBkZXJlZmVyZW5jZSB0aGlzIHBvaW50ZXIgb3IKYWxsb2NhdGUgYW55 IGludGVybmFsIHRyYWNraW5nIHN0cnVjdHVyZXMuCgo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3N0 YWdpbmcvbWVkaWEvbWVzb24vdmRlYy9lc3BhcnNlci5jIGIvZHJpdmVycy9zdGFnaW5nL21lZGlh L21lc29uL3ZkZWMvZXNwYXJzZXIuYwo+IGluZGV4IDQ2MzIzNDZmMDRhOWUuLjM3NzQ5ZWRlMzA4 YzYgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29uL3ZkZWMvZXNwYXJz ZXIuYwo+ICsrKyBiL2RyaXZlcnMvc3RhZ2luZy9tZWRpYS9tZXNvbi92ZGVjL2VzcGFyc2VyLmMK PiBAQCAtNjAsNiArNjAsMTIgQEAgc3RhdGljIGlycXJldHVybl90IGVzcGFyc2VyX2lzcihpbnQg aXJxLCB2b2lkICpkZXYpCj4gIHsKPiAgCWludCBpbnRfc3RhdHVzOwo+ICAJc3RydWN0IGFtdmRl Y19jb3JlICpjb3JlID0gZGV2Owo+ICsJc3RydWN0IGFtdmRlY19zZXNzaW9uICpzZXNzOwo+ICsK PiArCS8qIFNlY3VyZSBhbiBhdG9taWMgc25hcHNob3QgdG8gcHJvdGVjdCBhZ2FpbnN0IGNvbmN1 cnJlbnQgdGVhcmRvd24gKi8KPiArCXNlc3MgPSBzbXBfbG9hZF9hY3F1aXJlKCZjb3JlLT5jdXJf c2Vzcyk7Cj4gKwlpZiAoIXNlc3MpCj4gKwkJcmV0dXJuIElSUV9IQU5ETEVEOwoKW1NldmVyaXR5 OiBIaWdoXQpJcyBpdCBzYWZlIHRvIHJldHVybiBJUlFfSEFORExFRCBoZXJlIHdpdGhvdXQgaW50 ZXJhY3Rpbmcgd2l0aCB0aGUgaGFyZHdhcmUKdG8gY2xlYXIgdGhlIGludGVycnVwdD8KCkJlY2F1 c2UgZXNwYXJzZXJfaXJxIGlzIHJlZ2lzdGVyZWQgd2l0aCBJUlFGX1NIQVJFRCwgcmV0dXJuaW5n IElSUV9IQU5ETEVECndoZW4gY3VyX3Nlc3MgaXMgTlVMTCBmYWxzZWx5IHRlbGxzIHRoZSBJUlEg c3Vic3lzdGVtIHRoYXQgdGhpcyBkcml2ZXIKaGFuZGxlZCB0aGUgaW50ZXJydXB0LgoKV2lsbCB0 aGlzIGNhdXNlIGFuIGludGVycnVwdCBzdG9ybSBmb3IgbGV2ZWwtdHJpZ2dlcmVkIGludGVycnVw dHMsIG9yIGJyZWFrCnNwdXJpb3VzIGludGVycnVwdCBkZXRlY3Rpb24gZm9yIG90aGVyIGRldmlj ZXMgc2hhcmluZyB0aGlzIElSUSBsaW5lPwoKPiAgCj4gIAlpbnRfc3RhdHVzID0gYW12ZGVjX3Jl YWRfcGFyc2VyKGNvcmUsIFBBUlNFUl9JTlRfU1RBVFVTKTsKPiAgCWFtdmRlY193cml0ZV9wYXJz ZXIoY29yZSwgUEFSU0VSX0lOVF9TVEFUVVMsIGludF9zdGF0dXMpOwoKWyAuLi4gXQoKPiBkaWZm IC0tZ2l0IGEvZHJpdmVycy9zdGFnaW5nL21lZGlhL21lc29uL3ZkZWMvdmRlYy5jIGIvZHJpdmVy cy9zdGFnaW5nL21lZGlhL21lc29uL3ZkZWMvdmRlYy5jCj4gaW5kZXggN2FlM2Q1YTlkZDZhYi4u NzY4OWZmZGIyZTUwMCAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24v dmRlYy92ZGVjLmMKPiArKysgYi9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvbWVzb24vdmRlYy92ZGVj LmMKPiBAQCAtNDg2LDYgKzQ4Niw4IEBAIHN0YXRpYyB2b2lkIHZkZWNfc3RvcF9zdHJlYW1pbmco c3RydWN0IHZiMl9xdWV1ZSAqcSkKPiAgCj4gIAkJLyogU3luY2hyb25pemUgYW5kIGZsdXNoIHBl bmRpbmcgaGFyZHdhcmUgaW50ZXJydXB0IHNlcnZpY2Ugcm91dGluZXMgKi8KPiAgCQlzeW5jaHJv bml6ZV9pcnEoY29yZS0+dmRlY19pcnEpOwo+ICsJCS8qIEVuc3VyZSBlc3BhcnNlciBJU1IgZmlu aXNoZXMgZXhlY3V0aW5nICovCj4gKwkJc3luY2hyb25pemVfaXJxKGNvcmUtPmVzcGFyc2VyX2ly cSk7Cj4gIAo+ICAJCXZkZWNfcG93ZXJvZmYoc2Vzcyk7Cj4gIAkJdmRlY19mcmVlX2NhbnZhcyhz ZXNzKTsKCltTZXZlcml0eTogSGlnaF0KVGhpcyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0 IGRvZXMgdGhpcyBzeW5jaHJvbml6YXRpb24gbG9naWMgZnVsbHkKY2xvc2UgdGhlIHJhY2UgY29u ZGl0aW9uPwoKVGhlIHN5bmNocm9uaXplX2lycSgpIGNhbGwgd2FpdHMgZm9yIGluLWZsaWdodCBJ U1JzLCBidXQgdGhlIGludGVycnVwdCBsaW5lCnJlbWFpbnMgZW5hYmxlZC4gTGF0ZXIgaW4gdGhp cyB0ZWFyZG93biBwYXRoOgoKdmRlY19zdG9wX3N0cmVhbWluZygpCiAgICB2ZGVjX3Bvd2Vyb2Zm KHNlc3MpOwogICAgLi4uCiAgICBzbXBfc3RvcmVfcmVsZWFzZSgmY29yZS0+Y3VyX3Nlc3MsIE5V TEwpOwoKSWYgdGhlIGludGVycnVwdCBmaXJlcyBhZnRlciB2ZGVjX3Bvd2Vyb2ZmKCkgY29tcGxl dGVzLCBidXQgYmVmb3JlIGN1cl9zZXNzCmlzIHNldCB0byBOVUxMLCB0aGUgSVNSIHdpbGwgcGFz cyB0aGUgIXNlc3MgY2hlY2sgYW5kIGF0dGVtcHQgdG8gcmVhZApQQVJTRVJfSU5UX1NUQVRVUyBm cm9tIHVuY2xvY2tlZCBoYXJkd2FyZS4KCkNvdWxkIHRoaXMgbGVhZCB0byBhIHN5bmNocm9ub3Vz IGJ1cyBmYXVsdCBhbmQga2VybmVsIHBhbmljPwoKWyAuLi4gXQoKPiBAQCAtOTk0LDYgKzk5Niw4 IEBAIHN0YXRpYyBpbnQgdmRlY19jbG9zZShzdHJ1Y3QgZmlsZSAqZmlsZSkKPiAgCj4gIAkvKiBT eW5jaHJvbml6ZSBhbmQgZmx1c2ggcGVuZGluZyBoYXJkd2FyZSBpbnRlcnJ1cHQgc2VydmljZSBy b3V0aW5lcyAqLwo+ICAJc3luY2hyb25pemVfaXJxKGNvcmUtPnZkZWNfaXJxKTsKPiArCS8qIEVu c3VyZSBlc3BhcnNlciBJU1IgZmluaXNoZXMgZXhlY3V0aW5nICovCj4gKwlzeW5jaHJvbml6ZV9p cnEoY29yZS0+ZXNwYXJzZXJfaXJxKTsKPiAgCj4gIAlpZiAoIUlTX0VSUl9PUl9OVUxMKHNlc3Mt PnJlY3ljbGVfdGhyZWFkKSkgewo+ICAJCWt0aHJlYWRfc3RvcChzZXNzLT5yZWN5Y2xlX3RocmVh ZCk7CgpbU2V2ZXJpdHk6IEhpZ2hdClRoaXMgaXMgYSBwcmUtZXhpc3RpbmcgaXNzdWUsIGJ1dCBk b2VzIHZkZWNfY2xvc2UoKSB1bmNvbmRpdGlvbmFsbHkgY2FsbAp2ZGVjX3Bvd2Vyb2ZmKCkgZXZl biBpZiB0aGUgZGV2aWNlIHdhcyBqdXN0IG9wZW5lZCB3aXRob3V0IHN0YXJ0aW5nIHN0cmVhbWlu Zz8KCklmIHZkZWNfb3BlbigpIGlzIGNhbGxlZCBhbmQgaW1tZWRpYXRlbHkgZm9sbG93ZWQgYnkg dmRlY19jbG9zZSgpLCBjYWxsaW5nCnZkZWNfcG93ZXJvZmYoKSB1bmNvbmRpdGlvbmFsbHkgd291 bGQgZXhlY3V0ZSBjbGtfZGlzYWJsZV91bnByZXBhcmUoKSBvbgpkb3NfY2xrIGFuZCBkb3NfcGFy c2VyX2NsayB3aGljaCB3ZXJlIG5ldmVyIGVuYWJsZWQuCgpDYW4gdGhpcyBjYXVzZSBjbG9jayBm cmFtZXdvcmsgdW5kZXJmbG93IHdhcm5pbmdzIGFuZCBwb3RlbnRpYWxseSBkaXNhYmxlCmNsb2Nr cyBmb3Igb3RoZXIgaGFyZHdhcmUgc2hhcmluZyB0aGUgc2FtZSBjbG9jayB0cmVlPwoKLS0gClNh c2hpa28gQUkgcmV2aWV3IMK3IGh0dHBzOi8vc2FzaGlrby5kZXYvIy9wYXRjaHNldC8yMDI2MDcx MzEyMDg0MC4xNzQyNy0xLWxpbnV4LmFtb29uQGdtYWlsLmNvbT9wYXJ0PTUKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFtbG9naWMgbWFpbGlu ZyBsaXN0CmxpbnV4LWFtbG9naWNAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5m cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFtbG9naWMK 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 DD2FFC43458 for ; Mon, 13 Jul 2026 12:28:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4DD4710E5D4; Mon, 13 Jul 2026 12:28:53 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="c57OCsU5"; 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 969BD10E5D4 for ; Mon, 13 Jul 2026 12:28:51 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 4B932402BF; Mon, 13 Jul 2026 12:28:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E21031F000E9; Mon, 13 Jul 2026 12:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783945731; bh=6Uc3VVn8Aq1XfnvrCkubgMWGnVvS2e+ZwNlccy7alJk=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=c57OCsU53v9OHqwVSxShevXigL8VD5yLQBODqmpacHUhMeRXdVn7c8E8kRLc0/Q44 uub4rYoAahxEuKfJ48itSmOZhne0Aw2lAwms3JSlJ2/2hAwQ7hSR4DyhONv2FUeCg0 sbDygiuHzupQjBOEGlBnG+2YpfQlpDrQrjzYVPLjtq9o6jtht3Bt/z1o3wvSi12pY8 Z8ECWOuNgs6CEz87ndCNr9Vx5wt0ORVzDX1qTKypdqWdvzZilQ+A8V5nXyrRVM/90a /Nokrx6SojZYaeWPK6tLSX/Esxt/PgxNBFxwqIQqpQWpFsknwsK1uv7P+z0hf828Sq jh1D2/AWEhgTA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v7 05/19] media: meson: vdec: Fix race condition and synchronize esparser IRQ To: "Anand Moon" Cc: linux-amlogic@lists.infradead.org, dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org In-Reply-To: <20260713120840.17427-6-linux.amoon@gmail.com> References: <20260713120840.17427-1-linux.amoon@gmail.com> <20260713120840.17427-6-linux.amoon@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2026 12:28:50 +0000 Message-Id: <20260713122850.E21031F000E9@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: - [High] The newly added early return path in `esparser_isr()` incorrectly = returns `IRQ_HANDLED` without clearing the hardware interrupt status, leadi= ng to an interrupt storm and violating shared IRQ semantics. - [Medium] The commit message falsely claims to fix a race condition where = the ISR 'attempts to handle stream data and allocate internal tracking stat= e structures', which does not exist in the code. Pre-existing issues: - [High] The synchronization and early-exit logic introduced by the patch i= s ineffective and leaves the system vulnerable to synchronous bus faults du= ring teardown. - [High] Unconditional execution of `vdec_poweroff()` in `vdec_close()` cau= ses clock underflows. -- --- Patch [5]: [PATCH v7 05/19] media: meson: vdec: Fix race condition and = synchronize esparser IRQ --- commit 2f7e559e32b43d068f1e5390f023fbf7f75f1262 Author: Anand Moon media: meson: vdec: Fix race condition and synchronize esparser IRQ This commit attempts to fix a race condition during session teardown sequen= ces by synchronizing the esparser IRQ and adding a NULL check for the session pointer in the ISR. It aims to prevent the interrupt handler from running while context structures are dismantled. Closes: https://lore.kernel.org/all/20260521090944.F35401F00A3D@smtp.kernel= .org/ > During session teardown sequences in vdec_stop_streaming() and > vdec_close(), the 'esparser' hardware interrupt handler can still be > actively triggered or executing on another CPU core. This creates a > transient race condition where the ISR attempts to handle stream data and > allocate internal tracking state structures after session contexts have > been modified or freed. [Severity: Medium] Does the ISR actually allocate tracking state or handle stream data? Looking at esparser_isr(), the sess pointer is retrieved and checked for NU= LL, but the rest of the ISR does not appear to dereference this pointer or allocate any internal tracking structures. > diff --git a/drivers/staging/media/meson/vdec/esparser.c b/drivers/stagin= g/media/meson/vdec/esparser.c > index 4632346f04a9e..37749ede308c6 100644 > --- a/drivers/staging/media/meson/vdec/esparser.c > +++ b/drivers/staging/media/meson/vdec/esparser.c > @@ -60,6 +60,12 @@ static irqreturn_t esparser_isr(int irq, void *dev) > { > int int_status; > struct amvdec_core *core =3D dev; > + struct amvdec_session *sess; > + > + /* Secure an atomic snapshot to protect against concurrent teardown */ > + sess =3D smp_load_acquire(&core->cur_sess); > + if (!sess) > + return IRQ_HANDLED; [Severity: High] Is it safe to return IRQ_HANDLED here without interacting with the hardware to clear the interrupt? Because esparser_irq is registered with IRQF_SHARED, returning IRQ_HANDLED when cur_sess is NULL falsely tells the IRQ subsystem that this driver handled the interrupt. Will this cause an interrupt storm for level-triggered interrupts, or break spurious interrupt detection for other devices sharing this IRQ line? > =20 > int_status =3D amvdec_read_parser(core, PARSER_INT_STATUS); > amvdec_write_parser(core, PARSER_INT_STATUS, int_status); [ ... ] > diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/me= dia/meson/vdec/vdec.c > index 7ae3d5a9dd6ab..7689ffdb2e500 100644 > --- a/drivers/staging/media/meson/vdec/vdec.c > +++ b/drivers/staging/media/meson/vdec/vdec.c > @@ -486,6 +486,8 @@ static void vdec_stop_streaming(struct vb2_queue *q) > =20 > /* Synchronize and flush pending hardware interrupt service routines */ > synchronize_irq(core->vdec_irq); > + /* Ensure esparser ISR finishes executing */ > + synchronize_irq(core->esparser_irq); > =20 > vdec_poweroff(sess); > vdec_free_canvas(sess); [Severity: High] This is a pre-existing issue, but does this synchronization logic fully close the race condition? The synchronize_irq() call waits for in-flight ISRs, but the interrupt line remains enabled. Later in this teardown path: vdec_stop_streaming() vdec_poweroff(sess); ... smp_store_release(&core->cur_sess, NULL); If the interrupt fires after vdec_poweroff() completes, but before cur_sess is set to NULL, the ISR will pass the !sess check and attempt to read PARSER_INT_STATUS from unclocked hardware. Could this lead to a synchronous bus fault and kernel panic? [ ... ] > @@ -994,6 +996,8 @@ static int vdec_close(struct file *file) > =20 > /* Synchronize and flush pending hardware interrupt service routines */ > synchronize_irq(core->vdec_irq); > + /* Ensure esparser ISR finishes executing */ > + synchronize_irq(core->esparser_irq); > =20 > if (!IS_ERR_OR_NULL(sess->recycle_thread)) { > kthread_stop(sess->recycle_thread); [Severity: High] This is a pre-existing issue, but does vdec_close() unconditionally call vdec_poweroff() even if the device was just opened without starting streami= ng? If vdec_open() is called and immediately followed by vdec_close(), calling vdec_poweroff() unconditionally would execute clk_disable_unprepare() on dos_clk and dos_parser_clk which were never enabled. Can this cause clock framework underflow warnings and potentially disable clocks for other hardware sharing the same clock tree? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260713120840.1742= 7-1-linux.amoon@gmail.com?part=3D5