[2/2] include: warn for inconsistent endian config definition

On Mon, Jun 12, 2017 at 10:30 PM, Babu Moger <babu.moger@oracle.com> wrote:
>
> Looks like microblaze can be configured to either little or big endian
> formats.  How about
> adding a choice statement to address this.
> Here is my proposed patch.

Hi Babu,

This part looks fine, but I think we also need this one:


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).

        Arnd
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Jun 12, 2017 at 1:51 PM, Arnd Bergmann <arnd@arndb.de> 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.

On 6/12/2017 3:51 PM, Arnd Bergmann wrote:
> On Mon, Jun 12, 2017 at 10:30 PM, Babu Moger <babu.moger@oracle.com> wrote:
>> Looks like microblaze can be configured to either little or big endian
>> formats.  How about
>> adding a choice statement to address this.
>> Here is my proposed patch.
> Hi Babu,
>
> This part looks fine, but I think we also need this one:
>
> diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
> index 740f2b82a182..1f6c486826a0 100644
> --- a/arch/microblaze/Makefile
> +++ b/arch/microblaze/Makefile
> @@ -35,6 +35,8 @@ endif
>   CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
>   CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
>   CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
> +CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
> +CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian
>
>   CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
>
>
> 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.

Ok. Thanks. Arnd. Will update and resend the series.

>
> 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).
>
>          Arnd

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 6/12/2017 3:58 PM, Max Filippov wrote:
> On Mon, Jun 12, 2017 at 1:51 PM, Arnd Bergmann <arnd@arndb.de> 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.
>

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html