Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

[Diederik de Haas]

Hi,

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?

Most of my kernel modules are ``=m`` which is possibly a factor. And
because of that, -EPROBE_DEFER probably happens several times.
Dunno if that's relevant, but figured I'd mention it.

Cheers,
  Diederik

> The right timing shows below:
> on extcon_dev_register: ida_alloc() -> device_register()
> on extcon_dev_unregister: device_unregister() -> ida_free()
>
> stack information when an error occurs:
> sysfs: cannot create duplicate filename '/class/extcon/extcon1'
> Call trace:
>  sysfs_warn_dup+0x68/0x88
>  sysfs_do_create_link_sd+0x94/0xdc
>  sysfs_create_link+0x30/0x48
>  device_add_class_symlinks+0xb4/0x12c
>  device_add+0x1e0/0x48c
>  device_register+0x20/0x34
>  extcon_dev_register+0x3b8/0x5c4
>
> Fixes: 7bba9e81a6fb ("extcon: Use unique number for the extcon device ID")
> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Michael Wu <michael@allwinnertech.com>
> ---
> ChangeLog:
> V2 -> V3: Dropped some noisy lines in commit messages, suggested by Andy Shevchenko
> V1 -> V2: Update commit msg, suggested by Markus Elfring
> V1: https://lore.kernel.org/all/20251011053719.87055-1-michael@allwinnertech.com/
> ---
> ---
>  drivers/extcon/extcon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index e7f55c021e562..c08f642d7f5ee 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -1371,10 +1371,10 @@ void extcon_dev_unregister(struct extcon_dev *edev)
>  		return;
>  	}
>  
> -	ida_free(&extcon_dev_ids, edev->id);
> -
>  	device_unregister(&edev->dev);
>  
> +	ida_free(&extcon_dev_ids, edev->id);
> +
>  	if (edev->mutually_exclusive && edev->max_supported) {
>  		for (index = 0; edev->mutually_exclusive[index];
>  				index++)


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

[Andy Shevchenko]

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



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

[Diederik de Haas]

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.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

[Andy Shevchenko]

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

Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

[Diederik de Haas]

On Sun Dec 28, 2025 at 6:26 PM CET, Andy Shevchenko wrote:
> 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.

I checked on several devices and the phy_rockchip_inno_usb2 module is
used by various other modules on all of them, so I can't just 'rmmod' it.
I guess it should technically be possible to remove all its dependencies
and then remove that module. I don't know if my skills are sufficient
for that and it feels like I'm mostly testing the robustness of the USB
subsystem.

As I regularly already get the following kernel warning
``Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after``
which often results in USB 2 ports not working, I have my doubts about
the robustness anyway.

So I'll just keep an eye out if the ``sysfs: cannot create duplicate
filename`` error pops up again 'naturally' and report if/when it does.

Cheers,
  Diederik

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

[Andy Shevchenko]

On Tue, Dec 30, 2025 at 12:31:17AM +0100, Diederik de Haas wrote:
> On Sun Dec 28, 2025 at 6:26 PM CET, Andy Shevchenko wrote:
> > 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.
> 
> I checked on several devices and the phy_rockchip_inno_usb2 module is
> used by various other modules on all of them, so I can't just 'rmmod' it.
> I guess it should technically be possible to remove all its dependencies
> and then remove that module. I don't know if my skills are sufficient
> for that and it feels like I'm mostly testing the robustness of the USB
> subsystem.
> 
> As I regularly already get the following kernel warning
> ``Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after``
> which often results in USB 2 ports not working, I have my doubts about
> the robustness anyway.

This is interesting issue, have you reported it to USB people (such as Alan Stern)?

> So I'll just keep an eye out if the ``sysfs: cannot create duplicate
> filename`` error pops up again 'naturally' and report if/when it does.

Good, please monitor it and try to collect logs for the further investigations,
if required.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

[Diederik de Haas]

On Tue Dec 30, 2025 at 12:26 PM CET, Andy Shevchenko wrote:
> On Tue, Dec 30, 2025 at 12:31:17AM +0100, Diederik de Haas wrote:
>> On Sun Dec 28, 2025 at 6:26 PM CET, Andy Shevchenko wrote:
>> > 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.
>> 
>> I checked on several devices and the phy_rockchip_inno_usb2 module is
>> used by various other modules on all of them, so I can't just 'rmmod' it.
>> I guess it should technically be possible to remove all its dependencies
>> and then remove that module. I don't know if my skills are sufficient
>> for that and it feels like I'm mostly testing the robustness of the USB
>> subsystem.
>> 
>> As I regularly already get the following kernel warning
>> ``Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after``
>> which often results in USB 2 ports not working, I have my doubts about
>> the robustness anyway.
>
> This is interesting issue, have you reported it to USB people (such as Alan Stern)?

Not yet. I was reasonably sure I had mentioned this issue before, but
when doing a search on lore.k.o I couldn't find it. I guess I only
'reported' it on IRC.

Interestingly enough, I did find another very recent mail/patch:
https://lore.kernel.org/all/20251230080014.3934590-1-chenhuacai@loongson.cn/

but looks like Greg doesn't like it ... and his suggestion (make the
kernel module built-in) was exactly the thing I wanted to try before
reporting it. If it's tristate it _should_ be able to be built as
module, but it's extremely unlikely I'll spend time on that though.

