At present the uclass pre-remove method is called before the children are removed. But the children may refused to be removed, in whch case the uclass is in a tricky situation. At present we handle this by calling the uclass' post_probe() method. But it seems better to avoid doing anything with the uclass in this case.
Switch the ordering so that we make sure the children can be removed before advising the uclass.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/core/device-remove.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c index 7874d53c843..35b625e7b1f 100644 --- a/drivers/core/device-remove.c +++ b/drivers/core/device-remove.c @@ -172,13 +172,13 @@ int device_remove(struct udevice *dev, uint flags) drv = dev->driver; assert(drv);
- ret = uclass_pre_remove_device(dev); + ret = device_chld_remove(dev, NULL, flags); if (ret) return ret;
- ret = device_chld_remove(dev, NULL, flags); + ret = uclass_pre_remove_device(dev); if (ret) - goto err; + return ret;
/* * Remove the device if called with the "normal" remove flag set, @@ -216,12 +216,6 @@ err_remove: /* We can't put the children back */ dm_warn("%s: Device '%s' failed to remove, but children are gone\n", __func__, dev->name); -err: - ret = uclass_post_probe_device(dev); - if (ret) { - dm_warn("%s: Device '%s' failed to post_probe on error path\n", - __func__, dev->name); - }
return ret; }