From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) (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 52DAC1FC7 for ; Sun, 28 Dec 2025 11:02:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766919727; cv=none; b=S/ooyWJ9ViKmbT6qUnj5sMIjUYaO4t0hm3jooKcE8tqyKcXlQRVyFudmB3ESVUUMPG/mJl2d+/+J/O72Rz0HXSMEgtLYh5bxGX7lrBwNqjoR4c2qD9CkFkUw8zR3XwEmAg85ozu8FIRF4QxO2ZMRwO1b50mIKJXI72r8Rt4rHlM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766919727; c=relaxed/simple; bh=crJbFJQegcgLdar0nqyoCZq/Z6ptGQSxFA0GdVq/Hxo=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=kmdR+lolPTsSVg3zojzCn4qJypurct21sMyS3HynMhGK4vFzRRoVOKH+2HtsNpUa+O1S/prhbb/fa6Ob4Bi6SQlsu5tXjOUUuWKKbCc8tI/ar1clIWZQ659gNTEk0DYO7uBX6VTWMAL7Qcxzu3W1dKHq56ob0LsFweaW8GYj3ew= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=cknow-tech.com; spf=pass smtp.mailfrom=cknow-tech.com; dkim=pass (2048-bit key) header.d=cknow-tech.com header.i=@cknow-tech.com header.b=c8NdSiEa; arc=none smtp.client-ip=95.215.58.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=cknow-tech.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cknow-tech.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cknow-tech.com header.i=@cknow-tech.com header.b="c8NdSiEa" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cknow-tech.com; s=key1; t=1766919721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ORPbeGCezq2RycIES2ovg1z4YfgPj7odDnKIXufBjpA=; b=c8NdSiEaF6lKUnk0ll/c64CeXpwq2rdYQK8WhTMFD1ZY02PdKPsERv1eEGAZ5mJnec54aT WUb+8WrmhF+ukFgwkQ/JJs6/92iJM5j9AheOxZeLnVZW6G5lJtr7p0gP58/KYMZq7RQG7B 2bOjtL7LWKS33Qd9YBkk56VsGZqzg+KCQ3kNZzKiERrJXt3hdebhvCXfi+0ML0+fLllAud t7EGNnmGP7+KzbTiaI0l6Y9DaBnr5ROy3MljS5v/YhAJfeAjOvJQ57sz5dg8LUAT/h6juy wkA4+BnRqAVhB3cZHQSl0e4cMNb1hfgFDOJOnQ3mCTDmmuYRS1Q+9j8wC2Lw9g== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sun, 28 Dec 2025 12:01:54 +0100 Message-Id: Cc: "Michael Wu" , , , , "Dragan Simic" , Subject: Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Diederik de Haas" To: "Andy Shevchenko" , "Diederik de Haas" References: <20251024024946.16618-1-michael@allwinnertech.com> In-Reply-To: X-Migadu-Flow: FLOW_OUT On Sat Dec 27, 2025 at 4:08 PM CET, Andy Shevchenko wrote: > On Sun, Dec 21, 2025 at 03:01:11PM +0100, Diederik de Haas wrote: >> On Fri Oct 24, 2025 at 4:49 AM CEST, Michael Wu wrote: >> > With current extcon_dev_unregister() timing, ida_free is before >> > device_unregister(), that may cause current id re-alloc to another >> > device in extcon_dev_register() context but sysfs filename path not >> > removal completed yet. >>=20 >> I periodically get errors like this: >>=20 >> [ 7.116152] rockchip-usb2phy fe8a0000.usb2phy: error -EEXIST: failed = to register extcon device >> [ 7.117005] rockchip-usb2phy fe8a0000.usb2phy: probe with driver rock= chip-usb2phy failed with error -17 >>=20 >> This was today on a NanoPi R5S (rk3568), but I have seen it before and >> on multiple devices. They are all Rockchip based, but that's (quite) >> possible because that's what I use the most (and where I pay quite a bit >> of attention to dmesg). >>=20 >> Slightly fuller dmesg output of the above error is here: >> https://paste.sr.ht/~diederik/42c6b3405386c823cd9f837d73a9a32e810361be >> And via 'journalctl' I hopefully got the full dmesg output: >> https://paste.sr.ht/~diederik/7a6109115b1ad85290de482db091dad3759ec159 >>=20 >> Here are 2 similar logs, this time on PineTab2 and Quartz64-A (both rk35= 66) >> https://paste.sr.ht/~diederik/cfe606801d3dab0267bea7049687d24c0d6e8d71 >>=20 >> Those are all the logs I have saved, but it has happened several times >> besides that. But most times I just rebooted and didn't save the log. >> Today I looked a bit further, found commit 7bba9e81a6fb, searched on >> lore.k.o and found this patch. >>=20 >> So I'm wondering whether this patch would also fix 'my' issue? >> Or is this a different issue? > > But have you had a chance to test it? The code looks correct after this p= atch > as the first we remove the struct device and all associated data (includi= ng > sysfs nodes) and then remove the ID from the list. Without that there is = a > window to get the same id for the devices that is pending to be removed. I've build a kernel with it and it will be part of my kernels going forward. But it can take many months before the issue shows up again. So if I don't get it in a year, then I'm going to *assume* it's probably fixed.