All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cody P Schafer <cody@linux.vnet.ibm.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/2] powerpc64 powerpc64le: add support
Date: Mon, 12 May 2014 12:17:09 -0700	[thread overview]
Message-ID: <53711E35.9020603@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140511234912.7b70a9c2@free-electrons.com>

On 05/11/2014 02:49 PM, Thomas Petazzoni wrote:

> Generally speaking, I believe it would be nice if this patch could be
> split into smaller patches. This would also ease their way for merging.
> I'll try to suggest approaches to split it up while reviewing it, below.

yep, will do.

[...]

>> +config BR2_POWERPC_CPU_HAS_SPE
>> +	bool
>> +
>> +config BR2_POWERPC
>> +	bool
>> +	default y if BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le
>
> I see what you want to do, but I'm not a big fan of just using a case
> difference between BR2_POWERPC and BR2_powerpc. Unfortunately, I don't
> really have a great proposal to make here. One possibility would be to
> rename the current BR2_powerpc to BR2_powerpcbe, and then use
> BR2_powerpc64be instead of BR2_powerpc64. Then BR2_powerpc would be
> available as a common option for all PowerPC architectures. But that
> requires a fairly significant rename, so before implementing it, I'd
> suggest you wait a bit to see if there's a consensus around this
> proposal or not.

I don't like the BR2_powerpcbe change as it would mean the arch name and 
config option wouldn't be the same, potentially causing even more 
confusion than the switched caps mechanism I went with.

> In any case, introducing this common BR2_POWERPC or BR2_powerpc option
> could be done as a separate, preliminary patch. This way, a good number
> of the package related changes to use BR2_POWERPC could be made before
> introducing the PPC64 support.

I avoided using BR2_POWERPC in packages as generally when a new ppc 
variant is added they'll need to be updated to support it.

>>   choice
>>   	prompt "Target Architecture Variant"
>> -	depends on BR2_powerpc
>> +	depends on BR2_POWERPC
>
> Not your fault, but since the file containing this is only included
> when BR2_powerpc is defined, I'm not sure to see why we have this
> 'depends on' here.
>

Yep, I'll remove these. This also removes much of the point of 
BR2_POWERPC, so I think I'll nuke it as well in v2.

[... removed a bunch of acks to your suggestions hidden in a mountain of 
code ...]

      reply	other threads:[~2014-05-12 19:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-11 21:11 [Buildroot] [PATCH v2 1/2] powerpc64 powerpc64le: add support Cody P Schafer
2014-05-11 21:11 ` [Buildroot] [PATCH v2 2/2] package/gdb: add gdb 7.7.1 Cody P Schafer
2014-05-11 21:54   ` Thomas Petazzoni
2014-05-12 19:08     ` Cody P Schafer
2014-05-12 19:21       ` Thomas Petazzoni
2014-05-12 19:25         ` Cody P Schafer
2014-05-11 21:49 ` [Buildroot] [PATCH v2 1/2] powerpc64 powerpc64le: add support Thomas Petazzoni
2014-05-12 19:17   ` Cody P Schafer [this message]

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=53711E35.9020603@linux.vnet.ibm.com \
    --to=cody@linux.vnet.ibm.com \
    --cc=buildroot@busybox.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.