On 08/15/2012 09:21 AM, Kumar Gala wrote:
On Aug 14, 2012, at 4:45 PM, Scott Wood wrote:
On 08/14/2012 04:31 PM, Kumar Gala wrote:
On Aug 14, 2012, at 3:14 PM, Scott Wood wrote:
These are not supported as individual build targets, but instead are supported by another target.
The dead p4040 defines in particular had bitrotted significantly.
Signed-off-by: Scott Wood scottwood@freescale.com
arch/powerpc/cpu/mpc85xx/Makefile | 3 -- arch/powerpc/include/asm/config_mpc85xx.h | 68 ++--------------------------- arch/powerpc/include/asm/immap_85xx.h | 2 +- drivers/net/fm/Makefile | 1 - include/configs/P2041RDB.h | 2 +- include/configs/P4080DS.h | 1 + include/configs/P5020DS.h | 2 +- 7 files changed, 7 insertions(+), 72 deletions(-)
I had put these in for customer specific boards...
Why wouldn't they use the p2041/p4080/p5020 symbol? The point is we support both at runtime.
I understand we might have bit rot, but I guess I'd rather we added:
P2040RDB, P4040DS, and P5010DS to boards.cfg to test these SoC builds than remove the code.
I disagree. That adds extra builds to test and maintain for no real gain.
It was an attempt to try and reduce some confusion for customers if they happen to utilize a P4040/P2040/P5010.
Well, I did add comments saying "this also supports <foo>". I think documentation is the way to deal with this, or maybe a target name alias mechanism if we're really having problems with customers unable to figure this out.
If we do add separate builds I predict they will receive approximately zero test coverage beyond the occasional (now slightly slower) MAKEALL.
We have the same issue with P1/P2 SoCs and single core vs dual core devices.
I'd be happy to see those extra builds go away too.
-Scott