From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Diederik de Haas <diederik@cknow-tech.com>
Cc: Michael Wu <michael@allwinnertech.com>,
myungjoo.ham@samsung.com, cw00.choi@samsung.com,
linux-kernel@vger.kernel.org, Dragan Simic <dsimic@manjaro.org>,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue
Date: Sun, 28 Dec 2025 19:26:13 +0200 [thread overview]
Message-ID: <aVFoNbsd13ufl7ge@smile.fi.intel.com> (raw)
In-Reply-To: <DF9SRIU7GHOX.1G7OOKX72555M@cknow-tech.com>
On Sun, Dec 28, 2025 at 12:01:54PM +0100, Diederik de Haas wrote:
> 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.
> >>
> >> 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.
>
> 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.
I believe you may speed up the test case by creating two shell scripts that
trying insmod / rmmod the same module in parallel.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Diederik de Haas <diederik@cknow-tech.com>
Cc: Michael Wu <michael@allwinnertech.com>,
myungjoo.ham@samsung.com, cw00.choi@samsung.com,
linux-kernel@vger.kernel.org, Dragan Simic <dsimic@manjaro.org>,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue
Date: Sun, 28 Dec 2025 19:26:13 +0200 [thread overview]
Message-ID: <aVFoNbsd13ufl7ge@smile.fi.intel.com> (raw)
In-Reply-To: <DF9SRIU7GHOX.1G7OOKX72555M@cknow-tech.com>
On Sun, Dec 28, 2025 at 12:01:54PM +0100, Diederik de Haas wrote:
> 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.
> >>
> >> 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.
>
> 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.
I believe you may speed up the test case by creating two shell scripts that
trying insmod / rmmod the same module in parallel.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-12-28 17:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 2:49 [PATCH v3] extcon: Fixed sysfs duplicate filename issue Michael Wu
2025-11-23 15:38 ` Chanwoo Choi
2025-12-21 14:01 ` Diederik de Haas
2025-12-21 14:01 ` Diederik de Haas
2025-12-27 15:08 ` Andy Shevchenko
2025-12-27 15:08 ` Andy Shevchenko
2025-12-28 11:01 ` Diederik de Haas
2025-12-28 11:01 ` Diederik de Haas
2025-12-28 17:26 ` Andy Shevchenko [this message]
2025-12-28 17:26 ` Andy Shevchenko
2025-12-29 23:31 ` Diederik de Haas
2025-12-29 23:31 ` Diederik de Haas
2025-12-30 11:26 ` Andy Shevchenko
2025-12-30 11:26 ` Andy Shevchenko
2025-12-30 14:24 ` Diederik de Haas
2025-12-30 14:24 ` Diederik de Haas
2026-01-02 11:38 ` Andy Shevchenko
2026-01-02 11:38 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aVFoNbsd13ufl7ge@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=cw00.choi@samsung.com \
--cc=diederik@cknow-tech.com \
--cc=dsimic@manjaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=michael@allwinnertech.com \
--cc=myungjoo.ham@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.