From: Yuho Choi <oss.patchbox@gmail.com>
To: u-boot@lists.u-boot-project.org
Cc: sjg@chromium.org, trini@konsulko.com, peng.fan@nxp.com,
Yuho Choi <oss.patchbox@gmail.com>
Subject: [PATCH] dm: core: Unlink the device when bind fails without DM_DEVICE_REMOVE
Date: Sun, 25 Oct 2026 23:09:22 -0400 [thread overview]
Message-ID: <20261026030925.1002846-1-oss.patchbox@gmail.com> (raw)
device_bind_common() adds the new device to its parent's list of
children and to its uclass before it calls the bind methods. If one of
them fails, the error path takes the device off both lists again, but
only when DM_DEVICE_REMOVE is enabled. The free(dev) at the end of the
error path is unconditional, so without DM_DEVICE_REMOVE the freed
device stays on both lists.
DM_DEVICE_REMOVE is disabled by default in SPL, and a failing bind is
not unusual there: lists_bind_fdt() takes -ENODEV from a bind method as
the driver refusing the node and goes on with the next driver. For
example cadence_ttc_bind() refuses TTC nodes that have a #pwm-cells
property so that the PWM driver binds them instead. Any later walk of
the parent's children or of the uclass then finds a device that was
freed. With the simple malloc() the memory is not reused, but the
refused device can still be found and probed through its uclass; with
a full malloc() the memory is handed out again.
Taking the device off the two lists only needs two list_del() calls, so
do it regardless of DM_DEVICE_REMOVE. The remaining clean-up, which only
frees memory, stays conditional as before.
Fixes: 5a87c4174d18 ("dm: core: Drop device removal error path when not supported")
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
---
drivers/core/device.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 6024534ff93..ea7beeb662d 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -206,10 +206,13 @@ fail_bind:
dm_warn("Failed to unbind dev '%s' on error path\n",
dev->name);
}
+ } else {
+ /* dev is freed below, so it must not stay in the uclass */
+ list_del(&dev->uclass_node);
}
fail_uclass_bind:
+ list_del(&dev->sibling_node);
if (CONFIG_IS_ENABLED(DM_DEVICE_REMOVE)) {
- list_del(&dev->sibling_node);
if (dev_get_flags(dev) & DM_FLAG_ALLOC_PARENT_PDATA) {
free(dev_get_parent_plat(dev));
dev_set_parent_plat(dev, NULL);
--
2.43.0
next reply other threads:[~2026-10-26 5:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 3:09 Yuho Choi [this message]
2026-10-27 13:28 ` [PATCH] dm: core: Unlink the device when bind fails without DM_DEVICE_REMOVE Simon Glass
2026-10-27 14:21 ` Yuho Choi
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=20261026030925.1002846-1-oss.patchbox@gmail.com \
--to=oss.patchbox@gmail.com \
--cc=peng.fan@nxp.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.u-boot-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.