Re: [PATCH] usb: core: deattach child device from typec connector on port unbind
From: Marco Tormento
Date: Mon Jul 27 2026 - 13:11:24 EST
Hi Heikki,
On Mon, 27 Jul 2026 at 13:13, Heikki Krogerus
<heikki.krogerus@xxxxxxxxxxxxxxx> wrote:
>
> We should not need to reverse anything. We can't avoid calling
> typec_attach() separately from connector_bind() because we can't
> prevent USB devices from being enumerated before the typec drivers are
> loaded for example during bootup. But that does not mean we need to
> call typec_deattach() in connector_unbind().
>
> After the USB device is "attached" to the typec connector, the
> connector device should be pinned down for as long as the USB device
> exists, but that is not happening. So what both you guys are doing, is
> working around a problem with the reference count.
>
> I can see that most of your commit message is written by some LLM, and
> the parts that you've added don't usually belong to the commit
> message. That makes me a bit concerned about how much you actually
> understand what the code that you are modifying does.
>
> Use of LLMs is fine, but you still have understand the code that you
> modify.
First of all, thank you for the explanation.
The commit message definitely sounded over confident, my understanding
of the issue is summed up here in my first patch submission a year
ago: https://lore.kernel.org/all/20250720210847.30998-1-mtormento80@xxxxxxxxx/
As I said back then, my experience on kernel code was nearly zero, and
I was well aware there might be better ways to fix the issue: that's
also true today.
What I did a few days ago was to ask AI to analyse my first patch and
see if it could find a better mitigation.
It came up with this patch, I read the explanation and it made sense
for my level of understanding of the matter (which is arguably low,
unfortunately).
I checked the code and tested for a while with success, so I submitted
a new patch and here we are.
Do you have any suspects yet on where the underlying issue might be?
Regards,
Marco