All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Diederik de Haas" <diederik@cknow-tech.com>
To: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"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: Tue, 30 Dec 2025 00:31:17 +0100	[thread overview]
Message-ID: <DFB3BUDFOIN1.3IM5386T534NQ@cknow-tech.com> (raw)
In-Reply-To: <aVFoNbsd13ufl7ge@smile.fi.intel.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: "Diederik de Haas" <diederik@cknow-tech.com>
To: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"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: Tue, 30 Dec 2025 00:31:17 +0100	[thread overview]
Message-ID: <DFB3BUDFOIN1.3IM5386T534NQ@cknow-tech.com> (raw)
In-Reply-To: <aVFoNbsd13ufl7ge@smile.fi.intel.com>

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

  reply	other threads:[~2025-12-29 23:31 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
2025-12-28 17:26         ` Andy Shevchenko
2025-12-29 23:31         ` Diederik de Haas [this message]
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=DFB3BUDFOIN1.3IM5386T534NQ@cknow-tech.com \
    --to=diederik@cknow-tech.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=cw00.choi@samsung.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.