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 39585C43458 for ; Sat, 11 Jul 2026 17:14:35 +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=RELfoacsjGhzTIM6aFWCHwmcgE8HziYklzao8dywsSs=; b=xhoUIspqvbEd0N n283990Zip77A3iDaCngY9zzfralGZ1+Kim4fiftEUjcsdc0Id47NyhR3G3Dlk47zoFkpmZofbkG8 dC75vEyFzb1Uwt1Q26tkZ0bJtCxMesgzysWA1537W1S0dNAhPFxjOkr/AaJ3R4WHuFi7l36vC90Bh yyAQ7tMqpT8WcjADo5zQbeF/IDKN3DEfH/EDfspCbfKSVjdHx1H1fXQowPZp/f9s01BPUMISKQf5s otRQWiq/gZ8Z/hK+dGIXB7Hj/Vo1dDJ6CdKnSn4SoDCNFStaTh1YzreFtiDnoV6apqdZXJpXdkkFn 50qNYqQdE2f+5lY3clwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wibHe-00000006ijM-44pJ; Sat, 11 Jul 2026 17:14:34 +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 1wibHd-00000006ijG-3Ap2 for linux-phy@lists.infradead.org; Sat, 11 Jul 2026 17:14:33 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 1F19B6111A; Sat, 11 Jul 2026 17:14:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 670041F000E9; Sat, 11 Jul 2026 17:14:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783790072; bh=hvnalrBrz7i25/1/ePJ4MowKK0ECNIieiQuBXigipO8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=cxKJN5qB9qc0seAXVGKftyhVjq8t9PchyYuu4c/VnQ7TEXm6aGqfMbh4l4ef7ve5X wb5XFVgk3HCCu39hRDBgdgdayj9G7t+aLFJuN1kEVcLef0xWo35oNozoAMLt4wRISo tKn4AbTuCwU/6UfJWA7ZvfHrb/WfpHt9VZM99QNCu/3cn63XiRSo721hNYTvFEoDam /ch1f7HlE7Qy1fu8qIXxFSSZeLnSqewlP+duz3DKNfHJ2rTPGiAh9wjYhnRKz/Nmps ygwVR/zfUjc2Zf7laECH3yYUpgdZKg4CstK9a4bxrqeeKWBQssmTkIqBr0sJpJgrRV lqgdsvHo/D6Pw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v4 4/6] phy: cpcap-usb: add extcon support To: "Ivaylo Dimitrov" Cc: olteanv@gmail.com, linux-phy@lists.infradead.org, conor+dt@kernel.org, vkoul@kernel.org, robh@kernel.org, devicetree@vger.kernel.org, neil.armstrong@linaro.org In-Reply-To: <20260711164754.185565-5-ivo.g.dimitrov.75@gmail.com> References: <20260711164754.185565-1-ivo.g.dimitrov.75@gmail.com> <20260711164754.185565-5-ivo.g.dimitrov.75@gmail.com> Date: Sat, 11 Jul 2026 17:14:31 +0000 Message-Id: <20260711171432.670041F000E9@smtp.kernel.org> X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list 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-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MiBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtNZWRpdW1d IFRoZSBvcmRlcmluZyBvZiBleHRjb24gc3RhdGUgdXBkYXRlcyBleHBvc2VzIGludmFsaWQgaW50 ZXJtZWRpYXRlIGNhYmxlIHN0YXRlcyB0byB1c2Vyc3BhY2UuCgpQcmUtZXhpc3RpbmcgaXNzdWVz OgotIFtIaWdoXSBQcmUtZXhpc3RpbmcgVUFGOiBEZWxheWVkIHdvcmsgY2FuIGJlIHJlLWFybWVk IGFmdGVyIGNhbmNlbF9kZWxheWVkX3dvcmtfc3luYygpIGR1cmluZyBkcml2ZXIgcmVtb3ZhbCBk dWUgdG8gYW4gSVJRIHRocmVhZCByYWNlLgotLQoKLS0tIFBhdGNoIFs0XTogW1BBVENIIHY0IDQv Nl0gcGh5OiBjcGNhcC11c2I6IGFkZCBleHRjb24gc3VwcG9ydCAtLS0KY29tbWl0IDVmYTZhYWI1 NDJkOTJhMmM3OWZiZTUxOTVhODYxODU5OTc2NTA3YjYKQXV0aG9yOiBJdmF5bG8gRGltaXRyb3Yg PGl2by5nLmRpbWl0cm92Ljc1QGdtYWlsLmNvbT4KCnBoeTogY3BjYXAtdXNiOiBhZGQgZXh0Y29u IHN1cHBvcnQKClRoaXMgY29tbWl0IHJlZ2lzdGVycyBhbiBFeHRjb24gZGV2aWNlIGFuZCByZXBv cnRzIHRoZSBkZXRlY3RlZCBVU0IgY2FibGUKc3RhdGUuIEl0IGV4cG9ydHMgdGhpcyBzdGF0ZSB0 aHJvdWdoIHRoZSBFeHRjb24gZnJhbWV3b3JrIHNvIG90aGVyIGRyaXZlcnMKY2FuIGNvbnN1bWUg aXQgdXNpbmcgc3RhbmRhcmQga2VybmVsIGludGVyZmFjZXMuCgo+IGRpZmYgLS1naXQgYS9kcml2 ZXJzL3BoeS9tb3Rvcm9sYS9waHktY3BjYXAtdXNiLmMgYi9kcml2ZXJzL3BoeS9tb3Rvcm9sYS9w aHktY3BjYXAtdXNiLmMKPiBpbmRleCBkNGViODA4NmI2MDAwLi44ZjliZWExZDhhMjEyIDEwMDY0 NAo+IC0tLSBhL2RyaXZlcnMvcGh5L21vdG9yb2xhL3BoeS1jcGNhcC11c2IuYwo+ICsrKyBiL2Ry aXZlcnMvcGh5L21vdG9yb2xhL3BoeS1jcGNhcC11c2IuYwpbIC4uLiBdCj4gQEAgLTIyNiw2ICsy MzksNDYgQEAgc3RhdGljIHZvaWQgY3BjYXBfdXNiX3RyeV9tdXNiX21haWxib3goc3RydWN0IGNw Y2FwX3BoeV9kZGF0YSAqZGRhdGEsCj4gIAkJX19mdW5jX18sIGVycm9yKTsKPiAgfQo+ICAKPiAr c3RhdGljIHZvaWQgY3BjYXBfdXNiX3NldF9leHRjb24oc3RydWN0IGNwY2FwX3BoeV9kZGF0YSAq ZGRhdGEpCj4gK3sKPiArCWludCBjYWJsZTsKPiArCj4gKwlzd2l0Y2ggKGRkYXRhLT5tb2RlKSB7 ClsgLi4uIF0KPiArCWlmIChjYWJsZSA9PSBkZGF0YS0+Y2FibGUpCj4gKwkJcmV0dXJuOwo+ICsK PiArCWlmIChkZGF0YS0+Y2FibGUgPT0gRVhUQ09OX0NIR19VU0JfU0RQKQo+ICsJCWV4dGNvbl9z ZXRfc3RhdGVfc3luYyhkZGF0YS0+ZWRldiwgRVhUQ09OX1VTQiwgZmFsc2UpOwo+ICsJZWxzZSBp ZiAoY2FibGUgPT0gRVhUQ09OX0NIR19VU0JfU0RQKQo+ICsJCWV4dGNvbl9zZXRfc3RhdGVfc3lu YyhkZGF0YS0+ZWRldiwgRVhUQ09OX1VTQiwgdHJ1ZSk7Cj4gKwo+ICsJaWYgKGRkYXRhLT5jYWJs ZSAhPSBFWFRDT05fTk9ORSkKPiArCQlleHRjb25fc2V0X3N0YXRlX3N5bmMoZGRhdGEtPmVkZXYs IGRkYXRhLT5jYWJsZSwgZmFsc2UpOwoKW1NldmVyaXR5OiBNZWRpdW1dCkNvdWxkIHRoaXMgb3Jk ZXJpbmcgZXhwb3NlIGludmFsaWQgaW50ZXJtZWRpYXRlIGNhYmxlIHN0YXRlcyB0byB1c2Vyc3Bh Y2U/CgpXaGVuIHRyYW5zaXRpb25pbmcgdG8gYSBuZXcgY2FibGUgc3RhdGUgKHNwZWNpZmljYWxs eSBFWFRDT05fQ0hHX1VTQl9TRFApLAp0aGUgbmV3IHN0YXRlJ3MgYXNzb2NpYXRlZCBFWFRDT05f VVNCIHN0YXRlIGlzIGVuYWJsZWQgYmVmb3JlIHRoZSBvbGQKZGRhdGEtPmNhYmxlIHN0YXRlIGlz IGNsZWFyZWQuCgpCZWNhdXNlIGV4dGNvbl9zZXRfc3RhdGVfc3luYygpIGltbWVkaWF0ZWx5IG5v dGlmaWVzIGNvbnN1bWVycyBhbmQgZW1pdHMgYQp1ZXZlbnQsIGNvbnN1bWVycyBtaWdodCBicmll Zmx5IG9ic2VydmUgb3ZlcmxhcHBpbmcsIG11dHVhbGx5IGV4Y2x1c2l2ZQpzdGF0ZXMgKHN1Y2gg YXMgYm90aCBEQ1AgYW5kIFNEUCBhY3RpdmUgc2ltdWx0YW5lb3VzbHkpLgoKV291bGQgaXQgYmUg c2FmZXIgdG8gY29tcGxldGVseSBjbGVhciB0aGUgb2xkIHN0YXRlcyBiZWZvcmUgYXNzZXJ0aW5n IGFueQpuZXcgc3RhdGVzPwoKPiArCj4gKwlpZiAoY2FibGUgIT0gRVhUQ09OX05PTkUpCj4gKwkJ ZXh0Y29uX3NldF9zdGF0ZV9zeW5jKGRkYXRhLT5lZGV2LCBjYWJsZSwgdHJ1ZSk7Cj4gKwo+ICsJ ZGRhdGEtPmNhYmxlID0gY2FibGU7Cj4gK30KWyAuLi4gXQoKCltTZXZlcml0eTogSGlnaF0KVGhp cyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IEkgbm90aWNlZCBhIHBvdGVudGlhbCB1c2Ut YWZ0ZXItZnJlZSByYWNlCmludm9sdmluZyB0aGUgZGVsYXllZCB3b3JrIGR1cmluZyBkcml2ZXIg dW5iaW5kLiBEb2VzIHRoaXMgZXhlY3V0aW9uIHNlcXVlbmNlCmxlYXZlIHRoZSB3b3JrIHF1ZXVl ZCBhZnRlciByZW1vdmFsPwoKSWYgdGhlIElSUSB0aHJlYWQgY2hlY2tzIGRkYXRhLT5hY3RpdmUg YW5kIGdldHMgcHJlZW1wdGVkIGJlZm9yZSBjYWxsaW5nCnNjaGVkdWxlX2RlbGF5ZWRfd29yaygp OgoKY3BjYXBfcGh5X2lycV90aHJlYWQoKSB7CiAgICAuLi4KICAgIGlmIChhdG9taWNfcmVhZCgm ZGRhdGEtPmFjdGl2ZSkpCiAgICAgICAgLi4uIDxwcmVlbXB0ZWQgaGVyZT4gLi4uCgpjcGNhcF91 c2JfcGh5X3JlbW92ZSgpIGNhbiBjb25jdXJyZW50bHkgc2V0IGFjdGl2ZSB0byAwIGFuZCBjYWxs CmNhbmNlbF9kZWxheWVkX3dvcmtfc3luYygpLiBTaW5jZSB0aGUgd29yayBpc24ndCBxdWV1ZWQg eWV0LCB0aGUKY2FuY2VsbGF0aW9uIGNvbXBsZXRlcyBpbW1lZGlhdGVseToKCmNwY2FwX3VzYl9w aHlfcmVtb3ZlKCkgewogICAgLi4uCiAgICBhdG9taWNfc2V0KCZkZGF0YS0+YWN0aXZlLCAwKTsK ICAgIGNhbmNlbF9kZWxheWVkX3dvcmtfc3luYygmZGRhdGEtPmRldGVjdF93b3JrKTsKICAgIC4u LgoKRHVyaW5nIGRldnJlcyBjbGVhbnVwLCBmcmVlX2lycSgpIHdhaXRzIGZvciB0aGUgSVJRIHRo cmVhZCB0byBmaW5pc2guClRoZSB0aHJlYWQgdGhlbiByZXN1bWVzLCB1bmNvbmRpdGlvbmFsbHkg Y2FsbHMgc2NoZWR1bGVfZGVsYXllZF93b3JrKCksCmFuZCBleGl0czoKCiAgICAgICAgc2NoZWR1 bGVfZGVsYXllZF93b3JrKCZkZGF0YS0+ZGV0ZWN0X3dvcmssIG1zZWNzX3RvX2ppZmZpZXMoMSkp Owp9CgpBZnRlciBmcmVlX2lycSgpIGNvbXBsZXRlcywgZGV2cmVzIGZyZWVzIGRkYXRhLiBUaGUg ZGVsYXllZCB3b3JrIHdpbGwKc3Vic2VxdWVudGx5IGV4ZWN1dGUgYW5kIGFjY2VzcyB0aGUgZnJl ZWQgbWVtb3J5LgoKQ291bGQgdGhpcyBiZSBwcmV2ZW50ZWQgYnkgZGlzYWJsaW5nIElSUXMgcHJp b3IgdG8gY2FuY2VsbGluZyB0aGUgd29yaz8KCi0tIApTYXNoaWtvIEFJIHJldmlldyDCtyBodHRw czovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA3MTExNjQ3NTQuMTg1NTY1LTEtaXZvLmcu ZGltaXRyb3YuNzVAZ21haWwuY29tP3BhcnQ9NAoKLS0gCmxpbnV4LXBoeSBtYWlsaW5nIGxpc3QK bGludXgtcGh5QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cHM6Ly9saXN0cy5pbmZyYWRlYWQub3Jn L21haWxtYW4vbGlzdGluZm8vbGludXgtcGh5Cg== 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 E536D3CAA52 for ; Sat, 11 Jul 2026 17:14:32 +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=1783790074; cv=none; b=sbxdZRV87ekjzIErVtcZsfXKEoI/QLV4M8Yr8NQcVtl4iwHUAKmh6vprbLT98Nce5zWAKHHcdmyrR4ZE4Q64vfyGbPo+Hj7pY3DGmCco/+tss9YXPlniDsTBfo6ezLMV3gpXc7rfz4ImRDM4R/Elop34nsm99O4vdemvEDC9P84= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783790074; c=relaxed/simple; bh=fV/n2Djoj48Pj22BodXIAAYSOy8lEdhA+K6p4gtHoHc=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=Sh3/k6etCSy5Nz33DHWmAIqaoymnlIIOK6cv8qVUMJ6OZ68EiqmuBxe+NYkLmrJMhIkQtOfcA/xVQKl+bC5eRdepQZKqkIRsxoPdSNQRXcpuXuiHMJV5gOfQW6tKgKz2ih+xfCkt+i3ZSyWM7UXen4hPx3GwMZt/KZokNoGtE2Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cxKJN5qB; 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="cxKJN5qB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 670041F000E9; Sat, 11 Jul 2026 17:14:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783790072; bh=hvnalrBrz7i25/1/ePJ4MowKK0ECNIieiQuBXigipO8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=cxKJN5qB9qc0seAXVGKftyhVjq8t9PchyYuu4c/VnQ7TEXm6aGqfMbh4l4ef7ve5X wb5XFVgk3HCCu39hRDBgdgdayj9G7t+aLFJuN1kEVcLef0xWo35oNozoAMLt4wRISo tKn4AbTuCwU/6UfJWA7ZvfHrb/WfpHt9VZM99QNCu/3cn63XiRSo721hNYTvFEoDam /ch1f7HlE7Qy1fu8qIXxFSSZeLnSqewlP+duz3DKNfHJ2rTPGiAh9wjYhnRKz/Nmps ygwVR/zfUjc2Zf7laECH3yYUpgdZKg4CstK9a4bxrqeeKWBQssmTkIqBr0sJpJgrRV lqgdsvHo/D6Pw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v4 4/6] phy: cpcap-usb: add extcon support Reply-To: sashiko-reviews@lists.linux.dev To: "Ivaylo Dimitrov" Cc: olteanv@gmail.com, linux-phy@lists.infradead.org, conor+dt@kernel.org, vkoul@kernel.org, robh@kernel.org, devicetree@vger.kernel.org, neil.armstrong@linaro.org In-Reply-To: <20260711164754.185565-5-ivo.g.dimitrov.75@gmail.com> References: <20260711164754.185565-1-ivo.g.dimitrov.75@gmail.com> <20260711164754.185565-5-ivo.g.dimitrov.75@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 11 Jul 2026 17:14:31 +0000 Message-Id: <20260711171432.670041F000E9@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] The ordering of extcon state updates exposes invalid intermediat= e cable states to userspace. Pre-existing issues: - [High] Pre-existing UAF: Delayed work can be re-armed after cancel_delaye= d_work_sync() during driver removal due to an IRQ thread race. -- --- Patch [4]: [PATCH v4 4/6] phy: cpcap-usb: add extcon support --- commit 5fa6aab542d92a2c79fbe5195a861859976507b6 Author: Ivaylo Dimitrov phy: cpcap-usb: add extcon support This commit registers an Extcon device and reports the detected USB cable state. It exports this state through the Extcon framework so other drivers can consume it using standard kernel interfaces. > diff --git a/drivers/phy/motorola/phy-cpcap-usb.c b/drivers/phy/motorola/= phy-cpcap-usb.c > index d4eb8086b6000..8f9bea1d8a212 100644 > --- a/drivers/phy/motorola/phy-cpcap-usb.c > +++ b/drivers/phy/motorola/phy-cpcap-usb.c [ ... ] > @@ -226,6 +239,46 @@ static void cpcap_usb_try_musb_mailbox(struct cpcap_= phy_ddata *ddata, > __func__, error); > } > =20 > +static void cpcap_usb_set_extcon(struct cpcap_phy_ddata *ddata) > +{ > + int cable; > + > + switch (ddata->mode) { [ ... ] > + if (cable =3D=3D ddata->cable) > + return; > + > + if (ddata->cable =3D=3D EXTCON_CHG_USB_SDP) > + extcon_set_state_sync(ddata->edev, EXTCON_USB, false); > + else if (cable =3D=3D EXTCON_CHG_USB_SDP) > + extcon_set_state_sync(ddata->edev, EXTCON_USB, true); > + > + if (ddata->cable !=3D EXTCON_NONE) > + extcon_set_state_sync(ddata->edev, ddata->cable, false); [Severity: Medium] Could this ordering expose invalid intermediate cable states to userspace? When transitioning to a new cable state (specifically EXTCON_CHG_USB_SDP), the new state's associated EXTCON_USB state is enabled before the old ddata->cable state is cleared. Because extcon_set_state_sync() immediately notifies consumers and emits a uevent, consumers might briefly observe overlapping, mutually exclusive states (such as both DCP and SDP active simultaneously). Would it be safer to completely clear the old states before asserting any new states? > + > + if (cable !=3D EXTCON_NONE) > + extcon_set_state_sync(ddata->edev, cable, true); > + > + ddata->cable =3D cable; > +} [ ... ] [Severity: High] This is a pre-existing issue, but I noticed a potential use-after-free race involving the delayed work during driver unbind. Does this execution sequen= ce leave the work queued after removal? If the IRQ thread checks ddata->active and gets preempted before calling schedule_delayed_work(): cpcap_phy_irq_thread() { ... if (atomic_read(&ddata->active)) ... ... cpcap_usb_phy_remove() can concurrently set active to 0 and call cancel_delayed_work_sync(). Since the work isn't queued yet, the cancellation completes immediately: cpcap_usb_phy_remove() { ... atomic_set(&ddata->active, 0); cancel_delayed_work_sync(&ddata->detect_work); ... During devres cleanup, free_irq() waits for the IRQ thread to finish. The thread then resumes, unconditionally calls schedule_delayed_work(), and exits: schedule_delayed_work(&ddata->detect_work, msecs_to_jiffies(1)); } After free_irq() completes, devres frees ddata. The delayed work will subsequently execute and access the freed memory. Could this be prevented by disabling IRQs prior to cancelling the work? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260711164754.1855= 65-1-ivo.g.dimitrov.75@gmail.com?part=3D4