[U-Boot] [PATCH0/6] patchset to support TPL and P1021MDS board
Scott Wood
scottwood at freescale.com
Mon Jan 31 22:15:06 CET 2011
On Mon, 31 Jan 2011 21:50:57 +0100
Wolfgang Denk <wd at denx.de> wrote:
> Dear Scott Wood,
>
> In message <20110131143141.2959da63 at udp111988uds.am.freescale.net> you wrote:
> >
> > I'm confused. You say "of course not all together", but the first one
> > you say to include with the second, and the second you say to include
> > with the third.
>
> I did not say this.
"WHy not add the tpl target when you actually add the tpl code?"
"Then this is where that file belongs to."
> > Has your aversion to "dead" code grown so strong it can't exist even in
> > a transitory state between members of a patchset, even when necessary
> > to avoid mixing users of a facility with the facility itself in the
> > same patch? I think that would do significant harm to reviewability.
>
> Calm down, and re-read what I wrote.
I am calm, albeit confused and a bit frustrated.
I did re-read it and I'm still not sure exactly what you want.
> For example, why must we add the Makefile changes in the first step,
> when all the code it references is still missing? Should this not be
> the last step?
If you make it the last step, then the board will exist but not be
buildable in the previous step (unless you combine them, but you said
that's not what you're asking for). How is that better? And is this
really worth bickering about?
Please just say, clearly and specifically, what you want the patchset
to look like...
> And what is the benefit of adding documentation to the README here?
> To me it makes more sense to add this when CONFIG_HAS_TPL and
> CONFIG_IN_TPL get used first.
Because it's not specific to 85xx or p1021mds. The generic
infrastructure for TPL consists of the makefile changes and
documentation. It seems useful to me to separate that for review, but
if you want it squashed into a board-specific patch instead, fine.
Just tell us what you want to see.
-Scott
More information about the U-Boot
mailing list