Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753790AbcLNVkY (ORCPT ); Wed, 14 Dec 2016 16:40:24 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:47752 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751014AbcLNVkX (ORCPT ); Wed, 14 Dec 2016 16:40:23 -0500 Date: Wed, 14 Dec 2016 14:40:12 -0700 From: Jason Gunthorpe To: Rob Herring Cc: Frank Rowand , Pawel Moll , Grant Likely , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] of/platform: depopulate devices in the reverse order of creation Message-ID: <20161214214012.GB6947@obsidianresearch.com> References: <20161212183905.GA30702@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1212 Lines: 31 On Wed, Dec 14, 2016 at 02:54:02PM -0600, Rob Herring wrote: > 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 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