[PATCH] of/platform: depopulate devices in the reverse order of creation

[PATCH] of/platform: depopulate devices in the reverse order of creation

[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_DEFER doesn't happen
during creating then a good way to avoid removal problems is reversing
the order during depopulation.

Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
 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..

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index cd72c0156db2ba..5720fe44f991e9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -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);
 	}
 }
-- 
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: depopulate devices in the reverse order of creation

[Rob Herring]

On Mon, Dec 12, 2016 at 12:39 PM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> 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.

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.

> Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> ---
>  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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: depopulate devices in the reverse order of creation

[Jason Gunthorpe]

On Wed, Dec 14, 2016 at 02:54:02PM -0600, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 12:39 PM, Jason Gunthorpe
> <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> > 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.
> 
> 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.

> > 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: depopulate devices in the reverse order of creation

[Rob Herring]

On Wed, Dec 14, 2016 at 3:40 PM, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> On Wed, Dec 14, 2016 at 02:54:02PM -0600, Rob Herring wrote:
>> On Mon, Dec 12, 2016 at 12:39 PM, Jason Gunthorpe
>> <jgunthorpe@obsidianresearch.com> wrote:
>> > 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.
>>
>> 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
>
>> > 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