From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 15 Aug 2012 12:19:59 -0500 Subject: [U-Boot] [PATCH 1/3] powerpc/fsl-corenet: remove dead variant symbols In-Reply-To: References: <1344975293-5185-1-git-send-email-scottwood@freescale.com> <9313E28A-A573-40E3-AE17-3504C0F8D61D@kernel.crashing.org> <502AC6FA.6020408@freescale.com> Message-ID: <502BDA3F.2000303@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>> --- >>>> 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 ". 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