[U-Boot-Users] [PATCH] RFC: generic property fixup mechanism for LIBFDT

Kim Phillips kim.phillips at freescale.com
Thu Aug 23 18:24:04 CEST 2007


On Wed, 22 Aug 2007 19:16:16 -0400
Jerry Van Baren <vanbargw at gmail.com> wrote:

> Kim Phillips wrote:
> > On Wed, 22 Aug 2007 09:18:20 -0400
> > Jerry Van Baren <gerald.vanbaren at smiths-aerospace.com> wrote:
> > 
> >> IMO your proposal is not acceptable.  Follow Grant's advice and the 
> >> current cpu/mpc83xx/cpu.c methodology.
> > 
> > ?  Bartlomiej's first patch followed the 83xx 'methodology', which Grant
> > commented on, which is what Bartlomiej tried to fix here.  Maybe I
> > missed something, but anyway, now that the window has closed, we can
> > arrange to fix libfdt support for all powerpc boards for the next
> > release.
> 
> Well, perhaps Grant can speak to the issue better than me, but I read 
> Grant's reply as a request to coelesce the four "setter" functions into 
> one, not to remove all setter functions and change it back to the 
> original table mechanism.  IMHO, using hardcoded [0] [1]... indexes is 

sounds good.  Thanks for clarifying this.

> > What about having a list of functions to call?  It could be called
> > something like fdt_update_sequence, and be similar in implementation to
> > lib_ppc/board.c's init_sequence.  It could also reside in lib_ppc,
> > esp. since, e.g. all powerpc's have a timebase, and to help naturally
> > enforce a certain level of consistency among powerpc board code.  The
> > updater/fixup/"setter" functions would only need be passed the pointer
> > to the base of the blob to update.
> 
> We _have_ "a list of functions to call".  That is what is done with the 
> 83xx which is what I advocated and what Bartlomiej had before rewriting 
> it back into a table without functions.

yeah, I meant /just/ a list of functions to call, without all the extra
fluff in both the existing 83xx and Bartlomiej's implementations.

Kim




More information about the U-Boot mailing list