of/platform: depopulate devices in the reverse order of creation
PATCH 1/1 of/platform: depopulate devices in the reverse order of creation
If the DT has inter-dependencies, then the devices need to be removed in the right order to avoid removal problems.
Assuming the DT is constructed so that EPROBE_DEFER doesn't happen during creating then a good way to avoid removal problems is reversing the order during depopulation.
--- drivers/of/platform.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
In my specific case I have a gpio driver, followed by a i2c bitbang using that driver. So gpiolib prints an error if it the gpio driver is removed before the gpio client..
drivers/of/platform.c +2 -1
@@ -568,7 +568,8 @@ static int of_platform_device_destroy(struct device *dev, void *data)void of_platform_depopulate (struct device *parent) {if (parent->of_node &&of_node_check_flag (parent->of_node,OF_POPULATED_BUS )) { -device_for_each_child (parent,NULL , of_platform_device_destroy); +device_for_each_child_reverse (parent,NULL , + of_platform_device_destroy);of_node_clear_flag (parent->of_node,OF_POPULATED_BUS ); } }
Signature · 5 lines
2.7.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerQuoted 6 lines · Jason Gunthorpe
If the DT has inter-dependencies, then the devices need to be removed in the right order to avoid removal problems.
Assuming the DT is constructed so that
EPROBE_DEFERdoesn't happen during creating then a good way to avoid removal problems is reversing the order during depopulation.
I assume you mean by sorting the nodes to get lucky with the init order. Not sure I want any patches that help that. I'm tempted to randomize the device creation order instead.
Quoted 8 lines
--- drivers/of/platform.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)In my specific case I have a gpio driver, followed by a i2c bitbang using that driver. So gpiolib prints an error if it the gpio driver is removed before the gpio client..
Good news, functional dependencies are going into 4.10. Let's fix GPIO and use that.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · Rob Herring
Quoted 6 lines · Jason Gunthorpe
If the DT has inter-dependencies, then the devices need to be removed in the right order to avoid removal problems.
Assuming the DT is constructed so that
EPROBE_DEFERdoesn't happen during creating then a good way to avoid removal problems is reversing the order during depopulation.I assume you mean by sorting the nodes to get lucky with the init order.
Not quite, the init order doesn't matter, just that the device list/DT is ordered topologically. The driver bind order can still be randomized. No luck needed.
Quoted 6 lines
Quoted 3 lines
In my specific case I have a gpio driver, followed by a i2c bitbang using that driver. So gpiolib prints an error if it the gpio driver is removed before the gpio client..
Good news, functional dependencies are going into 4.10. Let's fix GPIO and use that.
Sure, but it will be some time until that is used everwhere..
You don't think there is some value in 'hiding' the problem with ordering until that work is done? IIRC that was essentially how EPROBE_DEFER was introduced?
Jason
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerQuoted 10 lines · Jason Gunthorpe
Quoted 9 lines · Rob Herring
Quoted 6 lines · Jason Gunthorpe
If the DT has inter-dependencies, then the devices need to be removed in the right order to avoid removal problems.
Assuming the DT is constructed so that
EPROBE_DEFERdoesn't happen during creating then a good way to avoid removal problems is reversing the order during depopulation.
Quoted 6 lines
Quoted 2 lines
I assume you mean by sorting the nodes to get lucky with the init order.
Not quite, the init order doesn't matter, just that the device list/DT is ordered topologically. The driver bind order can still be randomized. No luck needed.
I meant init in a generic sense
Quoted 15 lines
Quoted 7 lines
Quoted 4 lines
In my specific case I have a gpio driver, followed by a i2c bitbang using that driver. So gpiolib prints an error if it the gpio driver is removed before the gpio client..
Good news, functional dependencies are going into 4.10. Let's fix GPIO and use that.
Sure, but it will be some time until that is used everwhere..
You don't think there is some value in 'hiding' the problem with ordering until that work is done? IIRC that was essentially how
EPROBE_DEFERwas introduced?Jason