drivers/base/core.c | 55 ++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 31 deletions(-)
In attempting to optimize fw_devlink runtime, I introduced numerous cycle
detection bugs by foregoing cycle detection logic under specific
conditions. Each fix has further narrowed the conditions for optimization.
It's time to give up on these optimization attempts and just run the cycle
detection logic every time fw_devlink tries to create a device link.
The specific bug report that triggered this fix involved a supplier fwnode
that never gets a device created for it. Instead, the supplier fwnode is
represented by the device that corresponds to an ancestor fwnode.
In this case, fw_devlink didn't do any cycle detection because the cycle
detection logic is only run when a device link is created between the
devices that correspond to the actual consumer and supplier fwnodes.
With this change, fw_devlink will run cycle detection logic even when
creating SYNC_STATE_ONLY proxy device links from a device that is an
ancestor of a consumer fwnode.
Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/base/core.c | 55 ++++++++++++++++++++-------------------------
1 file changed, 24 insertions(+), 31 deletions(-)
Tomi,
Thanks for all the testing and debugging help! And do use
post-init-providers even with this patch to improve ordering
enforcement. I probably should change the cycle log from info to warn in
a separate patch :)
Greg,
I no longer have concerns about pulling this into 6.13. But we can give
a week or so to Geert/Francesco to do some additional testing.
Geert/Francesco,
If you want to test this patch, pull it in and compare the output of
the following:
ls -1 /sys/class/devlink
The only device links that should be missing with the patch should be
device links in a cycle that weren't detected before.
Also, if you notice any significant boot time increase with this change,
let me know.
Thanks,
Saravana
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3b13fed1c3e3..9a490b1b7a6f 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1990,10 +1990,10 @@ static struct device *fwnode_get_next_parent_dev(const struct fwnode_handle *fwn
*
* Return true if one or more cycles were found. Otherwise, return false.
*/
-static bool __fw_devlink_relax_cycles(struct device *con,
+static bool __fw_devlink_relax_cycles(struct fwnode_handle *con_handle,
struct fwnode_handle *sup_handle)
{
- struct device *sup_dev = NULL, *par_dev = NULL;
+ struct device *sup_dev = NULL, *par_dev = NULL, *con_dev = NULL;
struct fwnode_link *link;
struct device_link *dev_link;
bool ret = false;
@@ -2010,22 +2010,22 @@ static bool __fw_devlink_relax_cycles(struct device *con,
sup_handle->flags |= FWNODE_FLAG_VISITED;
- sup_dev = get_dev_from_fwnode(sup_handle);
-
/* Termination condition. */
- if (sup_dev == con) {
+ if (sup_handle == con_handle) {
pr_debug("----- cycle: start -----\n");
ret = true;
goto out;
}
+ sup_dev = get_dev_from_fwnode(sup_handle);
+ con_dev = get_dev_from_fwnode(con_handle);
/*
* If sup_dev is bound to a driver and @con hasn't started binding to a
* driver, sup_dev can't be a consumer of @con. So, no need to check
* further.
*/
if (sup_dev && sup_dev->links.status == DL_DEV_DRIVER_BOUND &&
- con->links.status == DL_DEV_NO_DRIVER) {
+ con_dev && con_dev->links.status == DL_DEV_NO_DRIVER) {
ret = false;
goto out;
}
@@ -2034,7 +2034,7 @@ static bool __fw_devlink_relax_cycles(struct device *con,
if (link->flags & FWLINK_FLAG_IGNORE)
continue;
- if (__fw_devlink_relax_cycles(con, link->supplier)) {
+ if (__fw_devlink_relax_cycles(con_handle, link->supplier)) {
__fwnode_link_cycle(link);
ret = true;
}
@@ -2049,7 +2049,7 @@ static bool __fw_devlink_relax_cycles(struct device *con,
else
par_dev = fwnode_get_next_parent_dev(sup_handle);
- if (par_dev && __fw_devlink_relax_cycles(con, par_dev->fwnode)) {
+ if (par_dev && __fw_devlink_relax_cycles(con_handle, par_dev->fwnode)) {
pr_debug("%pfwf: cycle: child of %pfwf\n", sup_handle,
par_dev->fwnode);
ret = true;
@@ -2067,7 +2067,7 @@ static bool __fw_devlink_relax_cycles(struct device *con,
!(dev_link->flags & DL_FLAG_CYCLE))
continue;
- if (__fw_devlink_relax_cycles(con,
+ if (__fw_devlink_relax_cycles(con_handle,
dev_link->supplier->fwnode)) {
pr_debug("%pfwf: cycle: depends on %pfwf\n", sup_handle,
dev_link->supplier->fwnode);
@@ -2115,11 +2115,6 @@ static int fw_devlink_create_devlink(struct device *con,
if (link->flags & FWLINK_FLAG_IGNORE)
return 0;
- if (con->fwnode == link->consumer)
- flags = fw_devlink_get_flags(link->flags);
- else
- flags = FW_DEVLINK_FLAGS_PERMISSIVE;
-
/*
* In some cases, a device P might also be a supplier to its child node
* C. However, this would defer the probe of C until the probe of P
@@ -2140,25 +2135,23 @@ static int fw_devlink_create_devlink(struct device *con,
return -EINVAL;
/*
- * SYNC_STATE_ONLY device links don't block probing and supports cycles.
- * So, one might expect that cycle detection isn't necessary for them.
- * However, if the device link was marked as SYNC_STATE_ONLY because
- * it's part of a cycle, then we still need to do cycle detection. This
- * is because the consumer and supplier might be part of multiple cycles
- * and we need to detect all those cycles.
+ * Don't try to optimize by not calling the cycle detection logic under
+ * certain conditions. There's always some corner case that won't get
+ * detected.
*/
- if (!device_link_flag_is_sync_state_only(flags) ||
- flags & DL_FLAG_CYCLE) {
- device_links_write_lock();
- if (__fw_devlink_relax_cycles(con, sup_handle)) {
- __fwnode_link_cycle(link);
- flags = fw_devlink_get_flags(link->flags);
- pr_debug("----- cycle: end -----\n");
- dev_info(con, "Fixed dependency cycle(s) with %pfwf\n",
- sup_handle);
- }
- device_links_write_unlock();
+ device_links_write_lock();
+ if (__fw_devlink_relax_cycles(link->consumer, sup_handle)) {
+ __fwnode_link_cycle(link);
+ pr_debug("----- cycle: end -----\n");
+ pr_info("%pfwf: Fixed dependency cycle(s) with %pfwf\n",
+ link->consumer, sup_handle);
}
+ device_links_write_unlock();
+
+ if (con->fwnode == link->consumer)
+ flags = fw_devlink_get_flags(link->flags);
+ else
+ flags = FW_DEVLINK_FLAGS_PERMISSIVE;
if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
sup_dev = fwnode_get_next_parent_dev(sup_handle);
--
2.47.0.163.g1226f6d8fa-googHi Saravana,
On 30/10/2024 19:10, Saravana Kannan wrote:
> In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> detection bugs by foregoing cycle detection logic under specific
> conditions. Each fix has further narrowed the conditions for optimization.
>
> It's time to give up on these optimization attempts and just run the cycle
> detection logic every time fw_devlink tries to create a device link.
>
> The specific bug report that triggered this fix involved a supplier fwnode
> that never gets a device created for it. Instead, the supplier fwnode is
> represented by the device that corresponds to an ancestor fwnode.
>
> In this case, fw_devlink didn't do any cycle detection because the cycle
> detection logic is only run when a device link is created between the
> devices that correspond to the actual consumer and supplier fwnodes.
>
> With this change, fw_devlink will run cycle detection logic even when
> creating SYNC_STATE_ONLY proxy device links from a device that is an
> ancestor of a consumer fwnode.
>
> Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> drivers/base/core.c | 55 ++++++++++++++++++++-------------------------
> 1 file changed, 24 insertions(+), 31 deletions(-)
>
> Tomi,
>
> Thanks for all the testing and debugging help! And do use
> post-init-providers even with this patch to improve ordering
> enforcement. I probably should change the cycle log from info to warn in
> a separate patch :)
I've had this patch in one of my WIP branches for a while. Today I
started debugging a kmemleak in the branch, which I thought was related
to my changes. However, it ended up being this patch.
One of the drivers touched in my WIP branch is
drivers/media/i2c/ds90ub960.c. It does a i2c_new_client_device() and, at
remove time, i2c_unregister_device().
Without this patch, with some debug prints, I see that the newly created
i2c client has a kref count of 11, and when i2c_unregister_device() is
called, I see kref dropping to 0 and i2c_client_dev_release() being called.
With this patch, after i2c_new_client_device(), I see a kref of 16, and
after i2c_unregister_device(), a kref of 5 (and i2c_client_dev_release()
not called).
So five new refs were added, and not released... Any thoughts?
Tomi
Hello Saravana,
+Cc. DT maintainers, Hervé
On Wed, 30 Oct 2024 10:10:07 -0700
Saravana Kannan <saravanak@google.com> wrote:
> In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> detection bugs by foregoing cycle detection logic under specific
> conditions. Each fix has further narrowed the conditions for optimization.
>
> It's time to give up on these optimization attempts and just run the cycle
> detection logic every time fw_devlink tries to create a device link.
>
> The specific bug report that triggered this fix involved a supplier fwnode
> that never gets a device created for it. Instead, the supplier fwnode is
> represented by the device that corresponds to an ancestor fwnode.
>
> In this case, fw_devlink didn't do any cycle detection because the cycle
> detection logic is only run when a device link is created between the
> devices that correspond to the actual consumer and supplier fwnodes.
>
> With this change, fw_devlink will run cycle detection logic even when
> creating SYNC_STATE_ONLY proxy device links from a device that is an
> ancestor of a consumer fwnode.
>
> Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
After rebasing my work for the hotplug connector driver using device
tree overlays [0] on v6.13-rc1 I started getting these OF errors on
overlay removal:
OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/panel-dsi-lvds
OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/backlight-addon
OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/battery-charger
OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-5v0-sys
OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-3v3-sys
...and many more. Exactly one per each device in the overlay 'devices'
node, each implemented by a platform driver.
Bisecting found this patch is triggering these error messages, which
in fact disappear by reverting it.
I looked at the differences in dmesg and /sys/class/devlink/ in the
"good" and "bad" cases, and found almost no differences. The only
relevant difference is in cycle detection for the panel node, which was
expected, but nothing about all the other nodes like regulators.
Enabling debug messages in core.c also does not show significant
changes between the two cases, even though it's hard to be sure given
the verbosity of the log and the reordering of messages.
I suspect the new version of the cycle removal code is missing an
of_node_get() somewhere, but that is not directly visible in the patch
diff itself.
Any clues?
[0] https://lore.kernel.org/all/20240917-hotplug-drm-bridge-v4-0-bc4dfee61be6@bootlin.com/
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Saravana,
On Wed, 4 Dec 2024 12:48:26 +0100
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> Hello Saravana,
>
> +Cc. DT maintainers, Hervé
>
> On Wed, 30 Oct 2024 10:10:07 -0700
> Saravana Kannan <saravanak@google.com> wrote:
>
> > In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> > detection bugs by foregoing cycle detection logic under specific
> > conditions. Each fix has further narrowed the conditions for optimization.
> >
> > It's time to give up on these optimization attempts and just run the cycle
> > detection logic every time fw_devlink tries to create a device link.
> >
> > The specific bug report that triggered this fix involved a supplier fwnode
> > that never gets a device created for it. Instead, the supplier fwnode is
> > represented by the device that corresponds to an ancestor fwnode.
> >
> > In this case, fw_devlink didn't do any cycle detection because the cycle
> > detection logic is only run when a device link is created between the
> > devices that correspond to the actual consumer and supplier fwnodes.
> >
> > With this change, fw_devlink will run cycle detection logic even when
> > creating SYNC_STATE_ONLY proxy device links from a device that is an
> > ancestor of a consumer fwnode.
> >
> > Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> > Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> > Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> After rebasing my work for the hotplug connector driver using device
> tree overlays [0] on v6.13-rc1 I started getting these OF errors on
> overlay removal:
>
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/panel-dsi-lvds
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/backlight-addon
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/battery-charger
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-5v0-sys
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-3v3-sys
>
> ...and many more. Exactly one per each device in the overlay 'devices'
> node, each implemented by a platform driver.
>
> Bisecting found this patch is triggering these error messages, which
> in fact disappear by reverting it.
>
> I looked at the differences in dmesg and /sys/class/devlink/ in the
> "good" and "bad" cases, and found almost no differences. The only
> relevant difference is in cycle detection for the panel node, which was
> expected, but nothing about all the other nodes like regulators.
>
> Enabling debug messages in core.c also does not show significant
> changes between the two cases, even though it's hard to be sure given
> the verbosity of the log and the reordering of messages.
>
> I suspect the new version of the cycle removal code is missing an
> of_node_get() somewhere, but that is not directly visible in the patch
> diff itself.
I collected some more info by adding a bit of logging for one of the
affected devices.
It looks like the of_node_get() and of_node_put() in the overlay
loading phase are the same, even though not completely in the same
order. So after overlay insertion we should have the same refcount with
and without your patch.
There is a difference on overlay removal however: an of_node_put() call
is absent with 6.13-rc1 code (errors emitted), and becomes present by
just reverting your patch (the "good" case). Here's the stack trace of
this call:
Call trace:
show_stack+0x20/0x38 (C)
dump_stack_lvl+0x74/0x90
dump_stack+0x18/0x28
of_node_put+0x50/0x70
platform_device_release+0x24/0x68
device_release+0x3c/0xa0
kobject_put+0xa4/0x118
device_link_release_fn+0x60/0xd8
process_one_work+0x158/0x3c0
worker_thread+0x2d8/0x3e8
kthread+0x118/0x128
ret_from_fork+0x10/0x20
So for some reason device_link_release_fn() is not leading to a
of_node_put() call after adding your patch.
Quick code inspection did not show any useful info for me to understand
more.
Ideas?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hello, On Fri, 6 Dec 2024 10:31:43 +0100 Luca Ceresoli <luca.ceresoli@bootlin.com> wrote: > > After rebasing my work for the hotplug connector driver using device > > tree overlays [0] on v6.13-rc1 I started getting these OF errors on > > overlay removal: > > > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/panel-dsi-lvds > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/backlight-addon > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/battery-charger > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-5v0-sys > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-3v3-sys > > > > ...and many more. Exactly one per each device in the overlay 'devices' > > node, each implemented by a platform driver. > > > > Bisecting found this patch is triggering these error messages, which > > in fact disappear by reverting it. > > > > I looked at the differences in dmesg and /sys/class/devlink/ in the > > "good" and "bad" cases, and found almost no differences. The only > > relevant difference is in cycle detection for the panel node, which was > > expected, but nothing about all the other nodes like regulators. > > > > Enabling debug messages in core.c also does not show significant > > changes between the two cases, even though it's hard to be sure given > > the verbosity of the log and the reordering of messages. > > > > I suspect the new version of the cycle removal code is missing an > > of_node_get() somewhere, but that is not directly visible in the patch > > diff itself. > > I collected some more info by adding a bit of logging for one of the > affected devices. > > It looks like the of_node_get() and of_node_put() in the overlay > loading phase are the same, even though not completely in the same > order. So after overlay insertion we should have the same refcount with > and without your patch. > > There is a difference on overlay removal however: an of_node_put() call > is absent with 6.13-rc1 code (errors emitted), and becomes present by > just reverting your patch (the "good" case). Here's the stack trace of > this call: > > Call trace: > show_stack+0x20/0x38 (C) > dump_stack_lvl+0x74/0x90 > dump_stack+0x18/0x28 > of_node_put+0x50/0x70 > platform_device_release+0x24/0x68 > device_release+0x3c/0xa0 > kobject_put+0xa4/0x118 > device_link_release_fn+0x60/0xd8 > process_one_work+0x158/0x3c0 > worker_thread+0x2d8/0x3e8 > kthread+0x118/0x128 > ret_from_fork+0x10/0x20 > > So for some reason device_link_release_fn() is not leading to a > of_node_put() call after adding your patch. > > Quick code inspection did not show any useful info for me to understand > more. I just sent a patch fixing this: https://lore.kernel.org/20250212-fix__fw_devlink_relax_cycles_missing_device_put-v1-1-41818c7d7722@bootlin.com Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Wed, Feb 12, 2025 at 7:33 AM Luca Ceresoli <luca.ceresoli@bootlin.com> wrote: > > Hello, > > On Fri, 6 Dec 2024 10:31:43 +0100 > Luca Ceresoli <luca.ceresoli@bootlin.com> wrote: > > > > After rebasing my work for the hotplug connector driver using device > > > tree overlays [0] on v6.13-rc1 I started getting these OF errors on > > > overlay removal: > > > > > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/panel-dsi-lvds > > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/backlight-addon > > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/battery-charger > > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-5v0-sys > > > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-3v3-sys > > > > > > ...and many more. Exactly one per each device in the overlay 'devices' > > > node, each implemented by a platform driver. > > > > > > Bisecting found this patch is triggering these error messages, which > > > in fact disappear by reverting it. > > > > > > I looked at the differences in dmesg and /sys/class/devlink/ in the > > > "good" and "bad" cases, and found almost no differences. The only > > > relevant difference is in cycle detection for the panel node, which was > > > expected, but nothing about all the other nodes like regulators. > > > > > > Enabling debug messages in core.c also does not show significant > > > changes between the two cases, even though it's hard to be sure given > > > the verbosity of the log and the reordering of messages. > > > > > > I suspect the new version of the cycle removal code is missing an > > > of_node_get() somewhere, but that is not directly visible in the patch > > > diff itself. > > > > I collected some more info by adding a bit of logging for one of the > > affected devices. > > > > It looks like the of_node_get() and of_node_put() in the overlay > > loading phase are the same, even though not completely in the same > > order. So after overlay insertion we should have the same refcount with > > and without your patch. > > > > There is a difference on overlay removal however: an of_node_put() call > > is absent with 6.13-rc1 code (errors emitted), and becomes present by > > just reverting your patch (the "good" case). Here's the stack trace of > > this call: > > > > Call trace: > > show_stack+0x20/0x38 (C) > > dump_stack_lvl+0x74/0x90 > > dump_stack+0x18/0x28 > > of_node_put+0x50/0x70 > > platform_device_release+0x24/0x68 > > device_release+0x3c/0xa0 > > kobject_put+0xa4/0x118 > > device_link_release_fn+0x60/0xd8 > > process_one_work+0x158/0x3c0 > > worker_thread+0x2d8/0x3e8 > > kthread+0x118/0x128 > > ret_from_fork+0x10/0x20 > > > > So for some reason device_link_release_fn() is not leading to a > > of_node_put() call after adding your patch. > > > > Quick code inspection did not show any useful info for me to understand > > more. > > I just sent a patch fixing > this: https://lore.kernel.org/20250212-fix__fw_devlink_relax_cycles_missing_device_put-v1-1-41818c7d7722@bootlin.com Thanks a lot for debugging and fixing this! I'll review that patch. -Saravana
Hi Luca,
On Wed, Dec 4, 2024 at 12:48 PM Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> On Wed, 30 Oct 2024 10:10:07 -0700
> Saravana Kannan <saravanak@google.com> wrote:
>
> > In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> > detection bugs by foregoing cycle detection logic under specific
> > conditions. Each fix has further narrowed the conditions for optimization.
> >
> > It's time to give up on these optimization attempts and just run the cycle
> > detection logic every time fw_devlink tries to create a device link.
> >
> > The specific bug report that triggered this fix involved a supplier fwnode
> > that never gets a device created for it. Instead, the supplier fwnode is
> > represented by the device that corresponds to an ancestor fwnode.
> >
> > In this case, fw_devlink didn't do any cycle detection because the cycle
> > detection logic is only run when a device link is created between the
> > devices that correspond to the actual consumer and supplier fwnodes.
> >
> > With this change, fw_devlink will run cycle detection logic even when
> > creating SYNC_STATE_ONLY proxy device links from a device that is an
> > ancestor of a consumer fwnode.
> >
> > Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> > Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> > Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> After rebasing my work for the hotplug connector driver using device
> tree overlays [0] on v6.13-rc1 I started getting these OF errors on
> overlay removal:
>
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/panel-dsi-lvds
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/backlight-addon
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/battery-charger
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-5v0-sys
> OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-3v3-sys
>
> ...and many more. Exactly one per each device in the overlay 'devices'
> node, each implemented by a platform driver.
FTR, I am not seeing that when loading/removing
r8a77990-ebisu-cn41-msiof0-25lc040.dtso
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=topic/renesas-overlays&id=dd998e8db58b67744eb91f11f13544401c975470
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
thanks for your feedback.
On Wed, 4 Dec 2024 13:52:56 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Luca,
>
> On Wed, Dec 4, 2024 at 12:48 PM Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> > On Wed, 30 Oct 2024 10:10:07 -0700
> > Saravana Kannan <saravanak@google.com> wrote:
> >
> > > In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> > > detection bugs by foregoing cycle detection logic under specific
> > > conditions. Each fix has further narrowed the conditions for optimization.
> > >
> > > It's time to give up on these optimization attempts and just run the cycle
> > > detection logic every time fw_devlink tries to create a device link.
> > >
> > > The specific bug report that triggered this fix involved a supplier fwnode
> > > that never gets a device created for it. Instead, the supplier fwnode is
> > > represented by the device that corresponds to an ancestor fwnode.
> > >
> > > In this case, fw_devlink didn't do any cycle detection because the cycle
> > > detection logic is only run when a device link is created between the
> > > devices that correspond to the actual consumer and supplier fwnodes.
> > >
> > > With this change, fw_devlink will run cycle detection logic even when
> > > creating SYNC_STATE_ONLY proxy device links from a device that is an
> > > ancestor of a consumer fwnode.
> > >
> > > Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > > Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> > > Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> > > Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > > Signed-off-by: Saravana Kannan <saravanak@google.com>
> >
> > After rebasing my work for the hotplug connector driver using device
> > tree overlays [0] on v6.13-rc1 I started getting these OF errors on
> > overlay removal:
> >
> > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/panel-dsi-lvds
> > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/backlight-addon
> > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/battery-charger
> > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-5v0-sys
> > OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /addon-connector/devices/regulator-addon-3v3-sys
> >
> > ...and many more. Exactly one per each device in the overlay 'devices'
> > node, each implemented by a platform driver.
>
> FTR, I am not seeing that when loading/removing
> r8a77990-ebisu-cn41-msiof0-25lc040.dtso
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=topic/renesas-overlays&id=dd998e8db58b67744eb91f11f13544401c975470
This overlay is adding an SPI device. In my overlay I don't have any
SPI devices, but I have I2C and other devices and I'm getting those
errors only about devices implemented by platform drivers. Not sure
that matters, but that's the first difference that came to mind.
Best regards,
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Saravana,
On Wed, Oct 30, 2024 at 6:10 PM Saravana Kannan <saravanak@google.com> wrote:
> In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> detection bugs by foregoing cycle detection logic under specific
> conditions. Each fix has further narrowed the conditions for optimization.
>
> It's time to give up on these optimization attempts and just run the cycle
> detection logic every time fw_devlink tries to create a device link.
>
> The specific bug report that triggered this fix involved a supplier fwnode
> that never gets a device created for it. Instead, the supplier fwnode is
> represented by the device that corresponds to an ancestor fwnode.
>
> In this case, fw_devlink didn't do any cycle detection because the cycle
> detection logic is only run when a device link is created between the
> devices that correspond to the actual consumer and supplier fwnodes.
>
> With this change, fw_devlink will run cycle detection logic even when
> creating SYNC_STATE_ONLY proxy device links from a device that is an
> ancestor of a consumer fwnode.
>
> Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
Thanks for your patch, which is now commit bac3b10b78e54b7d ("driver
core: fw_devlink: Stop trying to optimize cycle detection logic") in
next-20241107 and later.
> Geert/Francesco,
>
> If you want to test this patch, pull it in and compare the output of
> the following:
>
> ls -1 /sys/class/devlink
>
> The only device links that should be missing with the patch should be
> device links in a cycle that weren't detected before.
I gave it a try on all my boards, and compared the output on a few of
them, and everything looks fine.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Nov 19, 2024 at 5:40 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Wed, Oct 30, 2024 at 6:10 PM Saravana Kannan <saravanak@google.com> wrote:
> > In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> > detection bugs by foregoing cycle detection logic under specific
> > conditions. Each fix has further narrowed the conditions for optimization.
> >
> > It's time to give up on these optimization attempts and just run the cycle
> > detection logic every time fw_devlink tries to create a device link.
> >
> > The specific bug report that triggered this fix involved a supplier fwnode
> > that never gets a device created for it. Instead, the supplier fwnode is
> > represented by the device that corresponds to an ancestor fwnode.
> >
> > In this case, fw_devlink didn't do any cycle detection because the cycle
> > detection logic is only run when a device link is created between the
> > devices that correspond to the actual consumer and supplier fwnodes.
> >
> > With this change, fw_devlink will run cycle detection logic even when
> > creating SYNC_STATE_ONLY proxy device links from a device that is an
> > ancestor of a consumer fwnode.
> >
> > Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> > Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> > Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> Thanks for your patch, which is now commit bac3b10b78e54b7d ("driver
> core: fw_devlink: Stop trying to optimize cycle detection logic") in
> next-20241107 and later.
>
> > Geert/Francesco,
> >
> > If you want to test this patch, pull it in and compare the output of
> > the following:
> >
> > ls -1 /sys/class/devlink
> >
> > The only device links that should be missing with the patch should be
> > device links in a cycle that weren't detected before.
>
> I gave it a try on all my boards, and compared the output on a few of
> them, and everything looks fine.
Thanks for testing the series Geert!
And no noticeable boot time increases?
Thanks,
Saravana
Hi Saravana,
On Wed, Nov 20, 2024 at 3:04 AM Saravana Kannan <saravanak@google.com> wrote:
> On Tue, Nov 19, 2024 at 5:40 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Wed, Oct 30, 2024 at 6:10 PM Saravana Kannan <saravanak@google.com> wrote:
> > > In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> > > detection bugs by foregoing cycle detection logic under specific
> > > conditions. Each fix has further narrowed the conditions for optimization.
> > >
> > > It's time to give up on these optimization attempts and just run the cycle
> > > detection logic every time fw_devlink tries to create a device link.
> > >
> > > The specific bug report that triggered this fix involved a supplier fwnode
> > > that never gets a device created for it. Instead, the supplier fwnode is
> > > represented by the device that corresponds to an ancestor fwnode.
> > >
> > > In this case, fw_devlink didn't do any cycle detection because the cycle
> > > detection logic is only run when a device link is created between the
> > > devices that correspond to the actual consumer and supplier fwnodes.
> > >
> > > With this change, fw_devlink will run cycle detection logic even when
> > > creating SYNC_STATE_ONLY proxy device links from a device that is an
> > > ancestor of a consumer fwnode.
> > >
> > > Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > > Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> > > Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> > > Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > > Signed-off-by: Saravana Kannan <saravanak@google.com>
> >
> > Thanks for your patch, which is now commit bac3b10b78e54b7d ("driver
> > core: fw_devlink: Stop trying to optimize cycle detection logic") in
> > next-20241107 and later.
> >
> > > Geert/Francesco,
> > >
> > > If you want to test this patch, pull it in and compare the output of
> > > the following:
> > >
> > > ls -1 /sys/class/devlink
> > >
> > > The only device links that should be missing with the patch should be
> > > device links in a cycle that weren't detected before.
> >
> > I gave it a try on all my boards, and compared the output on a few of
> > them, and everything looks fine.
>
> Thanks for testing the series Geert!
>
> And no noticeable boot time increases?
That's a bit hard to measure, as the serial console output easily takes
ten seconds.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Oct 30, 2024 at 10:10 AM Saravana Kannan <saravanak@google.com> wrote:
>
> In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> detection bugs by foregoing cycle detection logic under specific
> conditions. Each fix has further narrowed the conditions for optimization.
>
> It's time to give up on these optimization attempts and just run the cycle
> detection logic every time fw_devlink tries to create a device link.
>
> The specific bug report that triggered this fix involved a supplier fwnode
> that never gets a device created for it. Instead, the supplier fwnode is
> represented by the device that corresponds to an ancestor fwnode.
>
> In this case, fw_devlink didn't do any cycle detection because the cycle
> detection logic is only run when a device link is created between the
> devices that correspond to the actual consumer and supplier fwnodes.
>
> With this change, fw_devlink will run cycle detection logic even when
> creating SYNC_STATE_ONLY proxy device links from a device that is an
> ancestor of a consumer fwnode.
>
> Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> drivers/base/core.c | 55 ++++++++++++++++++++-------------------------
> 1 file changed, 24 insertions(+), 31 deletions(-)
>
> Tomi,
>
> Thanks for all the testing and debugging help! And do use
> post-init-providers even with this patch to improve ordering
> enforcement. I probably should change the cycle log from info to warn in
> a separate patch :)
>
> Greg,
>
> I no longer have concerns about pulling this into 6.13. But we can give
> a week or so to Geert/Francesco to do some additional testing.
>
> Geert/Francesco,
Heads up. Greg has pulled this into driver-core git's
driver-core-testing branch. Which means in a week or two it'll get
into the actual driver-core-next branch. So, if you want to do
additional testing, you might want to jump on it soon.
Thanks,
Saravana
>
> If you want to test this patch, pull it in and compare the output of
> the following:
>
> ls -1 /sys/class/devlink
>
> The only device links that should be missing with the patch should be
> device links in a cycle that weren't detected before.
>
> Also, if you notice any significant boot time increase with this change,
> let me know.
>
> Thanks,
> Saravana
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 3b13fed1c3e3..9a490b1b7a6f 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1990,10 +1990,10 @@ static struct device *fwnode_get_next_parent_dev(const struct fwnode_handle *fwn
> *
> * Return true if one or more cycles were found. Otherwise, return false.
> */
> -static bool __fw_devlink_relax_cycles(struct device *con,
> +static bool __fw_devlink_relax_cycles(struct fwnode_handle *con_handle,
> struct fwnode_handle *sup_handle)
> {
> - struct device *sup_dev = NULL, *par_dev = NULL;
> + struct device *sup_dev = NULL, *par_dev = NULL, *con_dev = NULL;
> struct fwnode_link *link;
> struct device_link *dev_link;
> bool ret = false;
> @@ -2010,22 +2010,22 @@ static bool __fw_devlink_relax_cycles(struct device *con,
>
> sup_handle->flags |= FWNODE_FLAG_VISITED;
>
> - sup_dev = get_dev_from_fwnode(sup_handle);
> -
> /* Termination condition. */
> - if (sup_dev == con) {
> + if (sup_handle == con_handle) {
> pr_debug("----- cycle: start -----\n");
> ret = true;
> goto out;
> }
>
> + sup_dev = get_dev_from_fwnode(sup_handle);
> + con_dev = get_dev_from_fwnode(con_handle);
> /*
> * If sup_dev is bound to a driver and @con hasn't started binding to a
> * driver, sup_dev can't be a consumer of @con. So, no need to check
> * further.
> */
> if (sup_dev && sup_dev->links.status == DL_DEV_DRIVER_BOUND &&
> - con->links.status == DL_DEV_NO_DRIVER) {
> + con_dev && con_dev->links.status == DL_DEV_NO_DRIVER) {
> ret = false;
> goto out;
> }
> @@ -2034,7 +2034,7 @@ static bool __fw_devlink_relax_cycles(struct device *con,
> if (link->flags & FWLINK_FLAG_IGNORE)
> continue;
>
> - if (__fw_devlink_relax_cycles(con, link->supplier)) {
> + if (__fw_devlink_relax_cycles(con_handle, link->supplier)) {
> __fwnode_link_cycle(link);
> ret = true;
> }
> @@ -2049,7 +2049,7 @@ static bool __fw_devlink_relax_cycles(struct device *con,
> else
> par_dev = fwnode_get_next_parent_dev(sup_handle);
>
> - if (par_dev && __fw_devlink_relax_cycles(con, par_dev->fwnode)) {
> + if (par_dev && __fw_devlink_relax_cycles(con_handle, par_dev->fwnode)) {
> pr_debug("%pfwf: cycle: child of %pfwf\n", sup_handle,
> par_dev->fwnode);
> ret = true;
> @@ -2067,7 +2067,7 @@ static bool __fw_devlink_relax_cycles(struct device *con,
> !(dev_link->flags & DL_FLAG_CYCLE))
> continue;
>
> - if (__fw_devlink_relax_cycles(con,
> + if (__fw_devlink_relax_cycles(con_handle,
> dev_link->supplier->fwnode)) {
> pr_debug("%pfwf: cycle: depends on %pfwf\n", sup_handle,
> dev_link->supplier->fwnode);
> @@ -2115,11 +2115,6 @@ static int fw_devlink_create_devlink(struct device *con,
> if (link->flags & FWLINK_FLAG_IGNORE)
> return 0;
>
> - if (con->fwnode == link->consumer)
> - flags = fw_devlink_get_flags(link->flags);
> - else
> - flags = FW_DEVLINK_FLAGS_PERMISSIVE;
> -
> /*
> * In some cases, a device P might also be a supplier to its child node
> * C. However, this would defer the probe of C until the probe of P
> @@ -2140,25 +2135,23 @@ static int fw_devlink_create_devlink(struct device *con,
> return -EINVAL;
>
> /*
> - * SYNC_STATE_ONLY device links don't block probing and supports cycles.
> - * So, one might expect that cycle detection isn't necessary for them.
> - * However, if the device link was marked as SYNC_STATE_ONLY because
> - * it's part of a cycle, then we still need to do cycle detection. This
> - * is because the consumer and supplier might be part of multiple cycles
> - * and we need to detect all those cycles.
> + * Don't try to optimize by not calling the cycle detection logic under
> + * certain conditions. There's always some corner case that won't get
> + * detected.
> */
> - if (!device_link_flag_is_sync_state_only(flags) ||
> - flags & DL_FLAG_CYCLE) {
> - device_links_write_lock();
> - if (__fw_devlink_relax_cycles(con, sup_handle)) {
> - __fwnode_link_cycle(link);
> - flags = fw_devlink_get_flags(link->flags);
> - pr_debug("----- cycle: end -----\n");
> - dev_info(con, "Fixed dependency cycle(s) with %pfwf\n",
> - sup_handle);
> - }
> - device_links_write_unlock();
> + device_links_write_lock();
> + if (__fw_devlink_relax_cycles(link->consumer, sup_handle)) {
> + __fwnode_link_cycle(link);
> + pr_debug("----- cycle: end -----\n");
> + pr_info("%pfwf: Fixed dependency cycle(s) with %pfwf\n",
> + link->consumer, sup_handle);
> }
> + device_links_write_unlock();
> +
> + if (con->fwnode == link->consumer)
> + flags = fw_devlink_get_flags(link->flags);
> + else
> + flags = FW_DEVLINK_FLAGS_PERMISSIVE;
>
> if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
> sup_dev = fwnode_get_next_parent_dev(sup_handle);
> --
> 2.47.0.163.g1226f6d8fa-goog
>
On Tue, Nov 05, 2024 at 05:30:20PM -0800, Saravana Kannan wrote:
> On Wed, Oct 30, 2024 at 10:10 AM Saravana Kannan <saravanak@google.com> wrote:
> >
> > In attempting to optimize fw_devlink runtime, I introduced numerous cycle
> > detection bugs by foregoing cycle detection logic under specific
> > conditions. Each fix has further narrowed the conditions for optimization.
> >
> > It's time to give up on these optimization attempts and just run the cycle
> > detection logic every time fw_devlink tries to create a device link.
> >
> > The specific bug report that triggered this fix involved a supplier fwnode
> > that never gets a device created for it. Instead, the supplier fwnode is
> > represented by the device that corresponds to an ancestor fwnode.
> >
> > In this case, fw_devlink didn't do any cycle detection because the cycle
> > detection logic is only run when a device link is created between the
> > devices that correspond to the actual consumer and supplier fwnodes.
> >
> > With this change, fw_devlink will run cycle detection logic even when
> > creating SYNC_STATE_ONLY proxy device links from a device that is an
> > ancestor of a consumer fwnode.
> >
> > Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
> > Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
> > Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > ---
> > drivers/base/core.c | 55 ++++++++++++++++++++-------------------------
> > 1 file changed, 24 insertions(+), 31 deletions(-)
> >
> > Tomi,
> >
> > Thanks for all the testing and debugging help! And do use
> > post-init-providers even with this patch to improve ordering
> > enforcement. I probably should change the cycle log from info to warn in
> > a separate patch :)
> >
> > Greg,
> >
> > I no longer have concerns about pulling this into 6.13. But we can give
> > a week or so to Geert/Francesco to do some additional testing.
> >
> > Geert/Francesco,
>
> Heads up. Greg has pulled this into driver-core git's
> driver-core-testing branch. Which means in a week or two it'll get
> into the actual driver-core-next branch. So, if you want to do
> additional testing, you might want to jump on it soon.
It should now show up in the next linux-next release.
thanks,
greg k-h
© 2016 - 2026 Red Hat, Inc.