[PATCH v3] arch: Kconfig: Let all architectures set endian explicitly

[Ralf Baechle]

- Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc
- Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300,
score, unicore32, x86
- Choose in config time: arc, arm, arm64, c6x, m32r, mips, powerpc, sh

Nak for MIPS. On MIPS Kconfig already always sets one of CPU_BIG_ENDIAN
and CPU_LITTLE_ENDIAN depending on platforms and where both endianess are
supported by a platform, user choice:

config FOO
bool "foo"
select SYS_SUPPORTS_LITTLE_ENDIAN

config FOO
bool "foo"
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
[...]
choice
prompt "Endianess selection"
help
Some MIPS machines can be configured for either little or big endian
byte order. These modes require different kernels and a different
Linux distribution. In general there is one preferred byteorder for a
particular system but some systems are just as commonly used in the
one or the other endianness.

config CPU_BIG_ENDIAN
bool "Big endian"
depends on SYS_SUPPORTS_BIG_ENDIAN

config CPU_LITTLE_ENDIAN
bool "Little endian"
depends on SYS_SUPPORTS_LITTLE_ENDIAN
help

endchoice

So I think you can just drop the MIPS segment from your patch.

Ralf

[Chen Gang]

Post by Ralf Baechle

- Big endian: avr32, frv, m68k, openrisc, parisc, s390, sparc
- Little endian: alpha, blackfin, cris, hexagon, ia64, metag, mn10300,
score, unicore32, x86
- Choose in config time: arc, arm, arm64, c6x, m32r, mips, powerpc, sh

Nak for MIPS. On MIPS Kconfig already always sets one of CPU_BIG_ENDIAN
and CPU_LITTLE_ENDIAN depending on platforms and where both endianess are
config FOO
bool "foo"
select SYS_SUPPORTS_LITTLE_ENDIAN
config FOO
bool "foo"
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
[...]
choice
prompt "Endianess selection"
help
Some MIPS machines can be configured for either little or big endian
byte order. These modes require different kernels and a different
Linux distribution. In general there is one preferred byteorder for a
particular system but some systems are just as commonly used in the
one or the other endianness.
config CPU_BIG_ENDIAN
bool "Big endian"
depends on SYS_SUPPORTS_BIG_ENDIAN
config CPU_LITTLE_ENDIAN
bool "Little endian"
depends on SYS_SUPPORTS_LITTLE_ENDIAN
help
endchoice

OK, thanks, I assumes when support both endian, the default choice is
CPU_BIG_ENDIAN, although no default value for choice (originally, I did
worry about it).

Post by Ralf Baechle
So I think you can just drop the MIPS segment from your patch.

If what I assumes is correct, what you said sounds reasonable to me.


Thanks.

[Chen Gang]

Post by Chen Gang
OK, thanks, I assumes when support both endian, the default choice is
CPU_BIG_ENDIAN, although no default value for choice (originally, I did
worry about it).

Post by Ralf Baechle
So I think you can just drop the MIPS segment from your patch.

If what I assumes is correct, what you said sounds reasonable to me.

So for me, it is harmless to add CPU_*_ENDIAN explicitly, and can let
other members don't need think of.

By the way, for sh, it is almost the same case, except it contents the
default value, for me, it is clear enough, so I skip sh architecture in
this patch.


Thanks

[Chen Gang]

Hello Maintainers:

Is this patch OK? If it pass basic checking, please let me know, and I
shall try to make another related patch for KBuild (I can do nothing
related with Kbuild, before get confirmation for this patch).

Thanks.

Post by Chen Gang

Post by Chen Gang
OK, thanks, I assumes when support both endian, the default choice is
CPU_BIG_ENDIAN, although no default value for choice (originally, I did
worry about it).

Post by Ralf Baechle
So I think you can just drop the MIPS segment from your patch.

If what I assumes is correct, what you said sounds reasonable to me.

So for me, it is harmless to add CPU_*_ENDIAN explicitly, and can let
other members don't need think of.
By the way, for sh, it is almost the same case, except it contents the
default value, for me, it is clear enough, so I skip sh architecture in
this patch.
Thanks

[Chen Gang]

Hello all:

It seems no any additional rejections for it. I guess, I need split the
'big' patch into pieces, and each send to its' related mailing list, so
let it not like a spam. And the schedule may like:

- Firstly, send patch for "init/Kconfig" to add CPU_*_ENDIAN. If pass
checking (hope it can be passed checking), then

- Send each related patch to each related architectures which already
knew their ENDIAN attributes in config time (24 patches, I guess),
then

- Make patch for Kbuild to support __BUILDING_TIME_BIG_ENDIAN__, and
pass checking (hope I can finish), then

- Finish left architectures which need __BUILDING_TIME_BIG_ENDIAN__
(4 patches, I guess).

Welcome any ideas, suggestions, or completions. And if no additional
reply, I shall not send any additional information any more to avoid
spam to other members.


Thanks.

Post by Chen Gang
Is this patch OK? If it pass basic checking, please let me know, and I
shall try to make another related patch for KBuild (I can do nothing
related with Kbuild, before get confirmation for this patch).
Thanks.

Post by Chen Gang

Post by Chen Gang
OK, thanks, I assumes when support both endian, the default choice is
CPU_BIG_ENDIAN, although no default value for choice (originally, I did
worry about it).

Post by Ralf Baechle
So I think you can just drop the MIPS segment from your patch.

If what I assumes is correct, what you said sounds reasonable to me.

So for me, it is harmless to add CPU_*_ENDIAN explicitly, and can let
other members don't need think of.
By the way, for sh, it is almost the same case, except it contents the
default value, for me, it is clear enough, so I skip sh architecture in
this patch.
Thanks