Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756765AbcLNUy2 (ORCPT ); Wed, 14 Dec 2016 15:54:28 -0500 Received: from mail.kernel.org ([198.145.29.136]:39210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753022AbcLNUy0 (ORCPT ); Wed, 14 Dec 2016 15:54:26 -0500 MIME-Version: 1.0 In-Reply-To: <20161212183905.GA30702@obsidianresearch.com> References: <20161212183905.GA30702@obsidianresearch.com> From: Rob Herring Date: Wed, 14 Dec 2016 14:54:02 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] of/platform: depopulate devices in the reverse order of creation To: Jason Gunthorpe Cc: Frank Rowand , Pawel Moll , Grant Likely , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 994 Lines: 26 On Mon, Dec 12, 2016 at 12:39 PM, Jason Gunthorpe 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 > --- > 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