From: Marc Zyngier <maz@kernel.org> To: Saravana Kannan <saravanak@google.com> Cc: Robin Murphy <robin.murphy@arm.com>, Qian Cai <qcai@redhat.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, "Rafael J. Wysocki" <rafael@kernel.org>, Len Brown <lenb@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Ard Biesheuvel <ardb@kernel.org>, Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, Grygorii Strashko <grygorii.strashko@ti.com>, Stephen Rothwell <sfr@canb.auug.org.au>, linux-efi <linux-efi@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Android Kernel Team <kernel-team@android.com>, Linux Next Mailing List <linux-next@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 16/17] driver core: Refactor fw_devlink feature Date: Fri, 11 Dec 2020 18:03:15 +0000 [thread overview] Message-ID: <813b3fbd80ad4dfee7ff8517d4829a1f@kernel.org> (raw) In-Reply-To: <CAGETcx-MsNyWWT=s1H6hDK+=QvibBLQrT9rM51y5bkomV_+G6g@mail.gmail.com> On 2020-12-11 17:51, Saravana Kannan wrote: > On Fri, Dec 11, 2020 at 8:34 AM Robin Murphy <robin.murphy@arm.com> > wrote: >> >> On 2020-12-11 14:11, Qian Cai wrote: >> > On Fri, 2020-11-20 at 18:02 -0800, Saravana Kannan wrote: >> >> The current implementation of fw_devlink is very inefficient because it >> >> tries to get away without creating fwnode links in the name of saving >> >> memory usage. Past attempts to optimize runtime at the cost of memory >> >> usage were blocked with request for data showing that the optimization >> >> made significant improvement for real world scenarios. >> >> >> >> We have those scenarios now. There have been several reports of boot >> >> time increase in the order of seconds in this thread [1]. Several OEMs >> >> and SoC manufacturers have also privately reported significant >> >> (350-400ms) increase in boot time due to all the parsing done by >> >> fw_devlink. >> >> >> >> So this patch uses all the setup done by the previous patches in this >> >> series to refactor fw_devlink to be more efficient. Most of the code has >> >> been moved out of firmware specific (DT mostly) code into driver core. >> >> >> >> This brings the following benefits: >> >> - Instead of parsing the device tree multiple times during bootup, >> >> fw_devlink parses each fwnode node/property only once and creates >> >> fwnode links. The rest of the fw_devlink code then just looks at these >> >> fwnode links to do rest of the work. >> >> >> >> - Makes it much easier to debug probe issue due to fw_devlink in the >> >> future. fw_devlink=on blocks the probing of devices if they depend on >> >> a device that hasn't been added yet. With this refactor, it'll be very >> >> easy to tell what that device is because we now have a reference to >> >> the fwnode of the device. >> >> >> >> - Much easier to add fw_devlink support to ACPI and other firmware >> >> types. A refactor to move the common bits from DT specific code to >> >> driver core was in my TODO list as a prerequisite to adding ACPI >> >> support to fw_devlink. This series gets that done. >> >> >> >> [1] - https://lore.kernel.org/linux-omap/ea02f57e-871d-cd16-4418-c1da4bbc4696@ti.com/ >> >> Signed-off-by: Saravana Kannan <saravanak@google.com> >> >> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >> >> Tested-by: Grygorii Strashko <grygorii.strashko@ti.com> >> > >> > Reverting this commit and its dependency: >> > >> > 2d09e6eb4a6f driver core: Delete pointless parameter in fwnode_operations.add_links >> > >> > from today's linux-next fixed a boot crash on an arm64 Thunder X2 server. >> >> Since the call stack implicates the platform-device-wrangling we do in >> IORT code I took a quick look; AFAICS my guess would be it's blowing >> up >> trying to walk a zeroed list head since "driver core: Add >> fwnode_init()" >> missed acpi_alloc_fwnode_static(). > > Thanks Robin. I'm pretty sure this is the reason. I thought I fixed > all ACPI cases, but clearly I missed this one. I'll send out a patch > for this today. If you think there are any other places I missed > please let me know. I'll try some git grep foo to see if I missed any > other instances of fwnode ops being set. Yup, that fixed it here (QDF2400). Thanks, M. diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 39263c6b52e1..2630c2e953f7 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -55,7 +55,7 @@ static inline struct fwnode_handle *acpi_alloc_fwnode_static(void) if (!fwnode) return NULL; - fwnode->ops = &acpi_static_fwnode_ops; + fwnode_init(fwnode, &acpi_static_fwnode_ops); return fwnode; } -- Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Saravana Kannan <saravanak@google.com> Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, linux-efi <linux-efi@vger.kernel.org>, Grygorii Strashko <grygorii.strashko@ti.com>, Frank Rowand <frowand.list@gmail.com>, "Rafael J. Wysocki" <rafael@kernel.org>, Qian Cai <qcai@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Tomi Valkeinen <tomi.valkeinen@ti.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, LKML <linux-kernel@vger.kernel.org>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, Linux Next Mailing List <linux-next@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Android Kernel Team <kernel-team@android.com>, Stephen Rothwell <sfr@canb.auug.org.au>, Thomas Gleixner <tglx@linutronix.de>, Robin Murphy <robin.murphy@arm.com>, Ard Biesheuvel <ardb@kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Len Brown <lenb@kernel.org> Subject: Re: [PATCH v2 16/17] driver core: Refactor fw_devlink feature Date: Fri, 11 Dec 2020 18:03:15 +0000 [thread overview] Message-ID: <813b3fbd80ad4dfee7ff8517d4829a1f@kernel.org> (raw) In-Reply-To: <CAGETcx-MsNyWWT=s1H6hDK+=QvibBLQrT9rM51y5bkomV_+G6g@mail.gmail.com> On 2020-12-11 17:51, Saravana Kannan wrote: > On Fri, Dec 11, 2020 at 8:34 AM Robin Murphy <robin.murphy@arm.com> > wrote: >> >> On 2020-12-11 14:11, Qian Cai wrote: >> > On Fri, 2020-11-20 at 18:02 -0800, Saravana Kannan wrote: >> >> The current implementation of fw_devlink is very inefficient because it >> >> tries to get away without creating fwnode links in the name of saving >> >> memory usage. Past attempts to optimize runtime at the cost of memory >> >> usage were blocked with request for data showing that the optimization >> >> made significant improvement for real world scenarios. >> >> >> >> We have those scenarios now. There have been several reports of boot >> >> time increase in the order of seconds in this thread [1]. Several OEMs >> >> and SoC manufacturers have also privately reported significant >> >> (350-400ms) increase in boot time due to all the parsing done by >> >> fw_devlink. >> >> >> >> So this patch uses all the setup done by the previous patches in this >> >> series to refactor fw_devlink to be more efficient. Most of the code has >> >> been moved out of firmware specific (DT mostly) code into driver core. >> >> >> >> This brings the following benefits: >> >> - Instead of parsing the device tree multiple times during bootup, >> >> fw_devlink parses each fwnode node/property only once and creates >> >> fwnode links. The rest of the fw_devlink code then just looks at these >> >> fwnode links to do rest of the work. >> >> >> >> - Makes it much easier to debug probe issue due to fw_devlink in the >> >> future. fw_devlink=on blocks the probing of devices if they depend on >> >> a device that hasn't been added yet. With this refactor, it'll be very >> >> easy to tell what that device is because we now have a reference to >> >> the fwnode of the device. >> >> >> >> - Much easier to add fw_devlink support to ACPI and other firmware >> >> types. A refactor to move the common bits from DT specific code to >> >> driver core was in my TODO list as a prerequisite to adding ACPI >> >> support to fw_devlink. This series gets that done. >> >> >> >> [1] - https://lore.kernel.org/linux-omap/ea02f57e-871d-cd16-4418-c1da4bbc4696@ti.com/ >> >> Signed-off-by: Saravana Kannan <saravanak@google.com> >> >> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> >> >> Tested-by: Grygorii Strashko <grygorii.strashko@ti.com> >> > >> > Reverting this commit and its dependency: >> > >> > 2d09e6eb4a6f driver core: Delete pointless parameter in fwnode_operations.add_links >> > >> > from today's linux-next fixed a boot crash on an arm64 Thunder X2 server. >> >> Since the call stack implicates the platform-device-wrangling we do in >> IORT code I took a quick look; AFAICS my guess would be it's blowing >> up >> trying to walk a zeroed list head since "driver core: Add >> fwnode_init()" >> missed acpi_alloc_fwnode_static(). > > Thanks Robin. I'm pretty sure this is the reason. I thought I fixed > all ACPI cases, but clearly I missed this one. I'll send out a patch > for this today. If you think there are any other places I missed > please let me know. I'll try some git grep foo to see if I missed any > other instances of fwnode ops being set. Yup, that fixed it here (QDF2400). Thanks, M. diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 39263c6b52e1..2630c2e953f7 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -55,7 +55,7 @@ static inline struct fwnode_handle *acpi_alloc_fwnode_static(void) if (!fwnode) return NULL; - fwnode->ops = &acpi_static_fwnode_ops; + fwnode_init(fwnode, &acpi_static_fwnode_ops); return fwnode; } -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-11 19:39 UTC|newest] Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-21 2:02 [PATCH v2 00/17] Refactor fw_devlink to significantly improve boot time Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 01/17] Revert "driver core: Avoid deferred probe due to fw_devlink_pause/resume()" Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 02/17] Revert "driver core: Rename dev_links_info.defer_sync to defer_hook" Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 03/17] Revert "driver core: Don't do deferred probe in parallel with kernel_init thread" Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 04/17] Revert "driver core: Remove check in driver_deferred_probe_force_trigger()" Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 05/17] Revert "of: platform: Batch fwnode parsing when adding all top level devices" Saravana Kannan 2020-12-07 22:18 ` Rob Herring 2020-11-21 2:02 ` [PATCH v2 06/17] Revert "driver core: fw_devlink: Add support for batching fwnode parsing" Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 07/17] driver core: Add fwnode_init() Saravana Kannan 2020-12-06 7:26 ` Leon Romanovsky 2020-12-07 19:25 ` Saravana Kannan 2020-12-07 19:53 ` Leon Romanovsky 2020-12-07 20:36 ` Saravana Kannan 2020-12-08 6:34 ` Leon Romanovsky 2020-12-07 22:20 ` Rob Herring 2020-11-21 2:02 ` [PATCH v2 08/17] driver core: Add fwnode link support Saravana Kannan 2020-12-06 7:48 ` Leon Romanovsky 2020-12-07 19:25 ` Saravana Kannan 2020-12-07 19:56 ` Leon Romanovsky 2020-12-07 22:21 ` Rob Herring 2020-11-21 2:02 ` [PATCH v2 09/17] driver core: Allow only unprobed consumers for SYNC_STATE_ONLY device links Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 10/17] device property: Add fwnode_is_ancestor_of() and fwnode_get_next_parent_dev() Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 11/17] driver core: Redefine the meaning of fwnode_operations.add_links() Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 12/17] driver core: Add fw_devlink_parse_fwtree() Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 13/17] driver core: Use device's fwnode to check if it is waiting for suppliers Saravana Kannan 2022-06-27 11:42 ` Abel Vesa 2022-06-27 22:30 ` Saravana Kannan 2022-06-28 15:24 ` Abel Vesa 2022-06-28 15:44 ` Abel Vesa 2022-06-28 15:55 ` Abel Vesa 2022-06-28 18:09 ` Saravana Kannan 2023-01-05 14:47 ` Dmitry Baryshkov 2020-11-21 2:02 ` [PATCH v2 14/17] of: property: Update implementation of add_links() to create fwnode links Saravana Kannan 2020-12-07 22:37 ` Rob Herring 2020-11-21 2:02 ` [PATCH v2 15/17] efi: " Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 16/17] driver core: Refactor fw_devlink feature Saravana Kannan 2020-11-23 16:00 ` [driver core] 95f755a4ef: will-it-scale.per_process_ops 2.2% improvement kernel test robot 2020-12-11 14:11 ` [PATCH v2 16/17] driver core: Refactor fw_devlink feature Qian Cai 2020-12-11 14:11 ` Qian Cai 2020-12-11 16:34 ` Robin Murphy 2020-12-11 16:34 ` Robin Murphy 2020-12-11 17:51 ` Saravana Kannan 2020-12-11 17:51 ` Saravana Kannan 2020-12-11 18:03 ` Marc Zyngier [this message] 2020-12-11 18:03 ` Marc Zyngier 2020-12-11 18:20 ` Saravana Kannan 2020-12-11 18:20 ` Saravana Kannan 2020-12-11 19:07 ` Marc Zyngier 2020-12-11 19:07 ` Marc Zyngier 2020-12-11 22:29 ` Saravana Kannan 2020-12-11 22:29 ` Saravana Kannan 2020-12-29 3:34 ` Michael Walle 2021-01-05 19:00 ` Saravana Kannan 2021-01-05 21:03 ` Michael Walle 2021-01-06 23:29 ` Saravana Kannan 2020-11-21 2:02 ` [PATCH v2 17/17] driver core: Delete pointless parameter in fwnode_operations.add_links Saravana Kannan 2020-12-07 22:38 ` Rob Herring 2020-11-24 8:29 ` [PATCH v2 00/17] Refactor fw_devlink to significantly improve boot time Tomi Valkeinen 2020-11-24 17:25 ` Saravana Kannan 2020-12-03 19:05 ` Saravana Kannan 2020-12-09 18:16 ` Greg Kroah-Hartman 2020-12-09 20:24 ` Saravana Kannan 2020-12-10 9:26 ` Greg Kroah-Hartman
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=813b3fbd80ad4dfee7ff8517d4829a1f@kernel.org \ --to=maz@kernel.org \ --cc=ardb@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=grygorii.strashko@ti.com \ --cc=kernel-team@android.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=lenb@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-next@vger.kernel.org \ --cc=qcai@redhat.com \ --cc=rafael@kernel.org \ --cc=rjw@rjwysocki.net \ --cc=robh+dt@kernel.org \ --cc=robin.murphy@arm.com \ --cc=saravanak@google.com \ --cc=sfr@canb.auug.org.au \ --cc=tglx@linutronix.de \ --cc=tomi.valkeinen@ti.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: linkBe 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.