[patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.

[Michael Ellerman]

On Tue, 2006-04-18 at 11:48 -0500, Jon Loeliger wrote:
> On Thu, 2006-04-13 at 09:34, Michael Ellerman wrote:
> > On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
> > > Actually, is this even an issue? can the LMB handle repeated  
> > > reservations?
> > 
> > It can, but we were thinking about adding code to check and warn if
> > reservations overlap, because it usually indicates a bug. Although
> > that's probably ok in this case, as long as dtc gets fixed eventually.
> > Another option would be to not warn for identical reservations.
> 
> > > >>>>> NOTE: that the dtc must also not generate the blob reservation
> > > >>>>> entry.
> 
> > > >> looking passed my own world I see:
> > > >>    - iSeries: not reserving the blob at all
> > > >
> > > > That sounds right. I think having the kernel do it is definitely the
> > > > right option.
> 
> 
> OK, I'm back to reading the list and beginning to catch
> up some here...
> 
> Let me see if I understand the consensus and direction:
> 
>     1) DTC should NOT reserve its own blob space in the
>        memory map, as it does for generated ASM code now,
> 
>     2) Kernel should reserve the blob space early so as
>        not to step on itself later,
> 
>     3a) Kernel LMB handling should be modified to warn
>         for overlapping LMB reservations,
> 
> Except that Ben says:
> 
>     3b) We should make lmb_reserve() of redudant/overlapping
>         entries become harmless I think. We need to be
>         backward compatible with earlier blobs that do
>         contain themselves in the reserve map.
> 
> I think we should interpret "harmless" to be "warn" and not
> cause an error at this point in time.
> 
> I do not think we should have the blob generate its own
> reservation because it is possible that some post-processing
> (like U-Boot) can modify and extend it.  Only after that can
> the blob's true size be determined.  (Sure, it could update
> on the fly too... but double blah).
> 
> In all of this, I'm on deck for step 1) above.

Nice summary :)
I'm up for 3a, we should make redundant/overlapping reserves "harmless",
by which I mean "not an error", but there should definitely be a warning
in the dmesg - as it will _usually_ indicate a bug.

cheers

-- 
Michael Ellerman
IBM OzLabs

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20060418/6e8c3a37/attachment.pgp>