public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Cc: linux-usb@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kernel-dev@igalia.com
Subject: Re: [PATCH] usb: typec: altmode should keep reference to parent
Date: Mon, 7 Oct 2024 11:33:09 +0300	[thread overview]
Message-ID: <ZwOcxWOftFJxpMbo@kuha.fi.intel.com> (raw)
In-Reply-To: <Zv/43ewc3n5aSEUO@quatroqueijos.cascardo.eti.br>

Hi,

On Fri, Oct 04, 2024 at 11:17:01AM -0300, Thadeu Lima de Souza Cascardo wrote:
> On Fri, Oct 04, 2024 at 05:08:28PM +0300, Heikki Krogerus wrote:
> > On Fri, Oct 04, 2024 at 09:37:38AM -0300, Thadeu Lima de Souza Cascardo wrote:
> > > The altmode device release refers to its parent device, but without keeping
> > > a reference to it.
> > > 
> > > When registering the altmode, get a reference to the parent and put it in
> > > the release function.
> > > 
> > > Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues
> > > like this:
> > 
> > Let me study what's going on in the drivers code. The children should
> > _not_ be cleaned first before the parent. I'll have to come back to
> > this on Monday.
> > 
> > This really should not be necessary.
> > 
> 
> Well, they are likely not. But driver core API states that either way, you
> should keep such references. And one way to test it is using
> CONFIG_DEBUG_KOBJECT_RELEASE. That delays the actual release/cleanup of the
> struct device, so:

What I want to understand is, what is the rationale for this behaviour
in the core. If this is something that the drivers can do, then why is
the core not doing it for everything? Why is the core decrementing the
parent reference count already in device_del() instead of
device_release()?

I'm probable missing something, but I really want to understand this.
There are other drivers also need resources from their parent, so if
there is nothing preventing this from being handled in the core, then
that's where it really should be handled.

thanks,

-- 
heikki

  parent reply	other threads:[~2024-10-07  8:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04 12:37 [PATCH] usb: typec: altmode should keep reference to parent Thadeu Lima de Souza Cascardo
2024-10-04 14:08 ` Heikki Krogerus
2024-10-04 14:17   ` Thadeu Lima de Souza Cascardo
2024-10-06 15:24     ` Dmitry Baryshkov
2024-10-07  8:33     ` Heikki Krogerus [this message]
2024-10-07 13:59       ` Thadeu Lima de Souza Cascardo
2024-10-07 11:07 ` Heikki Krogerus
2024-10-07 13:42   ` Thadeu Lima de Souza Cascardo

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=ZwOcxWOftFJxpMbo@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=cascardo@igalia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-dev@igalia.com \
    --cc=linux-usb@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox