Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752921AbdFLVcg (ORCPT ); Mon, 12 Jun 2017 17:32:36 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:36611 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752610AbdFLVcd (ORCPT ); Mon, 12 Jun 2017 17:32:33 -0400 Subject: Re: [PATCH 2/2] include: warn for inconsistent endian config definition To: Max Filippov , Arnd Bergmann Cc: kbuild test robot , kbuild-all@01.org, Yoshinori Sato , Geert Uytterhoeven , Jonas Bonn , Stefan Kristiansson , Stafford Horne , "James E.J. Bottomley" , Helge Deller , David Miller , Al Viro , Michael Ellerman , Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List , "moderated list:H8/300 ARCHITECTURE" , linux-m68k@vger.kernel.org, openrisc@lists.librecores.org, Parisc List , sparclinux , Michal Simek References: <201706102219.7auwXKYx%fengguang.wu@intel.com> <002f7627-1ce5-eabb-967d-fe93a3660f03@oracle.com> From: Babu Moger Organization: Oracle Corporation Message-ID: <7b6059eb-2e8f-a1e9-a3da-59e10617af95@oracle.com> Date: Mon, 12 Jun 2017 16:31:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 970 Lines: 18 On 6/12/2017 3:58 PM, Max Filippov wrote: > On Mon, Jun 12, 2017 at 1:51 PM, Arnd Bergmann wrote: >> That way, we don't have to guess what the toolchain does, but rather >> tell it to do whatever is configured, like we do for most other architectures. >> >> Unfortunately we can't do the same thing on xtensa, as that no longer >> supports the -mbig-endian/-mbig-endian flags in any recent gcc version >> (a long time ago it had them, but they were removed along with many other >> options). > For xtensa we probably need to generate Kconfig fragment that would go > in with the variant subdirectory. That will solve this, and clean up other > options that we currently have for manual selection for xtensa, but there's > actually no choice, i.e. the option has to be selected correctly, there's only > one correct choice and otherwise the kernel either won't build or won't work. > I'll look into it. Max. Thanks. Please update us when you are done. >