>> So I'll just keep an eye out if the ``sysfs: cannot create duplicate
>> filename`` error pops up again 'naturally' and report if/when it does.
>
> Good, please monitor it and try to collect logs for the further investigations,
> if required.

Will do. FWIW, Dragan asked me to enable DEBUG_DEVRES and share the
logs. Maybe they're useful for you too.
On Rock 5B (RK3588): https://paste.sr.ht/~diederik/2d8e0beced6477cc1abd28cd870ea76a1e413a9e
On NanoPi R5S (RK3568): https://paste.sr.ht/~diederik/1c4026d0c277b92391136bab4e80f64a989006f5

Cheers,
  Diederik

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v3] extcon: Fixed sysfs duplicate filename issue

[Andy Shevchenko]

On Tue, Dec 30, 2025 at 03:24:36PM +0100, Diederik de Haas wrote:
> On Tue Dec 30, 2025 at 12:26 PM CET, Andy Shevchenko wrote:
> > On Tue, Dec 30, 2025 at 12:31:17AM +0100, Diederik de Haas wrote:
> >> On Sun Dec 28, 2025 at 6:26 PM CET, Andy Shevchenko wrote:
> >> > 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.
> >> 
> >> I checked on several devices and the phy_rockchip_inno_usb2 module is
> >> used by various other modules on all of them, so I can't just 'rmmod' it.
> >> I guess it should technically be possible to remove all its dependencies
> >> and then remove that module. I don't know if my skills are sufficient
> >> for that and it feels like I'm mostly testing the robustness of the USB
> >> subsystem.
> >> 
> >> As I regularly already get the following kernel warning
> >> ``Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after``
> >> which often results in USB 2 ports not working, I have my doubts about
> >> the robustness anyway.
> >
> > This is interesting issue, have you reported it to USB people (such as Alan Stern)?
> 
> Not yet. I was reasonably sure I had mentioned this issue before, but
> when doing a search on lore.k.o I couldn't find it. I guess I only
> 'reported' it on IRC.
> 
> Interestingly enough, I did find another very recent mail/patch:
> https://lore.kernel.org/all/20251230080014.3934590-1-chenhuacai@loongson.cn/
> 
> but looks like Greg doesn't like it ... and his suggestion (make the
> kernel module built-in) was exactly the thing I wanted to try before
> reporting it. If it's tristate it _should_ be able to be built as
> module, but it's extremely unlikely I'll spend time on that though.

Okay, it seems you engaged Alan into the discussion, so I leave it to that
thread where all necessary stakeholders are present.

> >> So I'll just keep an eye out if the ``sysfs: cannot create duplicate
> >> filename`` error pops up again 'naturally' and report if/when it does.
> >
> > Good, please monitor it and try to collect logs for the further investigations,
> > if required.
> 
> Will do. FWIW, Dragan asked me to enable DEBUG_DEVRES and share the
> logs. Maybe they're useful for you too.
> On Rock 5B (RK3588): https://paste.sr.ht/~diederik/2d8e0beced6477cc1abd28cd870ea76a1e413a9e
> On NanoPi R5S (RK3568): https://paste.sr.ht/~diederik/1c4026d0c277b92391136bab4e80f64a989006f5

I don't see any smoking gun there.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip