All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Sudeep Holla" <sudeep.holla@arm.com>,
	"Cristian Marussi" <cristian.marussi@arm.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Marc Zyngier" <maz@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	"NXP Linux Team" <linux-imx@nxp.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Daniel Scally" <djrscally@gmail.com>,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Len Brown" <lenb@kernel.org>, "Rafał Miłecki" <rafal@milecki.pl>,
	"Abel Vesa" <abel.vesa@linaro.org>,
	"Alexander Stein" <alexander.stein@ew.tq-group.com>,
	"Tony Lindgren" <tony@atomide.com>,
	"John Stultz" <jstultz@google.com>,
	"Doug Anderson" <dianders@chromium.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
	"Maxim Kiselev" <bigunclemax@gmail.com>,
	"Maxim Kochetkov" <fido_max@inbox.ru>,
	"Luca Weiss" <luca.weiss@fairphone.com>,
	"Colin Foster" <colin.foster@in-advantage.com>,
	"Martin Kepplinger" <martin.kepplinger@puri.sm>,
	"Jean-Philippe Brucker" <jpb@kernel.org>,
	"Vladimir Oltean" <vladimir.oltean@nxp.com>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
	linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v3 09/12] of: property: Simplify of_link_to_phandle()
Date: Tue, 7 Feb 2023 18:08:00 -0800	[thread overview]
Message-ID: <CAGETcx8DaZqS7+47PhX4hQOfSk7AzPcTu=2i+4gAgXr6wyDNgg@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com>

On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote:
> > The driver core now:
> > - Has the parent device of a supplier pick up the consumers if the
> >   supplier never has a device created for it.
> > - Ignores a supplier if the supplier has no parent device and will never
> >   be probed by a driver
> >
> > And already prevents creating a device link with the consumer as a
> > supplier of a parent.
> >
> > So, we no longer need to find the "compatible" node of the supplier or
> > do any other checks in of_link_to_phandle(). We simply need to make sure
> > that the supplier is available in DT.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> Thanks for your patch!
>
> This patch introduces a regression when dynamically loading DT overlays.
> Unfortunately this happens when using the out-of-tree OF configfs,
> which is not supported upstream.  Still, there may be (obscure)
> in-tree users.
>
> When loading a DT overlay[1] to enable an SPI controller, and
> instantiate a connected SPI EEPROM:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>
> The SPI controller and the SPI EEPROM are no longer instantiated.
>
>     # cat /sys/kernel/debug/devices_deferred
>     e6e90000.spi    platform: wait for supplier msiof0
>
> Let's remove the overlay again:
>
>     $ overlay rm 25lc040
>     input: keys as /devices/platform/keys/input/input1
>
> And retry:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>     spi_sh_msiof e6e90000.spi: DMA available
>     spi_sh_msiof e6e90000.spi: registered master spi0
>     spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0
>     at25 spi0.0: 512 Byte at25 eeprom, pagesize 16
>     spi_sh_msiof e6e90000.spi: registered child spi0.0
>
> Now it succeeds, and the SPI EEPROM is available, and works.
>
> Without this patch, or with this patch reverted after applying the
> full series:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>     OF: Not linking spi@e6e90000 to interrupt-controller@f1010000 - No
> struct device
>     spi_sh_msiof e6e90000.spi: DMA available
>     spi_sh_msiof e6e90000.spi: registered master spi0
>     spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0
>     at25 spi0.0: 444 bps (2 bytes in 9 ticks)
>     at25 spi0.0: 512 Byte at25 eeprom, pagesize 16
>     spi_sh_msiof e6e90000.spi: registered child spi0.0
>
> The SPI EEPROM is available on the first try after boot.

Sigh... I spent way too long trying to figure out if I caused a memory
leak. I should have scrolled down further! Doesn't look like that part
is related to anything I did.

There are some flags set to avoid re-parsing fwnodes multiple times.
My guess is that the issue you are seeing has to do with how many of
the in memory structs are reused vs not when an overlay is
applied/removed and some of these flags might not be getting cleared
and this is having a bigger impact with this patch (because the fwnode
links are no longer anchored on "compatible" nodes).

With/without this patch (let's keep the series) can you look at how
the following things change between each step you do above (add,
remove, retry):
1) List of directories under /sys/class/devlink
2) Enable the debug logs inside __fwnode_link_add(),
__fwnode_link_del(), device_link_add()

My guess is that the final solution would entail clearing
FWNODE_FLAG_LINKS_ADDED for some fwnodes.

Thanks,
Saravana

WARNING: multiple messages have this Message-ID (diff)
From: Saravana Kannan <saravanak@google.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Sudeep Holla" <sudeep.holla@arm.com>,
	"Cristian Marussi" <cristian.marussi@arm.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Marc Zyngier" <maz@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	"NXP Linux Team" <linux-imx@nxp.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Daniel Scally" <djrscally@gmail.com>,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Len Brown" <lenb@kernel.org>, "Rafał Miłecki" <rafal@milecki.pl>,
	"Abel Vesa" <abel.vesa@linaro.org>,
	"Alexander Stein" <alexander.stein@ew.tq-group.com>,
	"Tony Lindgren" <tony@atomide.com>,
	"John Stultz" <jstultz@google.com>,
	"Doug Anderson" <dianders@chromium.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
	"Maxim Kiselev" <bigunclemax@gmail.com>,
	"Maxim Kochetkov" <fido_max@inbox.ru>,
	"Luca Weiss" <luca.weiss@fairphone.com>,
	"Colin Foster" <colin.foster@in-advantage.com>,
	"Martin Kepplinger" <martin.kepplinger@puri.sm>,
	"Jean-Philippe Brucker" <jpb@kernel.org>,
	"Vladimir Oltean" <vladimir.oltean@nxp.com>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
	linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v3 09/12] of: property: Simplify of_link_to_phandle()
Date: Tue, 7 Feb 2023 18:08:00 -0800	[thread overview]
Message-ID: <CAGETcx8DaZqS7+47PhX4hQOfSk7AzPcTu=2i+4gAgXr6wyDNgg@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com>

On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote:
> > The driver core now:
> > - Has the parent device of a supplier pick up the consumers if the
> >   supplier never has a device created for it.
> > - Ignores a supplier if the supplier has no parent device and will never
> >   be probed by a driver
> >
> > And already prevents creating a device link with the consumer as a
> > supplier of a parent.
> >
> > So, we no longer need to find the "compatible" node of the supplier or
> > do any other checks in of_link_to_phandle(). We simply need to make sure
> > that the supplier is available in DT.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> Thanks for your patch!
>
> This patch introduces a regression when dynamically loading DT overlays.
> Unfortunately this happens when using the out-of-tree OF configfs,
> which is not supported upstream.  Still, there may be (obscure)
> in-tree users.
>
> When loading a DT overlay[1] to enable an SPI controller, and
> instantiate a connected SPI EEPROM:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>
> The SPI controller and the SPI EEPROM are no longer instantiated.
>
>     # cat /sys/kernel/debug/devices_deferred
>     e6e90000.spi    platform: wait for supplier msiof0
>
> Let's remove the overlay again:
>
>     $ overlay rm 25lc040
>     input: keys as /devices/platform/keys/input/input1
>
> And retry:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>     spi_sh_msiof e6e90000.spi: DMA available
>     spi_sh_msiof e6e90000.spi: registered master spi0
>     spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0
>     at25 spi0.0: 512 Byte at25 eeprom, pagesize 16
>     spi_sh_msiof e6e90000.spi: registered child spi0.0
>
> Now it succeeds, and the SPI EEPROM is available, and works.
>
> Without this patch, or with this patch reverted after applying the
> full series:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>     OF: Not linking spi@e6e90000 to interrupt-controller@f1010000 - No
> struct device
>     spi_sh_msiof e6e90000.spi: DMA available
>     spi_sh_msiof e6e90000.spi: registered master spi0
>     spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0
>     at25 spi0.0: 444 bps (2 bytes in 9 ticks)
>     at25 spi0.0: 512 Byte at25 eeprom, pagesize 16
>     spi_sh_msiof e6e90000.spi: registered child spi0.0
>
> The SPI EEPROM is available on the first try after boot.

Sigh... I spent way too long trying to figure out if I caused a memory
leak. I should have scrolled down further! Doesn't look like that part
is related to anything I did.

There are some flags set to avoid re-parsing fwnodes multiple times.
My guess is that the issue you are seeing has to do with how many of
the in memory structs are reused vs not when an overlay is
applied/removed and some of these flags might not be getting cleared
and this is having a bigger impact with this patch (because the fwnode
links are no longer anchored on "compatible" nodes).

With/without this patch (let's keep the series) can you look at how
the following things change between each step you do above (add,
remove, retry):
1) List of directories under /sys/class/devlink
2) Enable the debug logs inside __fwnode_link_add(),
__fwnode_link_del(), device_link_add()

My guess is that the final solution would entail clearing
FWNODE_FLAG_LINKS_ADDED for some fwnodes.

Thanks,
Saravana

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Saravana Kannan <saravanak@google.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Sudeep Holla" <sudeep.holla@arm.com>,
	"Cristian Marussi" <cristian.marussi@arm.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Marc Zyngier" <maz@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	"NXP Linux Team" <linux-imx@nxp.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Daniel Scally" <djrscally@gmail.com>,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Len Brown" <lenb@kernel.org>, "Rafał Miłecki" <rafal@milecki.pl>,
	"Abel Vesa" <abel.vesa@linaro.org>,
	"Alexander Stein" <alexander.stein@ew.tq-group.com>,
	"Tony Lindgren" <tony@atomide.com>,
	"John Stultz" <jstultz@google.com>,
	"Doug Anderson" <dianders@chromium.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
	"Maxim Kiselev" <bigunclemax@gmail.com>,
	"Maxim Kochetkov" <fido_max@inbox.ru>,
	"Luca Weiss" <luca.weiss@fairphone.com>,
	"Colin Foster" <colin.foster@in-advantage.com>,
	"Martin Kepplinger" <martin.kepplinger@puri.sm>,
	"Jean-Philippe Brucker" <jpb@kernel.org>,
	"Vladimir Oltean" <vladimir.oltean@nxp.com>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
	linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v3 09/12] of: property: Simplify of_link_to_phandle()
Date: Tue, 7 Feb 2023 18:08:00 -0800	[thread overview]
Message-ID: <CAGETcx8DaZqS7+47PhX4hQOfSk7AzPcTu=2i+4gAgXr6wyDNgg@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com>

On Tue, Feb 7, 2023 at 12:57 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Tue, Feb 7, 2023 at 2:42 AM Saravana Kannan <saravanak@google.com> wrote:
> > The driver core now:
> > - Has the parent device of a supplier pick up the consumers if the
> >   supplier never has a device created for it.
> > - Ignores a supplier if the supplier has no parent device and will never
> >   be probed by a driver
> >
> > And already prevents creating a device link with the consumer as a
> > supplier of a parent.
> >
> > So, we no longer need to find the "compatible" node of the supplier or
> > do any other checks in of_link_to_phandle(). We simply need to make sure
> > that the supplier is available in DT.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> Thanks for your patch!
>
> This patch introduces a regression when dynamically loading DT overlays.
> Unfortunately this happens when using the out-of-tree OF configfs,
> which is not supported upstream.  Still, there may be (obscure)
> in-tree users.
>
> When loading a DT overlay[1] to enable an SPI controller, and
> instantiate a connected SPI EEPROM:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>
> The SPI controller and the SPI EEPROM are no longer instantiated.
>
>     # cat /sys/kernel/debug/devices_deferred
>     e6e90000.spi    platform: wait for supplier msiof0
>
> Let's remove the overlay again:
>
>     $ overlay rm 25lc040
>     input: keys as /devices/platform/keys/input/input1
>
> And retry:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>     spi_sh_msiof e6e90000.spi: DMA available
>     spi_sh_msiof e6e90000.spi: registered master spi0
>     spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0
>     at25 spi0.0: 512 Byte at25 eeprom, pagesize 16
>     spi_sh_msiof e6e90000.spi: registered child spi0.0
>
> Now it succeeds, and the SPI EEPROM is available, and works.
>
> Without this patch, or with this patch reverted after applying the
> full series:
>
>     $ overlay add 25lc040
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /keys/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-0
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/pinctrl-names
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/cs-gpios
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /soc/spi@e6e90000/status
>     OF: overlay: WARNING: memory leak will occur if overlay removed,
> property: /__symbols__/msiof0_pins
>     OF: Not linking spi@e6e90000 to interrupt-controller@f1010000 - No
> struct device
>     spi_sh_msiof e6e90000.spi: DMA available
>     spi_sh_msiof e6e90000.spi: registered master spi0
>     spi spi0.0: setup mode 0, 8 bits/w, 100000 Hz max --> 0
>     at25 spi0.0: 444 bps (2 bytes in 9 ticks)
>     at25 spi0.0: 512 Byte at25 eeprom, pagesize 16
>     spi_sh_msiof e6e90000.spi: registered child spi0.0
>
> The SPI EEPROM is available on the first try after boot.

Sigh... I spent way too long trying to figure out if I caused a memory
leak. I should have scrolled down further! Doesn't look like that part
is related to anything I did.

There are some flags set to avoid re-parsing fwnodes multiple times.
My guess is that the issue you are seeing has to do with how many of
the in memory structs are reused vs not when an overlay is
applied/removed and some of these flags might not be getting cleared
and this is having a bigger impact with this patch (because the fwnode
links are no longer anchored on "compatible" nodes).

With/without this patch (let's keep the series) can you look at how
the following things change between each step you do above (add,
remove, retry):
1) List of directories under /sys/class/devlink
2) Enable the debug logs inside __fwnode_link_add(),
__fwnode_link_del(), device_link_add()

My guess is that the final solution would entail clearing
FWNODE_FLAG_LINKS_ADDED for some fwnodes.

Thanks,
Saravana

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-02-08  2:08 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07  1:41 [PATCH v3 00/12] fw_devlink improvements Saravana Kannan
2023-02-07  1:41 ` Saravana Kannan
2023-02-07  1:41 ` [PATCH v3 01/12] driver core: fw_devlink: Don't purge child fwnode's consumer links Saravana Kannan
2023-02-07  1:41   ` Saravana Kannan
2023-02-07  1:41 ` [PATCH v3 02/12] driver core: fw_devlink: Improve check for fwnode with no device/driver Saravana Kannan
2023-02-07  1:41   ` Saravana Kannan
2023-02-07  1:41 ` [PATCH v3 03/12] soc: renesas: Move away from using OF_POPULATED for fw_devlink Saravana Kannan
2023-02-07  1:41   ` Saravana Kannan
2023-02-07  7:56   ` Geert Uytterhoeven
2023-02-07  7:56     ` Geert Uytterhoeven
2023-02-07  7:56     ` Geert Uytterhoeven
2023-02-07  1:41 ` [PATCH v3 04/12] gpiolib: Clear the gpio_device's fwnode initialized flag before adding Saravana Kannan
2023-02-07  1:41   ` Saravana Kannan
2023-02-07 10:20   ` Andy Shevchenko
2023-02-07 10:20     ` Andy Shevchenko
2023-02-07 10:20     ` Andy Shevchenko
2023-02-07 10:28     ` Andy Shevchenko
2023-02-07 10:28       ` Andy Shevchenko
2023-02-07 10:28       ` Andy Shevchenko
2023-02-07  1:41 ` [PATCH v3 05/12] driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links Saravana Kannan
2023-02-07  1:41   ` Saravana Kannan
2023-02-07  1:41 ` [PATCH v3 06/12] driver core: fw_devlink: Allow marking a fwnode link as being part of a cycle Saravana Kannan
2023-02-07  1:41   ` Saravana Kannan
2023-02-07  1:41 ` [PATCH v3 07/12] driver core: fw_devlink: Consolidate device link flag computation Saravana Kannan
2023-02-07  1:41   ` Saravana Kannan
2023-02-07  1:42 ` [PATCH v3 08/12] driver core: fw_devlink: Make cycle detection more robust Saravana Kannan
2023-02-07  1:42   ` Saravana Kannan
2023-02-07  1:42 ` [PATCH v3 09/12] of: property: Simplify of_link_to_phandle() Saravana Kannan
2023-02-07  1:42   ` Saravana Kannan
2023-02-07 20:57   ` Geert Uytterhoeven
2023-02-07 20:57     ` Geert Uytterhoeven
2023-02-07 20:57     ` Geert Uytterhoeven
2023-02-08  2:08     ` Saravana Kannan [this message]
2023-02-08  2:08       ` Saravana Kannan
2023-02-08  2:08       ` Saravana Kannan
2023-02-08  7:30       ` Geert Uytterhoeven
2023-02-08  7:30         ` Geert Uytterhoeven
2023-02-08  7:30         ` Geert Uytterhoeven
2023-02-08  7:31       ` Saravana Kannan
2023-02-08  7:31         ` Saravana Kannan
2023-02-08  7:31         ` Saravana Kannan
2023-02-08  7:56         ` Geert Uytterhoeven
2023-02-08  7:56           ` Geert Uytterhoeven
2023-02-08  7:56           ` Geert Uytterhoeven
2023-02-08  8:35           ` Saravana Kannan
2023-02-08  8:35             ` Saravana Kannan
2023-02-08  8:35             ` Saravana Kannan
2023-02-13 13:10             ` Geert Uytterhoeven
2023-02-13 13:10               ` Geert Uytterhoeven
2023-02-13 13:10               ` Geert Uytterhoeven
2023-02-08 13:37         ` Andy Shevchenko
2023-02-08 13:37           ` Andy Shevchenko
2023-02-08 13:37           ` Andy Shevchenko
2023-02-13 13:04       ` Geert Uytterhoeven
2023-02-13 13:04         ` Geert Uytterhoeven
2023-02-13 13:04         ` Geert Uytterhoeven
2023-02-08  7:33     ` Greg Kroah-Hartman
2023-02-08  7:33       ` Greg Kroah-Hartman
2023-02-08  7:33       ` Greg Kroah-Hartman
2023-02-08  7:50       ` Geert Uytterhoeven
2023-02-08  7:50         ` Geert Uytterhoeven
2023-02-08  7:50         ` Geert Uytterhoeven
2023-02-07  1:42 ` [PATCH v3 10/12] irqchip/irq-imx-gpcv2: Mark fwnode device as not initialized Saravana Kannan
2023-02-07  1:42   ` Saravana Kannan
2023-02-07  1:42 ` [PATCH v3 11/12] firmware: arm_scmi: Set fwnode for the scmi_device Saravana Kannan
2023-02-07  1:42   ` Saravana Kannan
2023-02-07  1:42 ` [PATCH v3 12/12] mtd: mtdpart: Don't create platform device that'll never probe Saravana Kannan
2023-02-07  1:42   ` Saravana Kannan
2023-02-07  7:51   ` Maxim Kiselev
2023-02-07  7:51     ` Maxim Kiselev
2023-02-07  7:51     ` Maxim Kiselev
2023-02-07  9:23 ` [PATCH v3 00/12] fw_devlink improvements Luca Weiss
2023-02-07  9:23   ` Luca Weiss
2023-02-07  9:23   ` Luca Weiss
2023-02-07 15:27 ` Doug Anderson
2023-02-07 15:27   ` Doug Anderson
2023-02-07 15:27   ` Doug Anderson
2023-02-07 18:15   ` Saravana Kannan
2023-02-07 18:15     ` Saravana Kannan
2023-02-07 18:15     ` Saravana Kannan
2023-02-07 21:35 ` Geert Uytterhoeven
2023-02-07 21:35   ` Geert Uytterhoeven
2023-02-07 21:35   ` Geert Uytterhoeven
2023-02-07 23:12   ` Saravana Kannan
2023-02-07 23:12     ` Saravana Kannan
2023-02-07 23:12     ` Saravana Kannan
2023-02-10 10:13 ` Vladimir Oltean
2023-02-10 10:13   ` Vladimir Oltean
2023-02-10 10:13   ` Vladimir Oltean
2023-02-10 19:27   ` Saravana Kannan
2023-02-10 19:27     ` Saravana Kannan
2023-02-10 19:27     ` Saravana Kannan
2023-02-10 21:08     ` Vladimir Oltean
2023-02-10 21:08       ` Vladimir Oltean
2023-02-10 21:08       ` Vladimir Oltean
2023-02-10 21:32       ` Saravana Kannan
2023-02-10 21:32         ` Saravana Kannan
2023-02-10 21:32         ` Saravana Kannan
2023-02-15  7:39 ` Tony Lindgren
2023-02-15  7:39   ` Tony Lindgren
2023-02-15  7:39   ` Tony Lindgren
2023-02-15 12:34 ` Jean-Philippe Brucker
2023-02-15 12:34   ` Jean-Philippe Brucker
2023-02-15 12:34   ` Jean-Philippe Brucker
2023-02-16  3:12 ` Dmitry Baryshkov
2023-02-16  3:12   ` Dmitry Baryshkov
2023-02-16  3:12   ` Dmitry Baryshkov
2023-02-25  6:24   ` Saravana Kannan
2023-02-25  6:24     ` Saravana Kannan
2023-02-25  6:24     ` 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='CAGETcx8DaZqS7+47PhX4hQOfSk7AzPcTu=2i+4gAgXr6wyDNgg@mail.gmail.com' \
    --to=saravanak@google.com \
    --cc=abel.vesa@linaro.org \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bigunclemax@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=colin.foster@in-advantage.com \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=djrscally@gmail.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=festevam@gmail.com \
    --cc=fido_max@inbox.ru \
    --cc=frowand.list@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=jpb@kernel.org \
    --cc=jstultz@google.com \
    --cc=kernel-team@android.com \
    --cc=kernel@pengutronix.de \
    --cc=lenb@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luca.weiss@fairphone.com \
    --cc=magnus.damm@gmail.com \
    --cc=martin.kepplinger@puri.sm \
    --cc=maz@kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=rafael@kernel.org \
    --cc=rafal@milecki.pl \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=sakari.ailus@linux.intel.com \
    --cc=shawnguo@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=tony@atomide.com \
    --cc=vigneshr@ti.com \
    --cc=vladimir.oltean@nxp.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.