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 C3C5DC5DF97 for ; Wed, 26 Aug 2026 10:50:48 +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=RHQMcKFdwihUvXicc4I999VKrO96yelhdUUXEbgczcM=; b=lLcCL/XN1xzd7y SqSOfse8oPBkEfkC6FZzwWNVHWLEzX97QHSgLvw8DRxAOxUZXmg/XAtnKrfa8WUzFXCLjm9lQBqap ShhP1p8ucXfYflnXoRiy9Mi8rbaztvijLnRrwqxEHoqwkAZkel+AzrS8xnPhkQD1+9QNDjm0Fzj48 +guc+FJub8NXXKgWtCe/GEfURGt4EhXXLZQF8I/fNnOnpUqqIAfvpMl26fhvtJbXf1WkpS6WaILh3 J8WuGpr/blO3TA0dmW5wgiyWnx1ww0MusYqy8oXDe8W5CMaAEwy1HQAB/zJfGKLTwmAMrOO5fZuM8 nYvntt93f+pu98AvOD8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wzBDU-00000002Jsg-1Sg3; Wed, 26 Aug 2026 10:50:48 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wzBDT-00000002JsV-1jpL for linux-i3c@lists.infradead.org; Wed, 26 Aug 2026 10:50:47 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 64BCC601E9; Wed, 26 Aug 2026 10:50:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3DA21F000E9; Wed, 26 Aug 2026 10:50:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787741446; bh=YtDaSLVh0eAnWe9c7pCY+O1a4NZv1iXPrGsIhLqFcAU=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=RNAScqSzwiCffQ8dSN8nhNAxS4OcaeWh+jfYO82JrhBV1Ew/ofdriceaxl9vgcRFv xzyRnBhkvlrUpDep8+rRrj7K0rn3uvabLBZML8NjMLSi0k4fyMOae/o5m4sIwYacT0 DzP20Kj1kuVu+GxAvLyFB6dRixUEc+kMrlH9OW6w0yDqO9yaPVi/fL++414GfoR7G0 6qXVNEu/MPTYXmF4gsHPwxgU3siNyO0T0/Ax7A2Gp/obpURTdmxMw+u+BB6qToZVYx YGmogEAvgjTFQiwVaO0bCYutmF45uL52mm/kQ4DbWf2omm+Q5Ph94z2QTFMZhTA+9k 3rxA405UkUV1g== From: sashiko-bot@kernel.org Subject: Re: [PATCH v16 2/8] i3c: master: Add controller-only device operation helpers To: "Lakshay Piplani" Cc: linux-i3c@lists.infradead.org, Frank.Li@kernel.org, "Alexandre Belloni" , conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org In-Reply-To: <20260826103819.1614843-3-lakshay.piplani@nxp.com> References: <20260826103819.1614843-1-lakshay.piplani@nxp.com> <20260826103819.1614843-3-lakshay.piplani@nxp.com> Date: Wed, 26 Aug 2026 10:50:45 +0000 Message-Id: <20260826105045.B3DA21F000E9@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 MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtNZWRpdW1d IFVubmVjZXNzYXJ5IGhlYXZ5IHdvcmtxdWV1ZSBhbGxvY2F0aW9uIGFuZCB0ZWFyZG93biB3aGVu IGEgY29udHJvbGxlciBkb2VzIG5vdCBzdXBwb3J0IElCSXMuCgpQcmUtZXhpc3RpbmcgaXNzdWVz OgotIFtDcml0aWNhbF0gUG90ZW50aWFsIHVzZS1hZnRlci1mcmVlIG9mIGdlbmVyaWMgSUJJIHBv b2wgc2xvdHMgYW5kIGBkZXYtPmliaWAgd2hlbiBkaXNhYmxpbmcgYW4gYWN0aXZlIElCSSBmYWls cyBkdXJpbmcgdGVhcmRvd24uCi0tCgpjb21taXQgZjM4YzExYjVkOTRhMzVmNWI5OWY2YTFmMjNi YmI0NDlmMTIyZGVkNApBdXRob3I6IExha3NoYXkgUGlwbGFuaSA8bGFrc2hheS5waXBsYW5pQG54 cC5jb20+CgppM2M6IG1hc3RlcjogQWRkIGNvbnRyb2xsZXItb25seSBkZXZpY2Ugb3BlcmF0aW9u IGhlbHBlcnMKClRoZSBnZW5lcmljIEkzQyBkZXZpY2UgYXR0YWNoIGFuZCBJQkkgcGF0aHMgcGVy Zm9ybSBib3RoIGNvcmUtbGV2ZWwKYm9va2tlZXBpbmcgYW5kIGNvbnRyb2xsZXItc3BlY2lmaWMg b3BlcmF0aW9ucy4gQWRkIGNvbnRyb2xsZXItb25seSBoZWxwZXJzCnRoYXQgaW52b2tlIHRoZSBj b250cm9sbGVyIGNhbGxiYWNrcyB3aXRob3V0IHVwZGF0aW5nIHRoZSBidXMgZGV2aWNlIGxpc3Qs CmFkZHJlc3Mtc2xvdCBzdGF0ZSwgb3IgZ2VuZXJpYyBJQkkgbGlmZWN5Y2xlLiBBbHNvIHJlbGVh c2UgdGhlIGdlbmVyaWMgSUJJCndvcmtxdWV1ZSBhbmQgc3RhdGUgd2hlbiB0aGUgY29udHJvbGxl ciByZXF1ZXN0IGNhbGxiYWNrIGZhaWxzLgoKPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9pM2MvbWFz dGVyLmMgYi9kcml2ZXJzL2kzYy9tYXN0ZXIuYwo+IGluZGV4IDAzZmI0MWYwNzg2YzUuLjg4Mzc5 YjY4MDlhNjQgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9pM2MvbWFzdGVyLmMKPiArKysgYi9kcml2 ZXJzL2kzYy9tYXN0ZXIuYwpbIC4uLiBdCj4gQEAgLTM2MDAsMTMgKzM3NTIsOSBAQCBFWFBPUlRf U1lNQk9MX0dQTChpM2NfZGV2X2VuYWJsZV9pYmlfbG9ja2VkKTsKPiAgaW50IGkzY19kZXZfcmVx dWVzdF9pYmlfbG9ja2VkKHN0cnVjdCBpM2NfZGV2X2Rlc2MgKmRldiwKPiAgCQkJICAgICAgIGNv bnN0IHN0cnVjdCBpM2NfaWJpX3NldHVwICpyZXEpCj4gIHsKPiAtCXN0cnVjdCBpM2NfbWFzdGVy X2NvbnRyb2xsZXIgKm1hc3RlciA9IGkzY19kZXZfZ2V0X21hc3RlcihkZXYpOwo+ICAJc3RydWN0 IGkzY19kZXZpY2VfaWJpX2luZm8gKmliaTsKPiAgCWludCByZXQ7Cj4gIAo+IC0JaWYgKCFtYXN0 ZXItPm9wcy0+cmVxdWVzdF9pYmkpCj4gLQkJcmV0dXJuIC1FT1BOT1RTVVBQOwo+IC0KPiAgCWlm IChkZXYtPmliaSkKPiAgCQlyZXR1cm4gLUVCVVNZOwo+ICAKWyAuLi4gXQo+IEBAIC0zNjI3LDgg KzM3NzUsMTUgQEAgaW50IGkzY19kZXZfcmVxdWVzdF9pYmlfbG9ja2VkKHN0cnVjdCBpM2NfZGV2 X2Rlc2MgKmRldiwKPiAgCWliaS0+bnVtX3Nsb3RzID0gcmVxLT5udW1fc2xvdHM7Cj4gIAo+ICAJ ZGV2LT5pYmkgPSBpYmk7Cj4gLQlyZXQgPSBtYXN0ZXItPm9wcy0+cmVxdWVzdF9pYmkoZGV2LCBy ZXEpOwo+ICsJcmV0ID0gaTNjX2Rldl9yZXF1ZXN0X2liaV9jb250cm9sbGVyX2xvY2tlZChkZXYs IHJlcSk7Cj4gIAlpZiAocmV0KSB7Cj4gKwkJLyoKPiArCQkgKiBUaGUgY29udHJvbGxlciByZXF1 ZXN0IGNhbGxiYWNrIGZhaWxlZCwgc28gdGVhciBkb3duIHRoZQo+ICsJCSAqIHdvcmtxdWV1ZSBh bGxvY2F0ZWQgYWJvdmUgYmVmb3JlIGZyZWVpbmcgdGhlIElCSSBvYmplY3QuCj4gKwkJICogVGhp cyBpcyB0aGUgb3duZXIgb2YgdGhlIHdvcmtxdWV1ZSwgc28gaXQgbXVzdCBkZXN0cm95IGl0Cj4g KwkJICogaGVyZSB0byBhdm9pZCBsZWFraW5nIGl0IG9uIHRoZSBlcnJvciBwYXRoLgo+ICsJCSAq Lwo+ICsJCWRlc3Ryb3lfd29ya3F1ZXVlKGliaS0+d3EpOwo+ICAJCWtmcmVlKGliaSk7Cj4gIAkJ ZGV2LT5pYmkgPSBOVUxMOwo+ICAJfQoKW1NldmVyaXR5OiBNZWRpdW1dClNpbmNlIHRoZSBjaGVj ayBmb3IgbWFzdGVyLT5vcHMtPnJlcXVlc3RfaWJpIHdhcyBtb3ZlZCBpbnRvCmkzY19kZXZfcmVx dWVzdF9pYmlfY29udHJvbGxlcl9sb2NrZWQoKSwgdGhpcyBjb2RlIG5vdyB1bmNvbmRpdGlvbmFs bHkKY3JlYXRlcyBhIG5ldyBvcmRlcmVkIHdvcmtxdWV1ZSBkdXJpbmcgZGV2aWNlIHByb2JlIGV2 ZW4gd2hlbiB0aGUKdW5kZXJseWluZyBjb250cm9sbGVyIGRvZXNuJ3Qgc3VwcG9ydCBJQklzLgoK RG9lcyB0aGlzIHVubmVjZXNzYXJ5IGFsbG9jYXRpb24gYW5kIGRlc3RydWN0aW9uIG9mIGEgd29y a3F1ZXVlIHRocmVhZAood2hpY2ggaW52b2x2ZXMgc3lzZnMgcmVnaXN0cmF0aW9uIGFuZCBSQ1Ug c3luY2hyb25pemF0aW9uKSBhZGQgYSBub3RpY2VhYmxlCnBlcmZvcm1hbmNlIGRlbGF5IGZvciBk ZXZpY2VzIG9uIGNvbnRyb2xsZXJzIHdpdGhvdXQgSUJJIHN1cHBvcnQ/CgpbIC4uLiBdCj4gQEAg LTM2NjcsNyArMzg0Myw3IEBAIHZvaWQgaTNjX2Rldl9mcmVlX2liaV9sb2NrZWQoc3RydWN0IGkz Y19kZXZfZGVzYyAqZGV2KQo+ICAJCQlkZXZfZXJyKCZtYXN0ZXItPmRldiwgIkZhaWxlZCB0byBk aXNhYmxlIElCSSBiZWZvcmUgZnJlZWluZ1xuIik7Cj4gIAl9Cj4gIAo+IC0JbWFzdGVyLT5vcHMt PmZyZWVfaWJpKGRldik7Cj4gKwlpM2NfZGV2X2ZyZWVfaWJpX2NvbnRyb2xsZXJfbG9ja2VkKGRl dik7Cj4gIAo+ICAJaWYgKGRldi0+aWJpLT53cSkgewo+ICAJCWRlc3Ryb3lfd29ya3F1ZXVlKGRl di0+aWJpLT53cSk7CgpbU2V2ZXJpdHk6IENyaXRpY2FsXQpUaGlzIGlzIGEgcHJlLWV4aXN0aW5n IGlzc3VlLCBidXQgY2FuIGNhbGxpbmcKaTNjX2Rldl9mcmVlX2liaV9jb250cm9sbGVyX2xvY2tl ZCgpIGJlZm9yZSBkZXN0cm95X3dvcmtxdWV1ZShkZXYtPmliaS0+d3EpCmNhdXNlIGEgdXNlLWFm dGVyLWZyZWU/CgpJZiBpM2NfZGV2X2Rpc2FibGVfaWJpX2xvY2tlZCgpIGZhaWxzIChlLmcuIGR1 ZSB0byBhIGJ1cyB0aW1lb3V0KSwgdGhlCnRlYXJkb3duIGNvbnRpbnVlcyBhbmQgaW52b2tlcyB0 aGUgY29udHJvbGxlcidzIGZyZWVfaWJpIGNhbGxiYWNrLCB3aGljaAppbW1lZGlhdGVseSBmcmVl cyB0aGUgZ2VuZXJpYyBJQkkgcG9vbCBtZW1vcnkuCgpJZiB0aGVyZSBhcmUgc3RpbGwgcGVuZGlu ZyBJQkkgd29yayBpdGVtcyBiZWNhdXNlIGRlc3Ryb3lfd29ya3F1ZXVlKCkgaGFzbid0CmJlZW4g Y2FsbGVkIHRvIGRyYWluIHRoZW0geWV0LCB3aWxsIHRoZSB3b3JrcXVldWUgcHJvY2VzcyB0aGVt IGFuZApkZXJlZmVyZW5jZSB0aGUgZnJlZWQgZ2VuZXJpYyBJQkkgc2xvdHM/CgpBZGRpdGlvbmFs bHksIGNvdWxkIGFuIGFjdGl2ZSBoYXJkd2FyZSBpbnRlcnJ1cHQgc3RpbGwgZmlyZSBhbmQgcmFj ZSB3aXRoCnRoZSBjb250cm9sbGVyJ3MgZnJlZV9pYmkgY2FsbGJhY2ssIGxlYWRpbmcgdG8gbWVt b3J5IGNvcnJ1cHRpb24gaW5zaWRlIHRoZQppbnRlcnJ1cHQgaGFuZGxlcj8KCi0tIApTYXNoaWtv IEFJIHJldmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA4MjYxMDM4 MTkuMTYxNDg0My0xLWxha3NoYXkucGlwbGFuaUBueHAuY29tP3BhcnQ9MgoKLS0gCmxpbnV4LWkz YyBtYWlsaW5nIGxpc3QKbGludXgtaTNjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3Rz LmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1pM2MK 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 E17C437AA79 for ; Wed, 26 Aug 2026 10:50:47 +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=1787741462; cv=none; b=biq5p3bqlMKs9cK6HwUB57GmNP80B3roYHR9VdGvc/01SjXdt5UV0PYaP9YSYqycyrSxki3mxxeTNfx4g+REOdShrEkl2eNmX/+EthD+5DwX1GDjpT8nRxlfXoosdidQu06MPtEwLu2HsnM2GijdcGHnYFgpPJ/h7afa8zYgxsE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787741462; c=relaxed/simple; bh=i/A6bdZ7KJmyziyRnpqMarB0JrRrD2m/3fAAiA7tzf8=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=j/j4nM3dmTmyWO18zNPm+qkysKUYKzYxBR1brAgERbcwrCFwJAWaFi6Da/MNhWStR1nT8s5zGU/uiGVZv/qUGgt+tDn5ZHJYic8o4CLgQ5ppW6z33P0jLL1fSnAmkOHPWaEbYF1O1UHjBODW+tQy2TOUMoweGFcZPPgy6MIJtCw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RNAScqSz; 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="RNAScqSz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3DA21F000E9; Wed, 26 Aug 2026 10:50:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787741446; bh=YtDaSLVh0eAnWe9c7pCY+O1a4NZv1iXPrGsIhLqFcAU=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=RNAScqSzwiCffQ8dSN8nhNAxS4OcaeWh+jfYO82JrhBV1Ew/ofdriceaxl9vgcRFv xzyRnBhkvlrUpDep8+rRrj7K0rn3uvabLBZML8NjMLSi0k4fyMOae/o5m4sIwYacT0 DzP20Kj1kuVu+GxAvLyFB6dRixUEc+kMrlH9OW6w0yDqO9yaPVi/fL++414GfoR7G0 6qXVNEu/MPTYXmF4gsHPwxgU3siNyO0T0/Ax7A2Gp/obpURTdmxMw+u+BB6qToZVYx YGmogEAvgjTFQiwVaO0bCYutmF45uL52mm/kQ4DbWf2omm+Q5Ph94z2QTFMZhTA+9k 3rxA405UkUV1g== From: sashiko-bot@kernel.org Subject: Re: [PATCH v16 2/8] i3c: master: Add controller-only device operation helpers Reply-To: sashiko-reviews@lists.linux.dev To: "Lakshay Piplani" Cc: linux-i3c@lists.infradead.org, Frank.Li@kernel.org, "Alexandre Belloni" , conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org In-Reply-To: <20260826103819.1614843-3-lakshay.piplani@nxp.com> References: <20260826103819.1614843-1-lakshay.piplani@nxp.com> <20260826103819.1614843-3-lakshay.piplani@nxp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2026 10:50:45 +0000 Message-Id: <20260826105045.B3DA21F000E9@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: New issues: - [Medium] Unnecessary heavy workqueue allocation and teardown when a contr= oller does not support IBIs. Pre-existing issues: - [Critical] Potential use-after-free of generic IBI pool slots and `dev->i= bi` when disabling an active IBI fails during teardown. -- commit f38c11b5d94a35f5b99f6a1f23bbb449f122ded4 Author: Lakshay Piplani i3c: master: Add controller-only device operation helpers The generic I3C device attach and IBI paths perform both core-level bookkeeping and controller-specific operations. Add controller-only helpers that invoke the controller callbacks without updating the bus device list, address-slot state, or generic IBI lifecycle. Also release the generic IBI workqueue and state when the controller request callback fails. > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > index 03fb41f0786c5..88379b6809a64 100644 > --- a/drivers/i3c/master.c > +++ b/drivers/i3c/master.c [ ... ] > @@ -3600,13 +3752,9 @@ EXPORT_SYMBOL_GPL(i3c_dev_enable_ibi_locked); > int i3c_dev_request_ibi_locked(struct i3c_dev_desc *dev, > const struct i3c_ibi_setup *req) > { > - struct i3c_master_controller *master =3D i3c_dev_get_master(dev); > struct i3c_device_ibi_info *ibi; > int ret; > =20 > - if (!master->ops->request_ibi) > - return -EOPNOTSUPP; > - > if (dev->ibi) > return -EBUSY; > =20 [ ... ] > @@ -3627,8 +3775,15 @@ int i3c_dev_request_ibi_locked(struct i3c_dev_desc= *dev, > ibi->num_slots =3D req->num_slots; > =20 > dev->ibi =3D ibi; > - ret =3D master->ops->request_ibi(dev, req); > + ret =3D i3c_dev_request_ibi_controller_locked(dev, req); > if (ret) { > + /* > + * The controller request callback failed, so tear down the > + * workqueue allocated above before freeing the IBI object. > + * This is the owner of the workqueue, so it must destroy it > + * here to avoid leaking it on the error path. > + */ > + destroy_workqueue(ibi->wq); > kfree(ibi); > dev->ibi =3D NULL; > } [Severity: Medium] Since the check for master->ops->request_ibi was moved into i3c_dev_request_ibi_controller_locked(), this code now unconditionally creates a new ordered workqueue during device probe even when the underlying controller doesn't support IBIs. Does this unnecessary allocation and destruction of a workqueue thread (which involves sysfs registration and RCU synchronization) add a noticeable performance delay for devices on controllers without IBI support? [ ... ] > @@ -3667,7 +3843,7 @@ void i3c_dev_free_ibi_locked(struct i3c_dev_desc *d= ev) > dev_err(&master->dev, "Failed to disable IBI before freeing\n"); > } > =20 > - master->ops->free_ibi(dev); > + i3c_dev_free_ibi_controller_locked(dev); > =20 > if (dev->ibi->wq) { > destroy_workqueue(dev->ibi->wq); [Severity: Critical] This is a pre-existing issue, but can calling i3c_dev_free_ibi_controller_locked() before destroy_workqueue(dev->ibi->wq) cause a use-after-free? If i3c_dev_disable_ibi_locked() fails (e.g. due to a bus timeout), the teardown continues and invokes the controller's free_ibi callback, which immediately frees the generic IBI pool memory. If there are still pending IBI work items because destroy_workqueue() hasn't been called to drain them yet, will the workqueue process them and dereference the freed generic IBI slots? Additionally, could an active hardware interrupt still fire and race with the controller's free_ibi callback, leading to memory corruption inside the interrupt handler? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260826103819.1614= 843-1-lakshay.piplani@nxp.com?part=3D2