Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756314Ab3G3Atf (ORCPT ); Mon, 29 Jul 2013 20:49:35 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:39168 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751725Ab3G3Atd (ORCPT ); Mon, 29 Jul 2013 20:49:33 -0400 MIME-Version: 1.0 In-Reply-To: References: <2469263.vMN09Q7Tzi@flatron> <20130729150124.GS29916@titan.lakedaemon.net> <20130729164905.GB2280@localhost.localdomain> <20130729172339.GT29916@titan.lakedaemon.net> Date: Mon, 29 Jul 2013 20:49:31 -0400 Message-ID: Subject: Re: [Ksummit-2013-discuss] Defining schemas for Device Tree From: "jonsmirl@gmail.com" To: David Lang Cc: Jason Cooper , Dave Martin , Mark Rutland , Tomasz Figa , Wolfram Sang , Grant Likely , Russell King - ARM Linux , Jason Gunthorpe , "devicetree@vger.kernel.org" , Ian Campbell , Pawel Moll , Stephen Warren , Richard Cochran , Domenico Andreoli , "linux-arm-kernel@lists.infradead.org" , James Bottomley , "ksummit-2013-discuss@lists.linuxfoundation.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1549 Lines: 44 On Mon, Jul 29, 2013 at 8:41 PM, David Lang wrote: > On Mon, 29 Jul 2013, Jason Cooper wrote: > >> >>> >>> I don't think that siblings have any defined order in DT. If reading a >>> device tree, there's no guarantee you get nodes or properties out in the >>> same order as the original .dts file. >> >> >> That's why I raised the point. If people think encoding initialization >> order in the DT is a good idea, then we should change the dtc so it >> compiles/decompiles in the same order. > > > if you make the initializaiton order 'magicly' correct by following the > order of the flat representation, how do you reflect the case where > initialization can be overlapped for different devices? I agree with David, using DT to try and eliminate deferred probes isn't a good solution. Overlapped probes and doing probes on multiple CPUs introduces a temporal angle to the problem. Best to just let the deferred probing code dynamically solve the problem. From what I can see the deferred probing solution is working out nicely. Plus there isn't that much code being run in deferred probing. I suspect potential savings (if there even is any) are under a millisecond. > > you are just trading one side of the problem for the other. > > David Lang -- Jon Smirl jonsmirl@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/