[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