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 626FBC79F82 for ; Tue, 8 Sep 2026 10:00:19 +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=mus+WL5SunEL0L2q6Mx7UFjYq7R4GcBIybCs6YLZmY8=; b=hBgbhDQE0HdNc8 jbGnV641tz4Xya6YPiYi4M//U44WmfjLX/NPlDbV95XxNLFsDBFBE0d+Bwvf9idB4Kxc4L1taZOER e6mUtrEgEJwLI2L0vkHt4kHK/f4c93MGwe9jxhzFnH8ylwD5391AMkRYI2ny7NvYjIwWXZkciJlmy 3KjeA+RGShfEuKZvjzkE9NmW1FXhhwjA3vhhi6vvgS5umMrtHRkEkVH3YDFo+VjGCtytUFPnsbHPK 9g+kfjN6LIlyzaLgKkXNZvrhvIKnOO/Y60O3//ySYqVeUQBqJ8xt8LVAXH3tb5w1z7BO5BPEFdwvY EQquAH1sn9b5zC899zPA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3sci-00000008i5k-4BWB; Tue, 08 Sep 2026 10:00:19 +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 1x3sch-00000008i5T-3EqA for linux-i3c@lists.infradead.org; Tue, 08 Sep 2026 10:00:15 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 87F3841573; Tue, 8 Sep 2026 10:00:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 109811F00A3A; Tue, 8 Sep 2026 10:00:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788861615; bh=nou0oXP9hRCLsU1cEsbfDPsg4+dtEPcqi5lmpwYxVeE=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=QFJx8F6s5l2tVNbdHuom48d6KaLGeJ1nTW5wa19KbAn9GEK3G9jucM7sdHTi6ETWm 4hG71pAjeoxCUqPRGTuV0i9Vztff7P1kmWx4DQWtASBDqLVt/G1jNORJSLi5wZ1hSO cUAsy9pS93f3Ey7jo9tEC+pMDMceUJONa9Puuwu+n6ZhpLnrnFE0tK1ASfq90FdYey hn0pafezuQp/d3UhoRatESfmnCTskNHXWMARa7/Pp2yM1xnw2D+1mBuVPWEHaLkc10 LaU1XoLw77QfVLICCIld2xpRlUWVzPpkCWiclhgKhVjbHyhwVyzkTfyVJINWWB8W/p vhW55etrwpPFA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 2/3] i3c: master: amd: Add support for in-band interrupts To: "Shubham Patil" Cc: linux-i3c@lists.infradead.org, conor+dt@kernel.org, devicetree@vger.kernel.org, Frank.Li@kernel.org, robh@kernel.org, "Alexandre Belloni" In-Reply-To: <20260908094257.3196120-3-shubhamsanjay.patil@amd.com> References: <20260908094257.3196120-1-shubhamsanjay.patil@amd.com> <20260908094257.3196120-3-shubhamsanjay.patil@amd.com> Date: Tue, 08 Sep 2026 10:00:14 +0000 Message-Id: <20260908100015.109811F00A3A@smtp.kernel.org> X-BeenThere: linux-i3c@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-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIEVhZ2VybHkgZHJhaW5p bmcgdGhlIHNoYXJlZCBSWCBGSUZPIGR1cmluZyBhIHBvbGxlZCByZWFkIHRyYW5zZmVyIGNvbnN1 bWVzIGluLWZsaWdodCBJQkkgcGF5bG9hZHMsIGNvcnJ1cHRpbmcgYm90aCB0aGUgSUJJIGFuZCB0 aGUgdHJhbnNmZXIgZGF0YS4KLSBbSGlnaF0gRnJlZWluZyB0aGUgSUJJIHBvb2wgYmVmb3JlIHRo ZSB3b3JrcXVldWUgaXMgZmx1c2hlZCBjYXVzZXMgYSBVQUYgYW5kIE5VTEwgcG9pbnRlciBkZXJl ZmVyZW5jZSBpZiBhIHN0cmF5IElCSSBpcyBxdWV1ZWQgYWZ0ZXIgZGlzYWJsZS4KLS0KCmNvbW1p dCA0ZTcxZmQ4MDlmZWJjODFhYTVlN2JjODA5YzFjZTRmYTYxOGVjNWE3CkF1dGhvcjogU2h1Ymhh bSBQYXRpbCA8c2h1YmhhbXNhbmpheS5wYXRpbEBhbWQuY29tPgoKaTNjOiBtYXN0ZXI6IGFtZDog QWRkIHN1cHBvcnQgZm9yIGluLWJhbmQgaW50ZXJydXB0cwoKQWRkIHN1cHBvcnQgZm9yIHJlY2Vp dmluZyBhbmQgZGVxdWV1ZWluZyBJM0MgaW4tYmFuZCBpbnRlcnJ1cHRzLiBJQkkKc3VwcG9ydCBp cyBvcHRpb25hbCBhdCBzeW50aGVzaXMgdGltZSwgc28gdGhlIG9wcyBhcmUgYXNzZW1ibGVkIGF0 IHByb2JlCnRpbWUuIFRoZSBjb250cm9sbGVyIGludGVycnVwdCBjYXJyaWVzIElCSSBldmVudHMg b25seS4KCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaTNjL21hc3Rlci9hbWQtaTNjLW1hc3Rlci5j IGIvZHJpdmVycy9pM2MvbWFzdGVyL2FtZC1pM2MtbWFzdGVyLmMKPiBpbmRleCBlZjVhZDVhYmI3 ODhjLi44YThhYjNjZDJmYTQwIDEwMDY0NAo+IC0tLSBhL2RyaXZlcnMvaTNjL21hc3Rlci9hbWQt aTNjLW1hc3Rlci5jCj4gKysrIGIvZHJpdmVycy9pM2MvbWFzdGVyL2FtZC1pM2MtbWFzdGVyLmMK ClsgLi4uIF0KCj4gQEAgLTYwNiwxNCArNjc4LDIxIEBAIHN0YXRpYyBpbnQgeGkzY19tYXN0ZXJf cmVhZChzdHJ1Y3QgeGkzY19tYXN0ZXIgKm1hc3Rlciwgc3RydWN0IHhpM2NfY21kICpjbWQpCj4g IAkJcmV0dXJuIHJldDsKPiAgCX0KPiAgCj4gLQlpZiAoIShzdGF0dXNfcmVnICYgWEkzQ19SRF9G SUZPX05PVF9FTVBUWV9NQVNLKSkKPiArCS8qCj4gKwkgKiBObyBkYXRhIHF1ZXVlZCBtZWFucyB0 aGlzIHJlYWQgcHJvZHVjZWQgbm9uZSwgdW5sZXNzIHdoYXQgaXMgcXVldWVkCj4gKwkgKiBpcyBh biBJQkkgcmVzcG9uc2UgdGhhdCByYWNlZCB3aXRoIGl0OyB4aTNjX3hmZXJfcmVzcF9hdmFpbGFi bGUoKQo+ICsJICogY29uc3VtZXMgdGhhdCBjYXNlIHNvIHRoZSB3YWl0IGZvciBvdXIgb3duIGRh dGEgY2FuIGNvbnRpbnVlLgo+ICsJICovCj4gKwlpZiAoIShzdGF0dXNfcmVnICYgWEkzQ19SRF9G SUZPX05PVF9FTVBUWV9NQVNLKSAmJgo+ICsJICAgIHhpM2NfeGZlcl9yZXNwX2F2YWlsYWJsZSht YXN0ZXIpKQo+ICAJCXJldHVybiAwOwo+ICAKPiAgCXRpbWVvdXQgPSBqaWZmaWVzICsgbXNlY3Nf dG9famlmZmllcyhYSTNDX1hGRVJfVElNRU9VVF9NUyk7Cj4gIAo+ICAJLyogUmVhZCBkYXRhIGZy b20gcnggZmlmbyAqLwo+IC0Jd2hpbGUgKGNtZC0+cnhfbGVuID4gMCAmJiAheGkzY19pc19yZXNw X2F2YWlsYWJsZShtYXN0ZXIpKSB7Cj4gKwl3aGlsZSAoY21kLT5yeF9sZW4gPiAwICYmICF4aTNj X3hmZXJfcmVzcF9hdmFpbGFibGUobWFzdGVyKSkgewoKW1NldmVyaXR5OiBIaWdoXQpDb3VsZCB0 aGlzIGxvb3AgZWFnZXJseSBjb25zdW1lIGluLWZsaWdodCBJQkkgcGF5bG9hZHMgYW5kIGNvcnJ1 cHQgYm90aCB0aGUKSUJJIGFuZCB0aGUgdHJhbnNmZXIgZGF0YT8KCklmIGEgaGFyZHdhcmUgdGFy Z2V0IGFzc2VydHMgYW4gSUJJIHJpZ2h0IGF0IHRoZSBzdGFydCBvZiBhIHJlYWQgdHJhbnNmZXIs Cml0cyBwYXlsb2FkIG1pZ2h0IHN0cmVhbSBpbnRvIHRoZSBzaGFyZWQgUkRfRklGTy4gU2luY2Ug dGhlIElCSSdzIHJlc3BvbnNlCndvcmQgaXMgbm90IHBvc3RlZCB0byBSRVNQX1NUQVRVU19GSUZP IHVudGlsIHRoZSB0cmFuc2FjdGlvbiBmaW5pc2hlcywgaXQKYXBwZWFycyB4aTNjX3hmZXJfcmVz cF9hdmFpbGFibGUoKSBjb3VsZCByZXR1cm4gZmFsc2UgaGVyZS4KClRoZSBwb2xsaW5nIGxvb3Ag d291bGQgdGhlbiBleGVjdXRlIHhpM2NfbWFzdGVyX3JkX2Zyb21fcnhfZmlmbygpLCBibGluZGx5 CmRyYWluaW5nIHRoZSB1bnRhZ2dlZCBJQkkgYnl0ZXMgZnJvbSBSRF9GSUZPIGludG8gdGhlIHRy YW5zZmVyJ3MgYnVmZmVyCmJlZm9yZSB2YWxpZGF0aW5nIG93bmVyc2hpcC4gTGF0ZXIsIHdoZW4g dGhlIElCSSBwcm9jZXNzaW5nIHBhdGgKKHhpM2NfbWFzdGVyX3Byb2Nlc3NfaWJpKSBydW5zLCBp dCBleHBlY3RzIGl0cyBwYXlsb2FkIHRvIHN0aWxsIGJlIGluIHRoZQpSWCBGSUZPIGFuZCBtYXkg dW5kZXJmbG93IHRoZSBGSUZPIG9yIHN0ZWFsIHRoZSB0cmFuc2ZlcidzIGFjdHVhbCBkYXRhLgoK PiAgCQlpZiAodGltZV9hZnRlcihqaWZmaWVzLCB0aW1lb3V0KSkgewo+ICAJCQlkZXZfZXJyKG1h c3Rlci0+ZGV2LCAiWEkzQyByZWFkIHRpbWVvdXRcbiIpOwo+ICAJCQlyZXR1cm4gLUVJTzsKPiAg CQl9Cj4gIAkJeGkzY19tYXN0ZXJfcmRfZnJvbV9yeF9maWZvKG1hc3RlciwgY21kKTsKPiAgCQl1 c2xlZXBfcmFuZ2UoWEkzQ19QT0xMX0lOVEVSVkFMX1VTLCAyICogWEkzQ19QT0xMX0lOVEVSVkFM X1VTKTsKPiAgCX0KClsgLi4uIF0KCj4gQEAgLTEwNTIsOSArMTI0MywzMzggQEAgc3RhdGljIHZv aWQgeGkzY19tYXN0ZXJfYnVzX2NsZWFudXAoc3RydWN0IGkzY19tYXN0ZXJfY29udHJvbGxlciAq bSkKPiArc3RhdGljIHZvaWQgeGkzY19tYXN0ZXJfZnJlZV9pYmkoc3RydWN0IGkzY19kZXZfZGVz YyAqZGV2KQo+ICt7Cj4gKwlzdHJ1Y3QgeGkzY19pM2NfZGV2X2RhdGEgKmRhdGEgPSBpM2NfZGV2 X2dldF9tYXN0ZXJfZGF0YShkZXYpOwo+ICsJc3RydWN0IGkzY19tYXN0ZXJfY29udHJvbGxlciAq bSA9IGkzY19kZXZfZ2V0X21hc3RlcihkZXYpOwo+ICsJc3RydWN0IHhpM2NfbWFzdGVyICptYXN0 ZXIgPSB0b194aTNjX21hc3RlcihtKTsKPiArCXVuc2lnbmVkIGxvbmcgZmxhZ3M7Cj4gKwo+ICsJ c3Bpbl9sb2NrX2lycXNhdmUoJm1hc3Rlci0+aWJpLmxvY2ssIGZsYWdzKTsKPiArCW1hc3Rlci0+ aWJpLnNsb3RzW2RhdGEtPmliaV9zbG90XSA9IE5VTEw7Cj4gKwlzcGluX3VubG9ja19pcnFyZXN0 b3JlKCZtYXN0ZXItPmliaS5sb2NrLCBmbGFncyk7Cj4gKwo+ICsJLyoKPiArCSAqIENsZWFyaW5n IHRoZSBzbG90IGFib3ZlIGtlZXBzIHRoZSBJQkkgaGFuZGxlciBmcm9tIGZpbmRpbmcgdGhpcwo+ ICsJICogZGV2aWNlLCBidXQgYSBoYW5kbGVyIGFscmVhZHkgcnVubmluZyBtYXkgYmUgY29weWlu ZyBhIHBheWxvYWQgaW50bwo+ICsJICogdGhlIHBvb2wuIFdhaXQgZm9yIGl0IHRvIGZpbmlzaCBi ZWZvcmUgdGhlIHBvb2wgaXMgZnJlZWQgYmVsb3cuCj4gKwkgKi8KPiArCXN5bmNocm9uaXplX2ly cShtYXN0ZXItPmlycSk7Cj4gKwo+ICsJaTNjX2dlbmVyaWNfaWJpX2ZyZWVfcG9vbChkYXRhLT5p YmlfcG9vbCk7Cj4gKwlpM2NfZGV2X3NldF9tYXN0ZXJfZGF0YShkZXYsIE5VTEwpOwo+ICsJa2Zy ZWUoZGF0YSk7CgpbU2V2ZXJpdHk6IEhpZ2hdCkRvZXMgZnJlZWluZyB0aGUgSUJJIHBvb2wgaGVy ZSBiZWZvcmUgdGhlIHdvcmtxdWV1ZSBpcyBmbHVzaGVkIGNyZWF0ZSBhCnVzZS1hZnRlci1mcmVl IGFuZCBOVUxMIHBvaW50ZXIgZGVyZWZlcmVuY2Ugcmlzaz8KCkR1cmluZyBkZXZpY2UgdGVhcmRv d24sIGl0IGxvb2tzIGxpa2UgYW4gYXN5bmNocm9ub3VzIElCSSBjb3VsZCByYWNlCndpdGggZGV2 aWNlIHJlbW92YWwuIElmIHRoZSBjb3JlIGNhbGxzIHhpM2NfbWFzdGVyX2Rpc2FibGVfaWJpKCkg YW5kIHRoZW4KcHJvY2VlZHMgdG8gY2FsbCB4aTNjX21hc3Rlcl9mcmVlX2liaSgpLCBhbiBJQkkg aW50ZXJydXB0IG1pZ2h0IGNvbmN1cnJlbnRseQpmaXJlLgoKVGhlIElSUSBoYW5kbGVyIGNhbGxp bmcgeGkzY19tYXN0ZXJfcHJvY2Vzc19pYmkoKSBjb3VsZCB1bmNvbmRpdGlvbmFsbHkgcXVldWUK YSB3b3JrIGl0ZW0gdG8gZGV2LT5pYmktPndxLiBCeSB0aGUgdGltZSB0aGUgY29yZSBjYWxscyBk ZXN0cm95X3dvcmtxdWV1ZSgpLAp3aGljaCBmbHVzaGVzIHRoZSBxdWV1ZSwgdGhlIHdvcmsgaXRl bSB3b3VsZCByZXNpZGUgaW4gZnJlZWQgbWVtb3J5LgoKRnVydGhlcm1vcmUsIHdoZW4gdGhlIGZs dXNoZWQgd29yayBleGVjdXRlcywgaXQgY2FsbHMKeGkzY19tYXN0ZXJfcmVjeWNsZV9pYmlfc2xv dCgpIHdoaWNoIHdvdWxkIGRlcmVmZXJlbmNlIHRoZSBub3ctTlVMTCBtYXN0ZXIKZGF0YToKCnhp M2NfbWFzdGVyX3JlY3ljbGVfaWJpX3Nsb3QoKSB7CiAgICBzdHJ1Y3QgeGkzY19pM2NfZGV2X2Rh dGEgKmRhdGEgPSBpM2NfZGV2X2dldF9tYXN0ZXJfZGF0YShkZXYpOwogICAgaTNjX2dlbmVyaWNf aWJpX3JlY3ljbGVfc2xvdChkYXRhLT5pYmlfcG9vbCwgc2xvdCk7Cn0KCj4gK30KClsgLi4uIF0K Ci0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQv MjAyNjA5MDgwOTQyNTcuMzE5NjEyMC0xLXNodWJoYW1zYW5qYXkucGF0aWxAYW1kLmNvbT9wYXJ0 PTIKCi0tIApsaW51eC1pM2MgbWFpbGluZyBsaXN0CmxpbnV4LWkzY0BsaXN0cy5pbmZyYWRlYWQu b3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtaTNj Cg== 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 DA03D49552B for ; Tue, 8 Sep 2026 10:00:15 +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=1788861617; cv=none; b=dKvrhR11890h17StncN+a1pSsTaYBBzbsjcYr+fwE8FwUa3VwQYJia3W7MZLmJbfY+oOwv6ZqCteSKajmuQSuI1b1OU4n0aOs3jrO5dPsrGz6bpEsql1h7OMluMCPTEgOrEZY0VTqE0N7NNiS//0l8/nPzsN9S85owxMBm5GooU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788861617; c=relaxed/simple; bh=GYKpmvQ2QIDlFJATeHFAWM+9PPQ+EYFrNQ6amZ+WTEc=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=Rq3MCzV7YGf6MtBLmwuSfq14mVI+s1TfxtXmIZ8P0BN4MUcieWuyeeyCaCB6wSFQGj9UtlDlWtpl1WgRjkNvc1kqrxiRsTavMIu/6s2YjeYjR+j4DiDoCvQF6GMlTFIIO2qKihNKgvxFbPIK6M/+X2YjWK/r91MhJ6IHae/IjHM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QFJx8F6s; 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="QFJx8F6s" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 109811F00A3A; Tue, 8 Sep 2026 10:00:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788861615; bh=nou0oXP9hRCLsU1cEsbfDPsg4+dtEPcqi5lmpwYxVeE=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=QFJx8F6s5l2tVNbdHuom48d6KaLGeJ1nTW5wa19KbAn9GEK3G9jucM7sdHTi6ETWm 4hG71pAjeoxCUqPRGTuV0i9Vztff7P1kmWx4DQWtASBDqLVt/G1jNORJSLi5wZ1hSO cUAsy9pS93f3Ey7jo9tEC+pMDMceUJONa9Puuwu+n6ZhpLnrnFE0tK1ASfq90FdYey hn0pafezuQp/d3UhoRatESfmnCTskNHXWMARa7/Pp2yM1xnw2D+1mBuVPWEHaLkc10 LaU1XoLw77QfVLICCIld2xpRlUWVzPpkCWiclhgKhVjbHyhwVyzkTfyVJINWWB8W/p vhW55etrwpPFA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 2/3] i3c: master: amd: Add support for in-band interrupts Reply-To: sashiko-reviews@lists.linux.dev To: "Shubham Patil" Cc: linux-i3c@lists.infradead.org, conor+dt@kernel.org, devicetree@vger.kernel.org, Frank.Li@kernel.org, robh@kernel.org, "Alexandre Belloni" In-Reply-To: <20260908094257.3196120-3-shubhamsanjay.patil@amd.com> References: <20260908094257.3196120-1-shubhamsanjay.patil@amd.com> <20260908094257.3196120-3-shubhamsanjay.patil@amd.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 08 Sep 2026 10:00:14 +0000 Message-Id: <20260908100015.109811F00A3A@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 2 potential issue(= s) to consider: - [High] Eagerly draining the shared RX FIFO during a polled read transfer = consumes in-flight IBI payloads, corrupting both the IBI and the transfer d= ata. - [High] Freeing the IBI pool before the workqueue is flushed causes a UAF = and NULL pointer dereference if a stray IBI is queued after disable. -- commit 4e71fd809febc81aa5e7bc809c1ce4fa618ec5a7 Author: Shubham Patil i3c: master: amd: Add support for in-band interrupts Add support for receiving and dequeueing I3C in-band interrupts. IBI support is optional at synthesis time, so the ops are assembled at probe time. The controller interrupt carries IBI events only. > diff --git a/drivers/i3c/master/amd-i3c-master.c b/drivers/i3c/master/amd= -i3c-master.c > index ef5ad5abb788c..8a8ab3cd2fa40 100644 > --- a/drivers/i3c/master/amd-i3c-master.c > +++ b/drivers/i3c/master/amd-i3c-master.c [ ... ] > @@ -606,14 +678,21 @@ static int xi3c_master_read(struct xi3c_master *mas= ter, struct xi3c_cmd *cmd) > return ret; > } > =20 > - if (!(status_reg & XI3C_RD_FIFO_NOT_EMPTY_MASK)) > + /* > + * No data queued means this read produced none, unless what is queued > + * is an IBI response that raced with it; xi3c_xfer_resp_available() > + * consumes that case so the wait for our own data can continue. > + */ > + if (!(status_reg & XI3C_RD_FIFO_NOT_EMPTY_MASK) && > + xi3c_xfer_resp_available(master)) > return 0; > =20 > timeout =3D jiffies + msecs_to_jiffies(XI3C_XFER_TIMEOUT_MS); > =20 > /* Read data from rx fifo */ > - while (cmd->rx_len > 0 && !xi3c_is_resp_available(master)) { > + while (cmd->rx_len > 0 && !xi3c_xfer_resp_available(master)) { [Severity: High] Could this loop eagerly consume in-flight IBI payloads and corrupt both the IBI and the transfer data? If a hardware target asserts an IBI right at the start of a read transfer, its payload might stream into the shared RD_FIFO. Since the IBI's response word is not posted to RESP_STATUS_FIFO until the transaction finishes, it appears xi3c_xfer_resp_available() could return false here. The polling loop would then execute xi3c_master_rd_from_rx_fifo(), blindly draining the untagged IBI bytes from RD_FIFO into the transfer's buffer before validating ownership. Later, when the IBI processing path (xi3c_master_process_ibi) runs, it expects its payload to still be in the RX FIFO and may underflow the FIFO or steal the transfer's actual data. > if (time_after(jiffies, timeout)) { > dev_err(master->dev, "XI3C read timeout\n"); > return -EIO; > } > xi3c_master_rd_from_rx_fifo(master, cmd); > usleep_range(XI3C_POLL_INTERVAL_US, 2 * XI3C_POLL_INTERVAL_US); > } [ ... ] > @@ -1052,9 +1243,338 @@ static void xi3c_master_bus_cleanup(struct i3c_ma= ster_controller *m) > +static void xi3c_master_free_ibi(struct i3c_dev_desc *dev) > +{ > + struct xi3c_i3c_dev_data *data =3D i3c_dev_get_master_data(dev); > + struct i3c_master_controller *m =3D i3c_dev_get_master(dev); > + struct xi3c_master *master =3D to_xi3c_master(m); > + unsigned long flags; > + > + spin_lock_irqsave(&master->ibi.lock, flags); > + master->ibi.slots[data->ibi_slot] =3D NULL; > + spin_unlock_irqrestore(&master->ibi.lock, flags); > + > + /* > + * Clearing the slot above keeps the IBI handler from finding this > + * device, but a handler already running may be copying a payload into > + * the pool. Wait for it to finish before the pool is freed below. > + */ > + synchronize_irq(master->irq); > + > + i3c_generic_ibi_free_pool(data->ibi_pool); > + i3c_dev_set_master_data(dev, NULL); > + kfree(data); [Severity: High] Does freeing the IBI pool here before the workqueue is flushed create a use-after-free and NULL pointer dereference risk? During device teardown, it looks like an asynchronous IBI could race with device removal. If the core calls xi3c_master_disable_ibi() and then proceeds to call xi3c_master_free_ibi(), an IBI interrupt might concurrently fire. The IRQ handler calling xi3c_master_process_ibi() could unconditionally que= ue a work item to dev->ibi->wq. By the time the core calls destroy_workqueue(), which flushes the queue, the work item would reside in freed memory. Furthermore, when the flushed work executes, it calls xi3c_master_recycle_ibi_slot() which would dereference the now-NULL master data: xi3c_master_recycle_ibi_slot() { struct xi3c_i3c_dev_data *data =3D i3c_dev_get_master_data(dev); i3c_generic_ibi_recycle_slot(data->ibi_pool, slot); } > +} [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260908094257.3196= 120-1-shubhamsanjay.patil@amd.com?part=3D2