From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Marco Tormento <mtormento80@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Stern <stern@rowland.harvard.edu>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: core: deattach child device from typec connector on port unbind
Date: Wed, 5 Aug 2026 13:49:54 +0200 [thread overview]
Message-ID: <anMjYmZAVA21fT8V@black.igk.intel.com> (raw)
In-Reply-To: <CACF_Uwo-hj8qpWoK8EjYVKRui2EmwHmWZ-ntS2Yd8MrTZ5Udgw@mail.gmail.com>
On Mon, Jul 27, 2026 at 06:51:36PM +0200, Marco Tormento wrote:
> Hi Heikki,
>
> On Mon, 27 Jul 2026 at 13:13, Heikki Krogerus
> <heikki.krogerus@linux.intel.com> 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@gmail.com/
>
> 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?
Right now my gut feeling is that this should be fixed in
drivers/usb/typec/class.c, but I would need to be able to study this
more carefully.
Thanks,
--
heikki
prev parent reply other threads:[~2026-08-05 11:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 20:22 [PATCH] usb: core: deattach child device from typec connector on port unbind Marco Tormento
2026-07-22 16:02 ` Heikki Krogerus
2026-07-22 16:25 ` Marco Tormento
2026-07-27 11:13 ` Heikki Krogerus
2026-07-27 16:51 ` Marco Tormento
2026-08-05 11:49 ` Heikki Krogerus [this message]
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=anMjYmZAVA21fT8V@black.igk.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mtormento80@gmail.com \
--cc=stern@rowland.harvard.edu \
/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.