Resending the series per Greg KH's request.
Found this problem while enabling queued rwlock on SPARC.
The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the
specific byte in qrwlock structure. Without this parameter,
we clear the wrong byte.
Here is the code in include/asm-generic/qrwlock.h
static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
{
return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
}
Also found few more references of this parameter in
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c
Here is our previous discussion.
https://lkml.org/lkml/2017/5/24/620
Based on the discussion, it was decided to add CONFIG_CPU_BIG_ENDIAN
for all the fixed big endian architecture(frv, h8300, m68k, openrisc,
parisc and sparc). And warn if there are inconsistencies in this definition.
v2 -> v3:
Added the choice statement for endianness selection for microblaze.
Updated the Makefile for microblaze(Suggested by Arnd Bergmann) to
properly compile for the correct format.
Updated acks.
v1 -> v2:
Updated the commit messages and acks.
Babu Moger (3):
arch: Define CPU_BIG_ENDIAN for all fixed big endian archs
arch/microblaze: Add choice for endianness and update Makefile
include: warn for inconsistent endian config definition
arch/frv/Kconfig | 3 +++
arch/h8300/Kconfig | 3 +++
arch/m68k/Kconfig | 3 +++
arch/microblaze/Kconfig | 16 ++++++++++++++++
arch/microblaze/Makefile | 2 ++
arch/openrisc/Kconfig | 3 +++
arch/parisc/Kconfig | 3 +++
arch/sparc/Kconfig | 3 +++
include/linux/byteorder/big_endian.h | 4 ++++
include/linux/byteorder/little_endian.h | 4 ++++
10 files changed, 44 insertions(+), 0 deletions(-)
While working on enabling queued rwlock on SPARC, found
this following code in include/asm-generic/qrwlock.h
which uses CONFIG_CPU_BIG_ENDIAN to clear a byte.
static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
{
return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
}
Problem is many of the fixed big endian architectures don't define
CPU_BIG_ENDIAN and clears the wrong byte.
Define CPU_BIG_ENDIAN for all the fixed big endian architecture to fix it.
Also found few more references of this config parameter in
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c
Be aware that this may cause regressions if someone has worked-around
problems in the above code already. Remove the work-around.
Here is our original discussion
https://lkml.org/lkml/2017/5/24/620
Signed-off-by: Babu Moger <[email protected]>
Suggested-by: Arnd Bergmann <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: David S. Miller <[email protected]>
Acked-by: Stafford Horne <[email protected]>
---
arch/frv/Kconfig | 3 +++
arch/h8300/Kconfig | 3 +++
arch/m68k/Kconfig | 3 +++
arch/openrisc/Kconfig | 3 +++
arch/parisc/Kconfig | 3 +++
arch/sparc/Kconfig | 3 +++
6 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index eefd9a4..1cce824 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -17,6 +17,9 @@ config FRV
select HAVE_DEBUG_STACKOVERFLOW
select ARCH_NO_COHERENT_DMA_MMAP
+config CPU_BIG_ENDIAN
+ def_bool y
+
config ZONE_DMA
bool
default y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 3ae8525..5380ac8 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -23,6 +23,9 @@ config H8300
select HAVE_ARCH_HASH
select CPU_NO_EFFICIENT_FFS
+config CPU_BIG_ENDIAN
+ def_bool y
+
config RWSEM_GENERIC_SPINLOCK
def_bool y
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index d140206..029a58b 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -23,6 +23,9 @@ config M68K
select OLD_SIGSUSPEND3
select OLD_SIGACTION
+config CPU_BIG_ENDIAN
+ def_bool y
+
config RWSEM_GENERIC_SPINLOCK
bool
default y
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 1e95920..a0f2e4a 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -29,6 +29,9 @@ config OPENRISC
select CPU_NO_EFFICIENT_FFS if !OPENRISC_HAVE_INST_FF1
select NO_BOOTMEM
+config CPU_BIG_ENDIAN
+ def_bool y
+
config MMU
def_bool y
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 531da9e..dda1f55 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -47,6 +47,9 @@ config PARISC
and later HP3000 series). The PA-RISC Linux project home page is
at <http://www.parisc-linux.org/>.
+config CPU_BIG_ENDIAN
+ def_bool y
+
config MMU
def_bool y
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 908f019..0d9dc49 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -92,6 +92,9 @@ config ARCH_DEFCONFIG
config ARCH_PROC_KCORE_TEXT
def_bool y
+config CPU_BIG_ENDIAN
+ def_bool y
+
config ARCH_ATU
bool
default y if SPARC64
--
1.7.1
We have seen some generic code use config parameter CONFIG_CPU_BIG_ENDIAN
to decide the endianness.
Here are the few examples.
include/asm-generic/qrwlock.h
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c
Display warning if CPU_BIG_ENDIAN is not defined on big endian
architecture and also warn if it defined on little endian architectures.
Here is our original discussion
https://lkml.org/lkml/2017/5/24/620
Signed-off-by: Babu Moger <[email protected]>
Suggested-by: Arnd Bergmann <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
---
include/linux/byteorder/big_endian.h | 4 ++++
include/linux/byteorder/little_endian.h | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/byteorder/big_endian.h b/include/linux/byteorder/big_endian.h
index 3920414..ffd2159 100644
--- a/include/linux/byteorder/big_endian.h
+++ b/include/linux/byteorder/big_endian.h
@@ -3,5 +3,9 @@
#include <uapi/linux/byteorder/big_endian.h>
+#ifndef CONFIG_CPU_BIG_ENDIAN
+#warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
+#endif
+
#include <linux/byteorder/generic.h>
#endif /* _LINUX_BYTEORDER_BIG_ENDIAN_H */
diff --git a/include/linux/byteorder/little_endian.h b/include/linux/byteorder/little_endian.h
index 0805737..ba910bb 100644
--- a/include/linux/byteorder/little_endian.h
+++ b/include/linux/byteorder/little_endian.h
@@ -3,5 +3,9 @@
#include <uapi/linux/byteorder/little_endian.h>
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#warning inconsistent configuration, CONFIG_CPU_BIG_ENDIAN is set
+#endif
+
#include <linux/byteorder/generic.h>
#endif /* _LINUX_BYTEORDER_LITTLE_ENDIAN_H */
--
1.7.1
microblaze architectures can be configured for either little or
big endian formats. Add a choice option for the user to select the
correct endian format(default to big endian).
Also update the Makefile so toolchain can compile for the format
it is configured for.
Signed-off-by: Babu Moger <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
arch/microblaze/Kconfig | 16 ++++++++++++++++
arch/microblaze/Makefile | 2 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 85885a5..74aa5de 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -35,6 +35,22 @@ config MICROBLAZE
select VIRT_TO_BUS
select CPU_NO_EFFICIENT_FFS
+# Endianness selection
+choice
+ prompt "Endianness selection"
+ default CPU_BIG_ENDIAN
+ help
+ microblaze architectures can be configured for either little or
+ big endian formats. Be sure to select the appropriate mode.
+
+config CPU_BIG_ENDIAN
+ bool "Big endian"
+
+config CPU_LITTLE_ENDIAN
+ bool "Little endian"
+
+endchoice
+
config SWAP
def_bool n
diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index 740f2b8..1f6c486 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))
--
1.7.1
On Thu, Jul 06, 2017 at 09:34:18AM -0700, Babu Moger wrote:
> Resending the series per Greg KH's request.
>
> Found this problem while enabling queued rwlock on SPARC.
> The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the
> specific byte in qrwlock structure. Without this parameter,
> we clear the wrong byte.
> Here is the code in include/asm-generic/qrwlock.h
>
> static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
> {
> return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
> }
>
> Also found few more references of this parameter in
> drivers/of/base.c
> drivers/of/fdt.c
> drivers/tty/serial/earlycon.c
> drivers/tty/serial/serial_core.c
>
> Here is our previous discussion.
> https://lkml.org/lkml/2017/5/24/620
>
> Based on the discussion, it was decided to add CONFIG_CPU_BIG_ENDIAN
> for all the fixed big endian architecture(frv, h8300, m68k, openrisc,
> parisc and sparc). And warn if there are inconsistencies in this definition.
Did this series ever get picked up by anyone? I don't know whose tree
it should go through if not, anyone have any ideas? I guess I could,
but arch-specific stuff is odd...
thanks,
greg k-h
On Tue, Aug 29, 2017 at 08:30:15AM +0200, Greg KH wrote:
> On Thu, Jul 06, 2017 at 09:34:18AM -0700, Babu Moger wrote:
> > Resending the series per Greg KH's request.
> >
> > Found this problem while enabling queued rwlock on SPARC.
> > The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the
> > specific byte in qrwlock structure. Without this parameter,
> > we clear the wrong byte.
> > Here is the code in include/asm-generic/qrwlock.h
> >
> > static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
> > {
> > return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
> > }
> >
> > Also found few more references of this parameter in
> > drivers/of/base.c
> > drivers/of/fdt.c
> > drivers/tty/serial/earlycon.c
> > drivers/tty/serial/serial_core.c
> >
> > Here is our previous discussion.
> > https://lkml.org/lkml/2017/5/24/620
> >
> > Based on the discussion, it was decided to add CONFIG_CPU_BIG_ENDIAN
> > for all the fixed big endian architecture(frv, h8300, m68k, openrisc,
> > parisc and sparc). And warn if there are inconsistencies in this definition.
>
> Did this series ever get picked up by anyone? I don't know whose tree
> it should go through if not, anyone have any ideas? I guess I could,
> but arch-specific stuff is odd...
Seems like something that akpm would pick up, but it appears people
didn't actually Cc him.