From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] powerpc/fsl-corenet: remove dead variant symbols
Date: Wed, 15 Aug 2012 12:19:59 -0500 [thread overview]
Message-ID: <502BDA3F.2000303@freescale.com> (raw)
In-Reply-To: <EB3A7B1D-A012-44FD-9754-6A902FEF0B82@kernel.crashing.org>
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
next prev parent reply other threads:[~2012-08-15 17:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 20:14 [U-Boot] [PATCH 1/3] powerpc/fsl-corenet: remove dead variant symbols Scott Wood
2012-08-14 20:14 ` [U-Boot] [PATCH 2/3] powerpc/85xx: clear out TLB on boot Scott Wood
2012-08-20 22:25 ` [U-Boot] [PATCH v2] " Scott Wood
2012-08-20 23:10 ` [U-Boot] [PATCH v3] " Scott Wood
2012-08-21 9:37 ` Prabhakar Kushwaha
2012-08-14 20:14 ` [U-Boot] [PATCH 3/3] powerpc/fsl-corenet: work around erratum A004510 Scott Wood
2012-08-14 21:31 ` [U-Boot] [PATCH 1/3] powerpc/fsl-corenet: remove dead variant symbols Kumar Gala
2012-08-14 21:45 ` Scott Wood
2012-08-15 14:21 ` Kumar Gala
2012-08-15 17:19 ` Scott Wood [this message]
2012-08-17 17:52 ` Kumar Gala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502BDA3F.2000303@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox