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 4A7A2C5DF94 for ; Mon, 24 Aug 2026 05:04:26 +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=mGoF8jxlB+/29AuhVmFixOxC3ucqTduDqJ+VooPzDO0=; b=RENPeCQa4MAMFM wwpJfJzHShpAViJgQIEFdeqivNhGlsHKsRMgEZH1MrJFoRwHA5b+4nnecZzA9HYwONXXHZFclgRpS KLyCh7I0gzR/NGzjKpb6ppgUsbXDwrJCr6EkDdEUi81lnD7Qj6JTGamH8DqpQ7SfboP73ysdCf0rc 436o+ihSIfoD5HeH6IitlcXKDDiEBqjq7ge+snWO3YNxO9W21xt2vBOnrI8MEoQqqnNE6Nvcn5OQs sicNSx2sltJLg1ryZ4yc+EiYcCqsabfJAvAqy3skYfE3hK/qZpjvuYNuPrxPu3pxIThaEv652ucGU 9lkbu/iLNU3tdPMcurlg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wyMrB-0000000FvTa-3gAo; Mon, 24 Aug 2026 05:04:25 +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 1wyMrA-0000000FvTU-3ZKj for linux-i3c@lists.infradead.org; Mon, 24 Aug 2026 05:04:24 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id E9BEA43B97; Mon, 24 Aug 2026 05:04:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82D601F000E9; Mon, 24 Aug 2026 05:04:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787547863; bh=f7wx6EGCh/T5ArQC2s1jZ97pGYD4zTjw2k8KAhE6maI=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Ybl6PJIUfDWaiP+K+8SNk8EVxr/R/mwFBHtWDy2SLynj9dvNkPVaeoUmBUPgYEWQ5 JtoyZA+NgIierYNUQG0/5ZF44t17/V1u1SSDYFAPDN1BDigf1/Dk3YpzUSjiKtBiyb GfekU/WStIcAOa6CX0yySC95OiS+bteYlL0gNUqqIOWM0OGUdEa0OQPD/hbQOi6mdc W2lJ1HtKEBtDnz9VkNJxNYhDd+IsoCbPkle7Z1JslIxFF+LMOQy0a2juvV+6lRNZlw oouH5I1/ycLcwsPUEk9jpxC4glX/Nr1JuRNQWq0J0RlJXQ2F37YoIUYNIhD1S6mQNb duV+tCcXme3NQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v2 2/3] i3c: master: amd: Add support for in-band interrupts To: "Shubham Patil" Cc: robh@kernel.org, "Alexandre Belloni" , linux-i3c@lists.infradead.org, Frank.Li@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org In-Reply-To: <20260824044835.2924141-3-shubhamsanjay.patil@amd.com> References: <20260824044835.2924141-1-shubhamsanjay.patil@amd.com> <20260824044835.2924141-3-shubhamsanjay.patil@amd.com> Date: Mon, 24 Aug 2026 05:04:23 +0000 Message-Id: <20260824050423.82D601F000E9@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 MyBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIEluY29uc2lzdGVudCBy ZWdpc3RlciByZWFkIG9yZGVyIGNhdXNlcyB0aGUgcG9sbGVkIElCSSBoYW5kbGVyIHRvIHJlYWQg dGhlIHdyb25nIFRhcmdldCBBZGRyZXNzIChEQSkuCi0gW0hpZ2hdIFByZW1hdHVyZSBwdWJsaWNh dGlvbiBvZiB0aGUgSUJJIHNsb3QgY2F1c2VzIGEgTlVMTCBwb2ludGVyIGRlcmVmZXJlbmNlIGlu IHRoZSBJUlEgaGFuZGxlci4KLSBbSGlnaF0gRWFnZXIgcG9sbGluZyBvZiB0aGUgc2hhcmVkIFJY IEZJRk8gY29ycnVwdHMgcmVhZCB0cmFuc2ZlcnMgYW5kIGRyb3BzIElCSSBwYXlsb2Fkcy4KLS0K Ci0tLSBQYXRjaCBbMl06IFtQQVRDSCB2MiAyLzNdIGkzYzogbWFzdGVyOiBhbWQ6IEFkZCBzdXBw b3J0IGZvciBpbi1iYW5kIGludGVycnVwdHMgLS0tCmNvbW1pdCAwOWM1MzNjYjNjN2I2NzBhY2Ji ZDI1YTNiZGZkNzhlOTgzZWZiNjc2CkF1dGhvcjogU2h1YmhhbSBQYXRpbCA8c2h1YmhhbXNhbmph eS5wYXRpbEBhbWQuY29tPgoKaTNjOiBtYXN0ZXI6IGFtZDogQWRkIHN1cHBvcnQgZm9yIGluLWJh bmQgaW50ZXJydXB0cwoKVGhpcyBjb21taXQgYWRkcyBzdXBwb3J0IGZvciByZWNlaXZpbmcgYW5k IGRlcXVldWVpbmcgSTNDIGluLWJhbmQgaW50ZXJydXB0cy4KVGhlIElCSSBvcGVyYXRpb25zIGFy ZSBhc3NlbWJsZWQgYXQgcHJvYmUgdGltZSBpZiB0aGUgY2FwYWJpbGl0eSBpcyBwcmVzZW50IGlu CnRoZSBkZXZpY2UgdHJlZS4gSXQgYWxzbyBpbnRyb2R1Y2VzIGxvZ2ljIHRvIGhhbmRsZSBJQklz IHRoYXQgcmFjZSB3aXRoIG5vcm1hbAp0cmFuc2ZlcnMgYnkgZGVtdWx0aXBsZXhpbmcgdGhlIHJl c3BvbnNlIEZJRk8gYnkgVElELgoKPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9pM2MvbWFzdGVyL2Ft ZC1pM2MtbWFzdGVyLmMgYi9kcml2ZXJzL2kzYy9tYXN0ZXIvYW1kLWkzYy1tYXN0ZXIuYwo+IGlu ZGV4IGVmNWFkNWFiYjc4OGMuLjkyYTlmNDNmODkzNDQgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9p M2MvbWFzdGVyL2FtZC1pM2MtbWFzdGVyLmMKPiArKysgYi9kcml2ZXJzL2kzYy9tYXN0ZXIvYW1k LWkzYy1tYXN0ZXIuYwpbIC4uLiBdCj4gQEAgLTIwNiwyMyArMjczLDg4IEBAIHN0YXRpYyBpbmxp bmUgYm9vbCB4aTNjX2lzX3Jlc3BfYXZhaWxhYmxlKHN0cnVjdCB4aTNjX21hc3RlciAqbWFzdGVy KQpbIC4uLiBdCj4gK3N0YXRpYyBib29sIHhpM2NfeGZlcl9yZXNwX2F2YWlsYWJsZShzdHJ1Y3Qg eGkzY19tYXN0ZXIgKm1hc3RlcikKPiArewo+ICsJdTMyIHJlc3A7Cj4gKwl1OCBkYTsKPiArCj4g KwlpZiAobWFzdGVyLT54ZmVyX3Jlc3BfdmFsaWQpCj4gKwkJcmV0dXJuIHRydWU7Cj4gKwo+ICsJ d2hpbGUgKHhpM2NfaXNfcmVzcF9hdmFpbGFibGUobWFzdGVyKSkgewo+ICsJCXJlc3AgPSBpb3Jl YWQzMihtYXN0ZXItPm1lbWJhc2UgKyBYSTNDX1JFU1BfU1RBVFVTX0ZJRk9fT0ZGU0VUKTsKPiAr Cj4gKwkJaWYgKEZJRUxEX0dFVChYSTNDX1JFU1BfVElEX01BU0ssIHJlc3ApICE9IFhJM0NfSUJJ X1JFU1BfVElEKSB7Cj4gKwkJCW1hc3Rlci0+eGZlcl9yZXNwID0gcmVzcDsKPiArCQkJbWFzdGVy LT54ZmVyX3Jlc3BfdmFsaWQgPSB0cnVlOwo+ICsJCQlyZXR1cm4gdHJ1ZTsKPiArCQl9Cj4gKwo+ ICsJCWRhID0gRklFTERfR0VUKFhJM0NfQUREUl9NQVNLLAo+ICsJCQkgICAgICAgaW9yZWFkMzIo bWFzdGVyLT5tZW1iYXNlICsgWEkzQ19JQklfVEFSR0VUX0FERFJfT0ZGU0VUKSk7CgpbU2V2ZXJp dHk6IEhpZ2hdCkRvZXMgcG9wcGluZyB0aGUgcmVzcG9uc2UgRklGTyBiZWZvcmUgcmVhZGluZyB0 aGUgVGFyZ2V0IEFkZHJlc3MgcmVnaXN0ZXIKY2F1c2UgdGhlIHdyb25nIGFkZHJlc3MgdG8gYmUg cmVhZD8KCkluIHRoZSBoYXJkd2FyZSBJUlEgaGFuZGxlciwgdGhlIFRhcmdldCBBZGRyZXNzIGlz IHJlYWQgYmVmb3JlIHdhaXRpbmcgZm9yCmFuZCBwb3BwaW5nIHRoZSByZXNwb25zZSBGSUZPOgoK eGkzY19tYXN0ZXJfaGFuZGxlX2liaSgpIHsKICAgIGliaV9yZWcgPSBpb3JlYWQzMihtYXN0ZXIt Pm1lbWJhc2UgKyBYSTNDX0lCSV9UQVJHRVRfQUREUl9PRkZTRVQpOwogICAgZGEgPSBGSUVMRF9H RVQoWEkzQ19BRERSX01BU0ssIGliaV9yZWcpOwogICAgaWYgKHhpM2Nfd2FpdF9yZXNwX2F0b21p YyhtYXN0ZXIpKSB7IC4uLiB9CiAgICByZXNwID0gaW9yZWFkMzIobWFzdGVyLT5tZW1iYXNlICsg WEkzQ19SRVNQX1NUQVRVU19GSUZPX09GRlNFVCk7Cn0KCklmIHRoZSByZXNwb25zZSBpcyBwb3Bw ZWQgZmlyc3QgaGVyZSwgZG9lcyBpdCBhZHZhbmNlIHRoZSBGSUZPIGhlYWQgYW5kIGNhdXNlCnRo aXMgcmVhZCB0byByZXR1cm4gdGhlIGFkZHJlc3Mgb2YgdGhlIG5leHQgcXVldWVkIElCSSAob3Ig Z2FyYmFnZSkgaW5zdGVhZCBvZgp0aGUgY3VycmVudCBvbmU/Cgo+ICsJCWRldl9kYmdfcmF0ZWxp bWl0ZWQobWFzdGVyLT5kZXYsCj4gKwkJCQkgICAgIklCSSBmcm9tIDB4JTAyeCByYWNlZCB3aXRo IHRyYW5zZmVyXG4iLCBkYSk7Cj4gKwkJeGkzY19tYXN0ZXJfcHJvY2Vzc19pYmkobWFzdGVyLCBy ZXNwLCBkYSk7ClsgLi4uIF0KPiBAQCAtNDM3LDEzICs2MDUsMTkgQEAgc3RhdGljIGludCB4aTNj X21hc3Rlcl9yZWFkKHN0cnVjdCB4aTNjX21hc3RlciAqbWFzdGVyLCBzdHJ1Y3QgeGkzY19jbWQg KmNtZCkKWyAuLi4gXQo+ICAJLyogUmVhZCBkYXRhIGZyb20gcnggZmlmbyAqLwo+IC0Jd2hpbGUg KGNtZC0+cnhfbGVuID4gMCAmJiAheGkzY19pc19yZXNwX2F2YWlsYWJsZShtYXN0ZXIpKSB7Cj4g Kwl3aGlsZSAoY21kLT5yeF9sZW4gPiAwICYmICF4aTNjX3hmZXJfcmVzcF9hdmFpbGFibGUobWFz dGVyKSkgewo+ICAJCWlmICh0aW1lX2FmdGVyKGppZmZpZXMsIHRpbWVvdXQpKSB7Cj4gIAkJCWRl dl9lcnIobWFzdGVyLT5kZXYsICJYSTNDIHJlYWQgdGltZW91dFxuIik7Cj4gIAkJCXJldHVybiAt RUlPOwo+ICAJCX0KPiAgCQl4aTNjX21hc3Rlcl9yZF9mcm9tX3J4X2ZpZm8obWFzdGVyLCBjbWQp Owo+ICAJCXVzbGVlcF9yYW5nZShYSTNDX1BPTExfSU5URVJWQUxfVVMsIDIgKiBYSTNDX1BPTExf SU5URVJWQUxfVVMpOwo+ICAJfQoKW1NldmVyaXR5OiBIaWdoXQpEb2VzIHRoaXMgZWFnZXIgcG9s bGluZyBvZiB0aGUgc2hhcmVkIFJYIEZJRk8gcmlzayBjb25zdW1pbmcgYW4gSUJJIHBheWxvYWQK aW50byB0aGUgdHJhbnNmZXIgYnVmZmVyIGJlZm9yZSB0aGUgSUJJIHJlc3BvbnNlIGlzIHByb2Nl c3NlZD8KCklmIGFuIElCSSBleGVjdXRlcyByaWdodCBiZWZvcmUgYSByZWFkIHRyYW5zZmVyLCBp dHMgcGF5bG9hZCB3aWxsIGVudGVyIHRoZSBSWApGSUZPLiBTaW5jZSAheGkzY194ZmVyX3Jlc3Bf YXZhaWxhYmxlKCkgY2FuIGV2YWx1YXRlIHRvIHRydWUgaWYgdGhlIHJlc3BvbnNlCndvcmQgaGFz bid0IGJlZW4gcHVzaGVkIHRvIHRoZSBSZXNwb25zZSBGSUZPIHlldCwgdGhlIGxvb3AgbWlnaHQg Y2FsbAp4aTNjX21hc3Rlcl9yZF9mcm9tX3J4X2ZpZm8oKS4KCkNvdWxkIHRoaXMgYmxpbmRseSBj b3B5IHRoZSBJQkkgcGF5bG9hZCBpbnRvIHRoZSByZWFkIHRyYW5zZmVyJ3MgYnVmZmVyLCBsZWF2 aW5nCmFuIGVtcHR5IFJYIEZJRk8gZm9yIHhpM2NfbWFzdGVyX3Byb2Nlc3NfaWJpKCkgYW5kIGRy b3BwaW5nIHRoZSBJQkkgZGF0YT8KClsgLi4uIF0KPiBAQCAtMTA1Miw5ICsxMjQyLDMzNyBAQCBz dGF0aWMgdm9pZCB4aTNjX21hc3Rlcl9idXNfY2xlYW51cChzdHJ1Y3QgaTNjX21hc3Rlcl9jb250 cm9sbGVyICptKQpbIC4uLiBdCj4gK3N0YXRpYyBpbnQgeGkzY19tYXN0ZXJfcmVxdWVzdF9pYmko c3RydWN0IGkzY19kZXZfZGVzYyAqZGV2LAo+ICsJCQkJICAgY29uc3Qgc3RydWN0IGkzY19pYmlf c2V0dXAgKnJlcSkKPiArewpbIC4uLiBdCj4gKwlzcGluX2xvY2tfaXJxc2F2ZSgmbWFzdGVyLT5p YmkubG9jaywgZmxhZ3MpOwo+ICsJZm9yIChpID0gMDsgaSA8IEFSUkFZX1NJWkUobWFzdGVyLT5p Ymkuc2xvdHMpOyBpKyspIHsKPiArCQlpZiAoIW1hc3Rlci0+aWJpLnNsb3RzW2ldKSB7Cj4gKwkJ CWRhdGEtPmliaV9zbG90ID0gaTsKPiArCQkJbWFzdGVyLT5pYmkuc2xvdHNbaV0gPSBkZXY7Cj4g KwkJCWJyZWFrOwo+ICsJCX0KPiArCX0KPiArCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJm1hc3Rl ci0+aWJpLmxvY2ssIGZsYWdzKTsKPiArCj4gKwlpZiAoZGF0YS0+aWJpX3Nsb3QgPCAwKSB7Cj4g KwkJZGV2X2VycihtYXN0ZXItPmRldiwgIklCSTogbm8gZnJlZSBzbG90IGZvciBhZGRyIDB4JTAy eFxuIiwKPiArCQkJZGV2LT5pbmZvLmR5bl9hZGRyKTsKPiArCQlpM2NfZ2VuZXJpY19pYmlfZnJl ZV9wb29sKGRhdGEtPmliaV9wb29sKTsKPiArCQlrZnJlZShkYXRhKTsKPiArCQlyZXR1cm4gLUVO T1NQQzsKPiArCX0KPiArCj4gKwlpM2NfZGV2X3NldF9tYXN0ZXJfZGF0YShkZXYsIGRhdGEpOwo+ ICsKPiArCXJldHVybiAwOwo+ICt9CgpbU2V2ZXJpdHk6IEhpZ2hdCkNhbiBhbiBpbmNvbWluZyBJ QkkgdHJpZ2dlciBhIE5VTEwgcG9pbnRlciBkZXJlZmVyZW5jZSBpZiBpdCBhcnJpdmVzIHJpZ2h0 CmFmdGVyIHRoZSBzbG90IGlzIHB1Ymxpc2hlZCBidXQgYmVmb3JlIHRoZSBtYXN0ZXIgZGF0YSBp cyBzZXQ/CgpJZiB0aGUgY29udHJvbGxlcidzIElCSSBBQ0sgaXMgYWxyZWFkeSBhcm1lZCBieSBh bm90aGVyIGRldmljZSwgYW5kIHRoZSBoYXJkd2FyZQpzZW5kcyBhbiBJQkkgYWZ0ZXIgbWFzdGVy LT5pYmkuc2xvdHNbaV0gPSBkZXYgYnV0IGJlZm9yZQppM2NfZGV2X3NldF9tYXN0ZXJfZGF0YShk ZXYsIGRhdGEpLCB0aGUgSVJRIGhhbmRsZXIgKHhpM2NfbWFzdGVyX3Byb2Nlc3NfaWJpKQpjb3Vs ZCBsb29rIHVwIHRoZSBkZXZpY2UgYW5kIGNhbGwgaTNjX2Rldl9nZXRfbWFzdGVyX2RhdGEoZGV2 KS4KCldvdWxkIHRoaXMgcmV0dXJuIE5VTEwgYW5kIHJlc3VsdCBpbiBhIGNyYXNoIHdoZW4gYWNj ZXNzaW5nIGRhdGEtPmliaV9wb29sPwpTaG91bGQgaTNjX2Rldl9zZXRfbWFzdGVyX2RhdGEoZGV2 LCBkYXRhKSBiZSBjYWxsZWQgYmVmb3JlIHRoZSBzbG90IGlzIG1hZGUKdmlzaWJsZSB0byB0aGUg SVJRIGhhbmRsZXI/CgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtvLmRl di8jL3BhdGNoc2V0LzIwMjYwODI0MDQ0ODM1LjI5MjQxNDEtMS1zaHViaGFtc2FuamF5LnBhdGls QGFtZC5jb20/cGFydD0yCgotLSAKbGludXgtaTNjIG1haWxpbmcgbGlzdApsaW51eC1pM2NAbGlz dHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2xpbnV4LWkzYwo= 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 4123333D6EE for ; Mon, 24 Aug 2026 05:04:23 +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=1787547865; cv=none; b=FPBG6VuYq7WqZDnjY1eIgXD8uOj80m2H6by9PyAMZ0YuqUBe45AO6MluF+Z4r+FZjuuxFhUvg6n+Rg6nP7tKdr8ZAMYItrwCg0++Z1Baj/ekoMGi3cxIx4joVQk+DPs8tZLFvHcrJWHyQgCaoZUYM0624I3ar77F1vnUN46imlU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787547865; c=relaxed/simple; bh=ABFoY8Kd/xi3PTZ5Pp7goeMiUi8sxiLqeBaaE2isV1g=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=OKURLD3kIz0N88C7z5OBGtcV9gtfc0+Nvm27hG09suvbZIqozNhyuZBA3PclX+XzeOQzuuydAPeWgGJOXUZpn5ffM2djKXAtp5cTy8v3/psrjfrD5naozp6R5fdqHu/IfN+UOgxHKZulciqSOnxl5z0ftYFsm7obKDp1Ucm0QPQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ybl6PJIU; 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="Ybl6PJIU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82D601F000E9; Mon, 24 Aug 2026 05:04:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787547863; bh=f7wx6EGCh/T5ArQC2s1jZ97pGYD4zTjw2k8KAhE6maI=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Ybl6PJIUfDWaiP+K+8SNk8EVxr/R/mwFBHtWDy2SLynj9dvNkPVaeoUmBUPgYEWQ5 JtoyZA+NgIierYNUQG0/5ZF44t17/V1u1SSDYFAPDN1BDigf1/Dk3YpzUSjiKtBiyb GfekU/WStIcAOa6CX0yySC95OiS+bteYlL0gNUqqIOWM0OGUdEa0OQPD/hbQOi6mdc W2lJ1HtKEBtDnz9VkNJxNYhDd+IsoCbPkle7Z1JslIxFF+LMOQy0a2juvV+6lRNZlw oouH5I1/ycLcwsPUEk9jpxC4glX/Nr1JuRNQWq0J0RlJXQ2F37YoIUYNIhD1S6mQNb duV+tCcXme3NQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH v2 2/3] i3c: master: amd: Add support for in-band interrupts Reply-To: sashiko-reviews@lists.linux.dev To: "Shubham Patil" Cc: robh@kernel.org, "Alexandre Belloni" , linux-i3c@lists.infradead.org, Frank.Li@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org In-Reply-To: <20260824044835.2924141-3-shubhamsanjay.patil@amd.com> References: <20260824044835.2924141-1-shubhamsanjay.patil@amd.com> <20260824044835.2924141-3-shubhamsanjay.patil@amd.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Aug 2026 05:04:23 +0000 Message-Id: <20260824050423.82D601F000E9@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 3 potential issue(= s) to consider: - [High] Inconsistent register read order causes the polled IBI handler to = read the wrong Target Address (DA). - [High] Premature publication of the IBI slot causes a NULL pointer derefe= rence in the IRQ handler. - [High] Eager polling of the shared RX FIFO corrupts read transfers and dr= ops IBI payloads. -- --- Patch [2]: [PATCH v2 2/3] i3c: master: amd: Add support for in-band int= errupts --- commit 09c533cb3c7b670acbbd25a3bdfd78e983efb676 Author: Shubham Patil i3c: master: amd: Add support for in-band interrupts This commit adds support for receiving and dequeueing I3C in-band interrupt= s. The IBI operations are assembled at probe time if the capability is present= in the device tree. It also introduces logic to handle IBIs that race with nor= mal transfers by demultiplexing the response FIFO by TID. > diff --git a/drivers/i3c/master/amd-i3c-master.c b/drivers/i3c/master/amd= -i3c-master.c > index ef5ad5abb788c..92a9f43f89344 100644 > --- a/drivers/i3c/master/amd-i3c-master.c > +++ b/drivers/i3c/master/amd-i3c-master.c [ ... ] > @@ -206,23 +273,88 @@ static inline bool xi3c_is_resp_available(struct xi= 3c_master *master) [ ... ] > +static bool xi3c_xfer_resp_available(struct xi3c_master *master) > +{ > + u32 resp; > + u8 da; > + > + if (master->xfer_resp_valid) > + return true; > + > + while (xi3c_is_resp_available(master)) { > + resp =3D ioread32(master->membase + XI3C_RESP_STATUS_FIFO_OFFSET); > + > + if (FIELD_GET(XI3C_RESP_TID_MASK, resp) !=3D XI3C_IBI_RESP_TID) { > + master->xfer_resp =3D resp; > + master->xfer_resp_valid =3D true; > + return true; > + } > + > + da =3D FIELD_GET(XI3C_ADDR_MASK, > + ioread32(master->membase + XI3C_IBI_TARGET_ADDR_OFFSET)); [Severity: High] Does popping the response FIFO before reading the Target Address register cause the wrong address to be read? In the hardware IRQ handler, the Target Address is read before waiting for and popping the response FIFO: xi3c_master_handle_ibi() { ibi_reg =3D ioread32(master->membase + XI3C_IBI_TARGET_ADDR_OFFSET); da =3D FIELD_GET(XI3C_ADDR_MASK, ibi_reg); if (xi3c_wait_resp_atomic(master)) { ... } resp =3D ioread32(master->membase + XI3C_RESP_STATUS_FIFO_OFFSET); } If the response is popped first here, does it advance the FIFO head and cau= se this read to return the address of the next queued IBI (or garbage) instead= of the current one? > + dev_dbg_ratelimited(master->dev, > + "IBI from 0x%02x raced with transfer\n", da); > + xi3c_master_process_ibi(master, resp, da); [ ... ] > @@ -437,13 +605,19 @@ static int xi3c_master_read(struct xi3c_master *mas= ter, struct xi3c_cmd *cmd) [ ... ] > /* 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)) { > 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); > } [Severity: High] Does this eager polling of the shared RX FIFO risk consuming an IBI payload into the transfer buffer before the IBI response is processed? If an IBI executes right before a read transfer, its payload will enter the= RX FIFO. Since !xi3c_xfer_resp_available() can evaluate to true if the response word hasn't been pushed to the Response FIFO yet, the loop might call xi3c_master_rd_from_rx_fifo(). Could this blindly copy the IBI payload into the read transfer's buffer, le= aving an empty RX FIFO for xi3c_master_process_ibi() and dropping the IBI data? [ ... ] > @@ -1052,9 +1242,337 @@ static void xi3c_master_bus_cleanup(struct i3c_ma= ster_controller *m) [ ... ] > +static int xi3c_master_request_ibi(struct i3c_dev_desc *dev, > + const struct i3c_ibi_setup *req) > +{ [ ... ] > + spin_lock_irqsave(&master->ibi.lock, flags); > + for (i =3D 0; i < ARRAY_SIZE(master->ibi.slots); i++) { > + if (!master->ibi.slots[i]) { > + data->ibi_slot =3D i; > + master->ibi.slots[i] =3D dev; > + break; > + } > + } > + spin_unlock_irqrestore(&master->ibi.lock, flags); > + > + if (data->ibi_slot < 0) { > + dev_err(master->dev, "IBI: no free slot for addr 0x%02x\n", > + dev->info.dyn_addr); > + i3c_generic_ibi_free_pool(data->ibi_pool); > + kfree(data); > + return -ENOSPC; > + } > + > + i3c_dev_set_master_data(dev, data); > + > + return 0; > +} [Severity: High] Can an incoming IBI trigger a NULL pointer dereference if it arrives right after the slot is published but before the master data is set? If the controller's IBI ACK is already armed by another device, and the har= dware sends an IBI after master->ibi.slots[i] =3D dev but before i3c_dev_set_master_data(dev, data), the IRQ handler (xi3c_master_process_ib= i) could look up the device and call i3c_dev_get_master_data(dev). Would this return NULL and result in a crash when accessing data->ibi_pool? Should i3c_dev_set_master_data(dev, data) be called before the slot is made visible to the IRQ handler? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260824044835.2924= 141-1-shubhamsanjay.patil@amd.com?part=3D2