Dear Scott Wood,
In message 20110131151506.700ddcd7@udp111988uds.am.freescale.net you wrote:
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?
Yes, this is better, and this is how we always do it: add the featurs, but not enable them unless we have all together, then add the needed #defines and make rules to actually use the code.
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
A dead / broken make rule and dead documentation is what the generic infrastructure for TPL consists of?
if you want it squashed into a board-specific patch instead, fine. Just tell us what you want to see.
I already did, but here we go:
First, please do not add make rules before you have code they apply to. After doing this, there is this rudimentary patch to the README.
From a strictly technical point of view it should be split nto two
parts: the first one (documenting the existing NAND_SPL variables) is independent of the TPL stuff and could be handles separately. The second part should be mergeed into the patch that first uses these variables. Note that I do not insist on splitting the README changes. It's OK with me to keep this together.
Best regards,
Wolfgang Denk