On Monday 05 October 2009, Paulraj, Sandeep wrote: > > I have already ack-ed Sandeep's patch that contains this > > fix for the warning. Please check with him. > > That is correct, I did not add it to my tree because you ACK'ed > this patch only after I sent a pull request. So obviously I cannot > add a patch that has been ACK'ed to an already existing pull request.
A "pull <this ID>" request wouldn't have been changed by adding another commit to that tree. You could however have sent an updated pull request, with both. That would result in a tree that *builds* properly... > This will be part of my next pull request which will have a similar > fix for DM365 and hopefully the EMAC support for DM365 which should > result in a fully functional DM365 EVM support. That would be nice. I'll still want the updated CPLD bits, which pass SRST through from the JTAG adapter though; that is obviously not a U-Boot issue. ;) > > In general it is better to break patches that do multiple things into > > multiple patches. When you resubmit, please break this patch into its > > logical parts : > > 1. NAND > > 2. Environment > > 3. Bootdelay > > > > Tom > > If the u-boot-ti tree or the u-boot-arm tree is checked, all the above > features which are being added are already in both trees. I guess that happened after I prepared the patch but before I sent it in. I'll look; there were some differences still. Notably to store the environment in the otherwise-unused block zero, and work better with the small-page NANDs I've got handy. > When Tom sends a pull request to Wolfgang it should become part of > Wolfgang's tree as well. > > Afcourse it does not have the 64 bit VSPRINTf for which I was > going to submit a patch anyway. That's important ... it doesn't work right without that patch. When you erase or protect blocks, the diagnostics are broken since they give bogus addresses. - Dave _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot