On Mon, Jul 29, 2013 at 8:41 PM, David Lang <da...@lang.hm> 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 jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
