All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: Saravana Kannan <saravanak@google.com>, Nuno Sa <nuno.sa@analog.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Lizhi Hou <lizhi.hou@amd.com>, Max Zhen <max.zhen@amd.com>,
	Sonal Santan <sonal.santan@amd.com>,
	Stefano Stabellini <stefano.stabellini@xilinx.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Allan Nielsen <allan.nielsen@microchip.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Steen Hegelund <steen.hegelund@microchip.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH 2/2] of: overlay: Synchronize of_overlay_remove() with the devlink removals
Date: Fri, 23 Feb 2024 10:45:50 +0100	[thread overview]
Message-ID: <20240223104550.234ecdcb@bootlin.com> (raw)
In-Reply-To: <CAGETcx_zB95nyTpi-_kYW_VqnPqMEc8mS9sewSwRNVr0x=7+kA@mail.gmail.com>

Hi Saravana, Nuno, 

On Tue, 20 Feb 2024 16:37:05 -0800
Saravana Kannan <saravanak@google.com> wrote:

...
> > @@ -1202,6 +1202,12 @@ int of_overlay_remove(int *ovcs_id)
> >                 goto out;
> >         }
> >
> > +       /*
> > +        * Wait for any ongoing device link removals before removing some of
> > +        * nodes
> > +        */
> > +       device_link_wait_removal();
> > +  
> 
> Nuno in his patch[1] had this "wait" happen inside
> __of_changeset_entry_destroy(). Which seems to be necessary to not hit
> the issue that Luca reported[2] in this patch series. Is there any
> problem with doing that?

Is it the right place to wait ?

__of_changeset_entry_destroy() can do some of_node_put() and I am not sure
that of_node_put() can call device_put() when the of_node refcount reachs
zero.

If of_node_put() cannot call device_put(), I think we can wait in the
of_changeset_destroy(). I.e. the __of_changeset_entry_destroy() caller.
  https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/of/dynamic.c#L670

What do you think about this ?
Does it make sense ?

> 
> Luca for some reason did a unlock/lock(of_mutex) in his test patch and
> I don't think that's necessary.
> 
> Can you move this call to where Nuno did it and see if that works for
> all of you?

I will check.

Best regards,
Hervé

  parent reply	other threads:[~2024-02-23  9:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-30 17:41 [PATCH 0/2] Synchronize DT overlay removal with devlink removals Herve Codina
2023-11-30 17:41 ` [PATCH 1/2] driver core: Introduce device_link_wait_removal() Herve Codina
2024-02-21  0:31   ` Saravana Kannan
2024-02-21  6:56     ` Nuno Sá
2024-02-23  1:08       ` Saravana Kannan
2024-02-23  8:13         ` Nuno Sá
2024-02-23  8:46         ` Herve Codina
2024-02-23  8:56           ` Nuno Sá
2024-02-23  9:11     ` Herve Codina
2024-02-23 10:45       ` Nuno Sá
2024-02-29 23:26         ` Saravana Kannan
2024-03-01  7:14           ` Nuno Sá
2023-11-30 17:41 ` [PATCH 2/2] of: overlay: Synchronize of_overlay_remove() with the devlink removals Herve Codina
2024-02-21  0:37   ` Saravana Kannan
2024-02-21  7:03     ` Nuno Sá
2024-02-23  9:45     ` Herve Codina [this message]
2024-02-23 10:35       ` Nuno Sá
2024-02-27 15:24     ` Herve Codina
2024-02-27 16:55       ` Nuno Sá
2024-02-27 17:54         ` Herve Codina
2024-02-27 19:07           ` Nuno Sá
2024-02-27 19:13             ` Rafael J. Wysocki
2024-02-27 19:28               ` Nuno Sá
2023-12-06 17:15 ` [PATCH 0/2] Synchronize DT overlay removal with " Rob Herring
2023-12-07  3:09   ` Saravana Kannan
2023-12-20 17:16     ` Luca Ceresoli
2023-12-20 18:12       ` Herve Codina
2024-02-21  0:19     ` Saravana Kannan

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=20240223104550.234ecdcb@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=allan.nielsen@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=horatiu.vultur@microchip.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizhi.hou@amd.com \
    --cc=luca.ceresoli@bootlin.com \
    --cc=max.zhen@amd.com \
    --cc=nuno.sa@analog.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --cc=sonal.santan@amd.com \
    --cc=steen.hegelund@microchip.com \
    --cc=stefano.stabellini@xilinx.com \
    --cc=thomas.petazzoni@bootlin.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.