linux-kernel - Re: [Ksummit-2013-discuss] Defining schemas for Device Tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKON4Ow2KMC_9xod3Ay51Yetg9RbfMxVcy4DH0A3baHpmxP+7A@mail.gmail.com>
Date:	Mon, 29 Jul 2013 20:49:31 -0400
From:	"jonsmirl@...il.com" <jonsmirl@...il.com>
To:	David Lang <david@...g.hm>
Cc:	Jason Cooper <jason@...edaemon.net>,
	Dave Martin <Dave.Martin@....com>,
	Mark Rutland <mark.rutland@....com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Wolfram Sang <w.sang@...gutronix.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Pawel Moll <pawel.moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Richard Cochran <richardcochran@...il.com>,
	Domenico Andreoli <cavokz@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2013-discuss] Defining schemas for Device Tree

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