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 D2477C43458 for ; Sat, 4 Jul 2026 07:51:38 +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=DGVUxevyHJ9pBKj/eFrxUK6+UQpu5QRuSYLV8u2YOxE=; b=Fj4n0b1eg7R5Xk q11dxUXzD6GmvQdIYKsov92nHEJsHIB4FzwMuKzCY8eMEmQgRNU64xFFZtOKv/He0uHdNXQX5noYL PIgyOOUrvXJqdn/KqdnnY7tJq3vFm55yqBtLF3N+9xhez4IVliYdSdKmMZf9r9Pn2kONbYFVuXIBT mTVRcJupqpfqRax7y1MpgIMtPJVC2nWh/x1RzWGtaYeMXDtZXHFR/5bRaVUkyNZYU3KMgRDBpI8EV HXynoySzhocVoHJq+pYfEQkEIhXM1DWxDrEkVsd/366AFcULK5X9jtMiEkoVQCpsLauSFt131gEhC dWNUlEABBKCgGWYdUM7w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wfvA2-00000008H3g-2TgI; Sat, 04 Jul 2026 07:51:38 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wfvA1-00000008H3a-0EIO for linux-phy@lists.infradead.org; Sat, 04 Jul 2026 07:51:37 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id BA9DC40122; Sat, 4 Jul 2026 07:51:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0014E1F000E9; Sat, 4 Jul 2026 07:51:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783151496; bh=nk6nP7hmKCgBnsx+MNVD61Cm7aZyuBzkUCKBoY7kSj0=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=c+BDokhpWiPzgGP+7wIiERr9pI7Jx51Fed5Hpd0TFL8FVQIwTTuuSwF1aqzi3L4mf D9feTB1bOJkXweUq7zKEmTCBqLxjTNVdxmqHEYCFK6JRvHUdqHK1JFIJHme2/aKTR5 kvLrycknJl9EByuxn856hP/pDHNp1qsmDK8Z4Nrn7Gj8qmZQQAmmPpz0MHb2jQax+z VvkPN50n3bYSmSFMSgWRvp3h9Rc03p5yoEyl3lz9XR/QNJf3CXAiUo9u4UqtHH3hnm Pg2QWNX54zkRdbze2+ubfb6HRp8ExleIo7ZRBcRR8EJJngVhwbljtJgjUfomEHlfkw 0Ixhx2JocRXog== From: sashiko-bot@kernel.org Subject: Re: [PATCH 5/5] phy: cpcap-usb: add extcon support To: "Ivaylo Dimitrov" Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, neil.armstrong@linaro.org, vkoul@kernel.org, linux-phy@lists.infradead.org, robh@kernel.org, olteanv@gmail.com In-Reply-To: <20260704073843.1750458-6-ivo.g.dimitrov.75@gmail.com> References: <20260704073843.1750458-1-ivo.g.dimitrov.75@gmail.com> <20260704073843.1750458-6-ivo.g.dimitrov.75@gmail.com> Date: Sat, 04 Jul 2026 07:51:35 +0000 Message-Id: <20260704075136.0014E1F000E9@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 MyBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6CgpOZXcgaXNzdWVzOgotIFtIaWdoXSBU aGUgRVhUQ09OX1VTQiBzdGF0ZSBpcyB1cGRhdGVkIHVzaW5nIGBleHRjb25fc2V0X3N0YXRlYCB3 aXRob3V0IGEgY29ycmVzcG9uZGluZyBgZXh0Y29uX3NldF9zdGF0ZV9zeW5jYCBvciBgZXh0Y29u X3N5bmNgLCBwcmV2ZW50aW5nIHJlZ2lzdGVyZWQgbGlzdGVuZXJzIGZyb20gcmVjZWl2aW5nIHN0 YXRlIGNoYW5nZSBub3RpZmljYXRpb25zLgotIFtNZWRpdW1dIEV4dGNvbiBzdGF0ZSBjYW4gYmVj b21lIHBlcm1hbmVudGx5IGRlc3luY2hyb25pemVkIGZyb20gdGhlIGhhcmR3YXJlL3NvZnR3YXJl IHN0YXRlIHdoZW4gcmVnbWFwIHVwZGF0ZXMgZmFpbC4KClByZS1leGlzdGluZyBpc3N1ZXM6Ci0g W0hpZ2hdIFRoZSBkcml2ZXIncyByZW1vdmUgcGF0aCByYWNlcyB3aXRoIHRoZSBkZXZyZXMtbWFu YWdlZCB0aHJlYWRlZCBJUlEgaGFuZGxlciwgbGVhZGluZyB0byBhIFVzZS1BZnRlci1GcmVlIG9m IHRoZSBkcml2ZXIgZGF0YSBzdHJ1Y3R1cmUuCi0tCgpjb21taXQgNWUyMWQyMDkwNThlZTkzMzA0 ZGEwZTE5NjRiODQzMzljZjg3MDljMgpBdXRob3I6IEl2YXlsbyBEaW1pdHJvdiA8aXZvLmcuZGlt aXRyb3YuNzVAZ21haWwuY29tPgoKcGh5OiBjcGNhcC11c2I6IGFkZCBleHRjb24gc3VwcG9ydAoK UmVnaXN0ZXIgYW4gRXh0Y29uIGRldmljZSBhbmQgcmVwb3J0IHRoZSBkZXRlY3RlZCBjYWJsZSBz dGF0ZS4KVGhlIGRyaXZlciBhbHJlYWR5IGRldGVybWluZXMgdGhlIHR5cGUgb2YgY2FibGUgYXR0 YWNoZWQgZHVyaW5nIFVTQiBjYWJsZQpkZXRlY3Rpb24uIEV4cG9ydCB0aGUgZGV0ZWN0ZWQgc3Rh dGUgdGhyb3VnaCB0aGUgRXh0Y29uIGZyYW1ld29yayBzbwpvdGhlciBkcml2ZXJzIGNhbiBjb25z dW1lIGl0IHVzaW5nIGEgc3RhbmRhcmQga2VybmVsIGludGVyZmFjZS4KCj4gZGlmZiAtLWdpdCBh L2RyaXZlcnMvcGh5L21vdG9yb2xhL3BoeS1jcGNhcC11c2IuYyBiL2RyaXZlcnMvcGh5L21vdG9y b2xhL3BoeS1jcGNhcC11c2IuYwo+IGluZGV4IDNiZTJiM2FmYWFmNGQuLjg5NzhhOTVjMWMxOTkg MTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9waHkvbW90b3JvbGEvcGh5LWNwY2FwLXVzYi5jCj4gKysr IGIvZHJpdmVycy9waHkvbW90b3JvbGEvcGh5LWNwY2FwLXVzYi5jCj4gQEAgLTEyMyw2ICsxMjQs NyBAQCBzdHJ1Y3QgY3BjYXBfcGh5X2RkYXRhIHsKPiAgCXN0cnVjdCByZWdtYXAgKnJlZzsKPiAg CXN0cnVjdCBkZXZpY2UgKmRldjsKPiAgCXN0cnVjdCB1c2JfcGh5IHBoeTsKPiArCXN0cnVjdCBl eHRjb25fZGV2ICplZGV2Owo+ICAJc3RydWN0IGRlbGF5ZWRfd29yayBkZXRlY3Rfd29yazsKCltT ZXZlcml0eTogSGlnaF0KVGhpcyBpcyBhIHByZS1leGlzdGluZyBpc3N1ZSwgYnV0IGRvZXMgdGhl IHJlbW92ZSBwYXRoIHJhY2Ugd2l0aCB0aGUKZGV2cmVzLW1hbmFnZWQgdGhyZWFkZWQgSVJRIGhh bmRsZXIsIGxlYWRpbmcgdG8gYSB1c2UtYWZ0ZXItZnJlZSBvZiB0aGlzCmRyaXZlciBkYXRhIHN0 cnVjdHVyZT8KCklmIHRoZSBkZXZyZXMtbWFuYWdlZCBJUlEgdGhyZWFkIGNwY2FwX3BoeV9pcnFf dGhyZWFkKCkgZmlyZXMgYW5kIHJlYWRzCmRkYXRhLT5hY3RpdmUgYXMgMSwgYnV0IGlzIHByZWVt cHRlZCBiZWZvcmUgY2FsbGluZyBzY2hlZHVsZV9kZWxheWVkX3dvcmsoKToKCkFuZCB0aGVuIHRo ZSBkcml2ZXIgcmVtb3ZlIHBhdGggY3BjYXBfdXNiX3BoeV9yZW1vdmUoKSBleGVjdXRlcywgc2V0 cwpkZGF0YS0+YWN0aXZlIHRvIDAsIGNhbmNlbHMgYW55IHBlbmRpbmcgd29yaywgYW5kIHJldHVy bnMuCgpEZXZyZXMgY2xlYW51cCB0aGVuIGJlZ2lucywgY2FsbGluZyBkZXZtX2lycV9yZWxlYXNl KCkgLT4gZnJlZV9pcnEoKSAtPgpzeW5jaHJvbml6ZV9pcnEoKSwgd2hpY2ggYmxvY2tzIHdhaXRp bmcgZm9yIHRoZSBwcmVlbXB0ZWQgSVJRIHRocmVhZC4KCldoZW4gdGhlIElSUSB0aHJlYWQgcmVz dW1lcywgaXQgc3VjY2Vzc2Z1bGx5IHF1ZXVlcyB0aGUgZGVsYXllZCB3b3JrIGFuZApyZXR1cm5z LgoKT25jZSBkZXZtX2lycV9yZWxlYXNlKCkgZmluaXNoZXMsIGRldnJlcyBwcm9jZWVkcyB0byBm cmVlIGRkYXRhLgpUaGUgZGVsYXllZCB3b3JrIHRpbWVyIGV4cGlyZXMgYW5kIGV4ZWN1dGVzIGNw Y2FwX3VzYl9kZXRlY3QoKSBvbiB0aGUgZnJlZWQKZGRhdGEgbWVtb3J5LgoKPiBbIC4uLiBdCj4g QEAgLTIyNiw2ICsyMzksNDMgQEAgc3RhdGljIHZvaWQgY3BjYXBfdXNiX3RyeV9tdXNiX21haWxi b3goc3RydWN0IGNwY2FwX3BoeV9kZGF0YSAqZGRhdGEsCj4gWyAuLi4gXQo+ICtzdGF0aWMgdm9p ZCBjcGNhcF91c2Jfc2V0X2V4dGNvbihzdHJ1Y3QgY3BjYXBfcGh5X2RkYXRhICpkZGF0YSkKPiAr ewo+IFsgLi4uIF0KPiArCWlmIChkZGF0YS0+Y2FibGUgPT0gRVhUQ09OX0NIR19VU0JfU0RQKQo+ ICsJCWV4dGNvbl9zZXRfc3RhdGUoZGRhdGEtPmVkZXYsIEVYVENPTl9VU0IsIGZhbHNlKTsKPiAr CWVsc2UgaWYgKGNhYmxlID09IEVYVENPTl9DSEdfVVNCX1NEUCkKPiArCQlleHRjb25fc2V0X3N0 YXRlKGRkYXRhLT5lZGV2LCBFWFRDT05fVVNCLCB0cnVlKTsKCltTZXZlcml0eTogSGlnaF0KRG9l cyB0aGlzIHByZXZlbnQgcmVnaXN0ZXJlZCBsaXN0ZW5lcnMgZnJvbSByZWNlaXZpbmcgc3RhdGUg Y2hhbmdlCm5vdGlmaWNhdGlvbnMgZm9yIEVYVENPTl9VU0I/CgpUaGUgRVhUQ09OX1VTQiBzdGF0 ZSBpcyB1cGRhdGVkIGhlcmUgdXNpbmcgZXh0Y29uX3NldF9zdGF0ZSgpIHdpdGhvdXQgYQpjb3Jy ZXNwb25kaW5nIGV4dGNvbl9zZXRfc3RhdGVfc3luYygpIG9yIGV4dGNvbl9zeW5jKCkuIFdoZW4g dGhlIGRyaXZlcgpjaGFuZ2VzIHRoZSBzdGF0ZSB0byBvciBmcm9tIENQQ0FQX1VTQiAod2hpY2gg bWFwcyB0byBFWFRDT05fQ0hHX1VTQl9TRFApLAp0aGUgc3Vic2VxdWVudCBleHRjb25fc2V0X3N0 YXRlX3N5bmMoKSBjYWxscyBvbmx5IHRhcmdldCB0aGUgY2hhcmdlciBjYWJsZQpJRCBhbmQgaXRz IHNwZWNpZmljIG5vdGlmaWVyIGNoYWluLgoKVGhlIG5vdGlmaWVyIGNoYWluIGZvciBFWFRDT05f VVNCIG1pZ2h0IG5ldmVyIGJlIGZpcmVkLgoKPiArCj4gKwlpZiAoZGRhdGEtPmNhYmxlICE9IEVY VENPTl9OT05FKQo+ICsJCWV4dGNvbl9zZXRfc3RhdGVfc3luYyhkZGF0YS0+ZWRldiwgZGRhdGEt PmNhYmxlLCBmYWxzZSk7Cj4gKwo+ICsJaWYgKGNhYmxlICE9IEVYVENPTl9OT05FKQo+ICsJCWV4 dGNvbl9zZXRfc3RhdGVfc3luYyhkZGF0YS0+ZWRldiwgY2FibGUsIHRydWUpOwo+ICsKPiArCWRk YXRhLT5jYWJsZSA9IGNhYmxlOwo+ICt9Cj4gWyAuLi4gXQo+IEBAIC0zNTYsNiArNDExLDggQEAg c3RhdGljIHZvaWQgY3BjYXBfdXNiX2RldGVjdChzdHJ1Y3Qgd29ya19zdHJ1Y3QgKndvcmspCj4g WyAuLi4gXQo+ICAJaWYgKGRkYXRhLT5tb2RlID09IENQQ0FQX0lETEUpCj4gIAkJcmV0dXJuOwo+ ICAKPiAgCWRkYXRhLT5tb2RlID0gQ1BDQVBfSURMRTsKPiAgCWNwY2FwX3VzYl90cnlfbXVzYl9t YWlsYm94KGRkYXRhLCBNVVNCX1ZCVVNfT0ZGKTsKPiAgCj4gIAllcnJvciA9IGNwY2FwX3VzYl9z ZXRfaWRsZV9tb2RlKGRkYXRhKTsKPiAgCWlmIChlcnJvcikKPiAgCQlnb3RvIG91dF9lcnI7Cj4g IAo+ICsJY3BjYXBfdXNiX3NldF9leHRjb24oZGRhdGEpOwo+ICsKPiAgCXJldHVybjsKPiAgCj4g IG91dF9lcnI6CgpbU2V2ZXJpdHk6IE1lZGl1bV0KQ2FuIHRoZSBleHRjb24gc3RhdGUgYmVjb21l IHBlcm1hbmVudGx5IGRlc3luY2hyb25pemVkIGZyb20gdGhlIGhhcmR3YXJlIGFuZApzb2Z0d2Fy ZSBzdGF0ZSBpZiBhIHJlZ21hcCB1cGRhdGUgZmFpbHM/CgpFYXJsaWVyIGluIGNwY2FwX3VzYl9k ZXRlY3QoKSwgdGhlIGludGVybmFsIHNvZnR3YXJlIHN0YXRlIGRkYXRhLT5tb2RlIGlzCnVwZGF0 ZWQgcHJpb3IgdG8gaGFyZHdhcmUgY29uZmlndXJhdGlvbi4gSWYgdGhlIGhhcmR3YXJlIHJlZ2lz dGVyIHVwZGF0ZQpmYWlscywgdGhlIGNvZGUgYnJhbmNoZXMgdG8gb3V0X2VyciBhbmQgc2tpcHMg Y2FsbGluZwpjcGNhcF91c2Jfc2V0X2V4dGNvbigpLgoKQmVjYXVzZSBkZGF0YS0+bW9kZSBpcyBh bHJlYWR5IG1vZGlmaWVkLCBzdWJzZXF1ZW50IGV4ZWN1dGlvbnMgb2YKY3BjYXBfdXNiX2RldGVj dCgpIHdpbGwgdGFrZSB0aGUgZWFybHkgcmV0dXJuIHBhdGggYW5kIHdpbGwgbmV2ZXIgcmV0cnkK dXBkYXRpbmcgdGhlIGV4dGNvbiBzdGF0ZSwgbGVhdmluZyBpdCBzdGFsZSBpbmRlZmluaXRlbHku CgotLSAKU2FzaGlrbyBBSSByZXZpZXcgwrcgaHR0cHM6Ly9zYXNoaWtvLmRldi8jL3BhdGNoc2V0 LzIwMjYwNzA0MDczODQzLjE3NTA0NTgtMS1pdm8uZy5kaW1pdHJvdi43NUBnbWFpbC5jb20/cGFy dD01CgotLSAKbGludXgtcGh5IG1haWxpbmcgbGlzdApsaW51eC1waHlAbGlzdHMuaW5mcmFkZWFk Lm9yZwpodHRwczovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1w aHkK 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 D95E13242D4 for ; Sat, 4 Jul 2026 07:51:40 +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=1783151508; cv=none; b=diZZzVLc9RLU/g5p7x9Qdg3kSBawQA2JfIHU/+DmEiLXNVIJKVvfqZUI/xvv8LGispovp0BgQdwHc1ZHCSTemchx2LuF2pFS+xHBAnBU1JyFOeokUP/GLIP+A69Y86FgZzFjLpdFJSUzGP0sQtz17Xdvpmbz98QKJn6/SDkSqI4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783151508; c=relaxed/simple; bh=WJQPXoV4CX9FxNljrf47UReCgG1FN5PZTqN96BiaKQc=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=pmHkUDwrFQo2A7t/L7BIHqv8KeDVkSrOKpiEAGzMbLdbvq3c7JuwEqm/Ka4ml9cbFgc9iYxS0x+ig5c9UKq9RyTsxiyaiqEx0n6BZWdGjfkeDEFFf9xP11klnAx7SdkonZOqLHiS7phow4AjXkRqS7KFr2vN8GBYy90MJVSexHs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c+BDokhp; 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="c+BDokhp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0014E1F000E9; Sat, 4 Jul 2026 07:51:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783151496; bh=nk6nP7hmKCgBnsx+MNVD61Cm7aZyuBzkUCKBoY7kSj0=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=c+BDokhpWiPzgGP+7wIiERr9pI7Jx51Fed5Hpd0TFL8FVQIwTTuuSwF1aqzi3L4mf D9feTB1bOJkXweUq7zKEmTCBqLxjTNVdxmqHEYCFK6JRvHUdqHK1JFIJHme2/aKTR5 kvLrycknJl9EByuxn856hP/pDHNp1qsmDK8Z4Nrn7Gj8qmZQQAmmPpz0MHb2jQax+z VvkPN50n3bYSmSFMSgWRvp3h9Rc03p5yoEyl3lz9XR/QNJf3CXAiUo9u4UqtHH3hnm Pg2QWNX54zkRdbze2+ubfb6HRp8ExleIo7ZRBcRR8EJJngVhwbljtJgjUfomEHlfkw 0Ixhx2JocRXog== From: sashiko-bot@kernel.org Subject: Re: [PATCH 5/5] phy: cpcap-usb: add extcon support Reply-To: sashiko-reviews@lists.linux.dev To: "Ivaylo Dimitrov" Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, neil.armstrong@linaro.org, vkoul@kernel.org, linux-phy@lists.infradead.org, robh@kernel.org, olteanv@gmail.com In-Reply-To: <20260704073843.1750458-6-ivo.g.dimitrov.75@gmail.com> References: <20260704073843.1750458-1-ivo.g.dimitrov.75@gmail.com> <20260704073843.1750458-6-ivo.g.dimitrov.75@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 04 Jul 2026 07:51:35 +0000 Message-Id: <20260704075136.0014E1F000E9@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: New issues: - [High] The EXTCON_USB state is updated using `extcon_set_state` without a= corresponding `extcon_set_state_sync` or `extcon_sync`, preventing registe= red listeners from receiving state change notifications. - [Medium] Extcon state can become permanently desynchronized from the hard= ware/software state when regmap updates fail. Pre-existing issues: - [High] The driver's remove path races with the devres-managed threaded IR= Q handler, leading to a Use-After-Free of the driver data structure. -- commit 5e21d209058ee93304da0e1964b84339cf8709c2 Author: Ivaylo Dimitrov phy: cpcap-usb: add extcon support Register an Extcon device and report the detected cable state. The driver already determines the type of cable attached during USB cable detection. Export the detected state through the Extcon framework so other drivers can consume it using a standard kernel interface. > diff --git a/drivers/phy/motorola/phy-cpcap-usb.c b/drivers/phy/motorola/= phy-cpcap-usb.c > index 3be2b3afaaf4d..8978a95c1c199 100644 > --- a/drivers/phy/motorola/phy-cpcap-usb.c > +++ b/drivers/phy/motorola/phy-cpcap-usb.c > @@ -123,6 +124,7 @@ struct cpcap_phy_ddata { > struct regmap *reg; > struct device *dev; > struct usb_phy phy; > + struct extcon_dev *edev; > struct delayed_work detect_work; [Severity: High] This is a pre-existing issue, but does the remove path race with the devres-managed threaded IRQ handler, leading to a use-after-free of this driver data structure? If the devres-managed IRQ thread cpcap_phy_irq_thread() fires and reads ddata->active as 1, but is preempted before calling schedule_delayed_work(): And then the driver remove path cpcap_usb_phy_remove() executes, sets ddata->active to 0, cancels any pending work, and returns. Devres cleanup then begins, calling devm_irq_release() -> free_irq() -> synchronize_irq(), which blocks waiting for the preempted IRQ thread. When the IRQ thread resumes, it successfully queues the delayed work and returns. Once devm_irq_release() finishes, devres proceeds to free ddata. The delayed work timer expires and executes cpcap_usb_detect() on the freed ddata memory. > [ ... ] > @@ -226,6 +239,43 @@ static void cpcap_usb_try_musb_mailbox(struct cpcap_= phy_ddata *ddata, > [ ... ] > +static void cpcap_usb_set_extcon(struct cpcap_phy_ddata *ddata) > +{ > [ ... ] > + if (ddata->cable =3D=3D EXTCON_CHG_USB_SDP) > + extcon_set_state(ddata->edev, EXTCON_USB, false); > + else if (cable =3D=3D EXTCON_CHG_USB_SDP) > + extcon_set_state(ddata->edev, EXTCON_USB, true); [Severity: High] Does this prevent registered listeners from receiving state change notifications for EXTCON_USB? The EXTCON_USB state is updated here using extcon_set_state() without a corresponding extcon_set_state_sync() or extcon_sync(). When the driver changes the state to or from CPCAP_USB (which maps to EXTCON_CHG_USB_SDP), the subsequent extcon_set_state_sync() calls only target the charger cable ID and its specific notifier chain. The notifier chain for EXTCON_USB might never be fired. > + > + if (ddata->cable !=3D EXTCON_NONE) > + extcon_set_state_sync(ddata->edev, ddata->cable, false); > + > + if (cable !=3D EXTCON_NONE) > + extcon_set_state_sync(ddata->edev, cable, true); > + > + ddata->cable =3D cable; > +} > [ ... ] > @@ -356,6 +411,8 @@ static void cpcap_usb_detect(struct work_struct *work) > [ ... ] > if (ddata->mode =3D=3D CPCAP_IDLE) > return; > =20 > ddata->mode =3D CPCAP_IDLE; > cpcap_usb_try_musb_mailbox(ddata, MUSB_VBUS_OFF); > =20 > error =3D cpcap_usb_set_idle_mode(ddata); > if (error) > goto out_err; > =20 > + cpcap_usb_set_extcon(ddata); > + > return; > =20 > out_err: [Severity: Medium] Can the extcon state become permanently desynchronized from the hardware and software state if a regmap update fails? Earlier in cpcap_usb_detect(), the internal software state ddata->mode is updated prior to hardware configuration. If the hardware register update fails, the code branches to out_err and skips calling cpcap_usb_set_extcon(). Because ddata->mode is already modified, subsequent executions of cpcap_usb_detect() will take the early return path and will never retry updating the extcon state, leaving it stale indefinitely. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260704073843.1750= 458-1-ivo.g.dimitrov.75@gmail.com?part=3D5