From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] kconfig: add CPU endian selection beconfig and leconfig
Date: Mon, 30 Nov 2015 11:26:36 -0800 [thread overview]
Message-ID: <565CA2EC.8050709@gmail.com> (raw)
In-Reply-To: <5658EC0C.1030305@broadcom.com>
On 27/11/15 15:49, Scott Branden wrote:
> Hi Florian,
>
> On 15-11-27 10:39 AM, Florian Fainelli wrote:
>> Le 26/11/2015 11:59, Scott Branden a ?crit :
>>> Add support for switching defconfig between big and little endian CPU.
>>> Various CPU types have ability to select big and little endian
>>> CPU in the kernel configuration.
>>>
>>> "make beconfig" will set CONFIG_CPU_BIG_ENDIAN
>>> "make leconfig" will unset CONFIG_CPU_BIG_ENDIAN
>>
>> I believe I understand what you are trying to achieve here, which is to
>> have an identical defconfig file that you can share between a big-endian
>> and little-endian kernel?
> You understand correct - ARM64 maintainers have only allowed 1 defconfig
> upstream and it supports little endian. And it doesn't make sense to
> have another defconfig with a single line difference upstreamed. Yet
> the defconfig does not allow the system to boot in big endian mode.
>>
>> Is not this something better left to a build system which understands
>> what config fragments are in general?
> Every build system would need to invent their own procedure. By adding
> this into the upstream kernel there is no need to.
> make defconfig
> make beconfig (or make leconfig)
> make
In my experience build systems like OpenWrt, Yocto/OE know about config
fragments, but have a harder time dealing with running multiple make
targets within the Linux source tree...
>>
>> Since we seem to have support for fragments now with kvm and friends,
>> having this does not seem to be a big stretch though.
> Yes, that is why I proposed place it in a common location.
Fair enough.
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Scott Branden <sbranden@broadcom.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: bcm-kernel-feedback-list@broadcom.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/1] kconfig: add CPU endian selection beconfig and leconfig
Date: Mon, 30 Nov 2015 11:26:36 -0800 [thread overview]
Message-ID: <565CA2EC.8050709@gmail.com> (raw)
In-Reply-To: <5658EC0C.1030305@broadcom.com>
On 27/11/15 15:49, Scott Branden wrote:
> Hi Florian,
>
> On 15-11-27 10:39 AM, Florian Fainelli wrote:
>> Le 26/11/2015 11:59, Scott Branden a écrit :
>>> Add support for switching defconfig between big and little endian CPU.
>>> Various CPU types have ability to select big and little endian
>>> CPU in the kernel configuration.
>>>
>>> "make beconfig" will set CONFIG_CPU_BIG_ENDIAN
>>> "make leconfig" will unset CONFIG_CPU_BIG_ENDIAN
>>
>> I believe I understand what you are trying to achieve here, which is to
>> have an identical defconfig file that you can share between a big-endian
>> and little-endian kernel?
> You understand correct - ARM64 maintainers have only allowed 1 defconfig
> upstream and it supports little endian. And it doesn't make sense to
> have another defconfig with a single line difference upstreamed. Yet
> the defconfig does not allow the system to boot in big endian mode.
>>
>> Is not this something better left to a build system which understands
>> what config fragments are in general?
> Every build system would need to invent their own procedure. By adding
> this into the upstream kernel there is no need to.
> make defconfig
> make beconfig (or make leconfig)
> make
In my experience build systems like OpenWrt, Yocto/OE know about config
fragments, but have a harder time dealing with running multiple make
targets within the Linux source tree...
>>
>> Since we seem to have support for fragments now with kvm and friends,
>> having this does not seem to be a big stretch though.
> Yes, that is why I proposed place it in a common location.
Fair enough.
--
Florian
next prev parent reply other threads:[~2015-11-30 19:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-26 19:59 [PATCH 0/1] kconfig: add CPU endian selection beconfig and leconfig Scott Branden
2015-11-26 19:59 ` Scott Branden
2015-11-26 19:59 ` [PATCH 1/1] " Scott Branden
2015-11-26 19:59 ` Scott Branden
2015-11-27 15:59 ` Arnd Bergmann
2015-11-27 15:59 ` Arnd Bergmann
2015-11-27 23:45 ` Scott Branden
2015-11-27 23:45 ` Scott Branden
2015-11-27 18:39 ` Florian Fainelli
2015-11-27 18:39 ` Florian Fainelli
2015-11-27 23:49 ` Scott Branden
2015-11-27 23:49 ` Scott Branden
2015-11-30 19:26 ` Florian Fainelli [this message]
2015-11-30 19:26 ` Florian Fainelli
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=565CA2EC.8050709@gmail.com \
--to=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.