[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aU_2VbFLPKqcyvp_@smile.fi.intel.com>
Date: Sat, 27 Dec 2025 17:08:05 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Diederik de Haas <diederik@...ow-tech.com>
Cc: Michael Wu <michael@...winnertech.com>, myungjoo.ham@...sung.com,
cw00.choi@...sung.com, linux-kernel@...r.kernel.org,
Dragan Simic <dsimic@...jaro.org>,
linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue
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.
>
> I periodically get errors like this:
>
> [ 7.116152] rockchip-usb2phy fe8a0000.usb2phy: error -EEXIST: failed to register extcon device
> [ 7.117005] rockchip-usb2phy fe8a0000.usb2phy: probe with driver rockchip-usb2phy failed with error -17
>
> 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).
>
> 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
>
> Here are 2 similar logs, this time on PineTab2 and Quartz64-A (both rk3566)
> https://paste.sr.ht/~diederik/cfe606801d3dab0267bea7049687d24c0d6e8d71
>
> 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.
>
> 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 patch
as the first we remove the struct device and all associated data (including
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.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists