Compiling bpf_skel for mips currently fails because clang --target=bpf
is invoked and the source files include byteorder.h, which uses the
MIPS-specific macros to determine the endianness, rather than the generic
__LITTLE_ENDIAN__ / __BIG_ENDIAN__. Fix this by using the generic
macros, which are also defined when targeting bpf. This is already done
similarly for powerpc.

Signed-off-by: Jens Reidel <adrian@mainlining.org>
---
 arch/mips/include/uapi/asm/byteorder.h | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/mips/include/uapi/asm/byteorder.h b/arch/mips/include/uapi/asm/byteorder.h
index b4edc85f9c30c09aafbc189ec820e6e2f7cbe0d8..5e3c3baa24994a9f3637bf2b63ea7c3577cae541 100644
--- a/arch/mips/include/uapi/asm/byteorder.h
+++ b/arch/mips/include/uapi/asm/byteorder.h
@@ -9,12 +9,10 @@
 #ifndef _ASM_BYTEORDER_H
 #define _ASM_BYTEORDER_H
 
-#if defined(__MIPSEB__)
-#include <linux/byteorder/big_endian.h>
-#elif defined(__MIPSEL__)
+#ifdef __LITTLE_ENDIAN__
 #include <linux/byteorder/little_endian.h>
 #else
-# error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
+#include <linux/byteorder/big_endian.h>
 #endif
 
 #endif /* _ASM_BYTEORDER_H */

---
base-commit: 9c0826a5d9aa4d52206dd89976858457a2a8a7ed
change-id: 20251108-mips-bpf-fix-8d1f14bc4903

Best regards,
-- 
Jens Reidel <adrian@mainlining.org>

On Sat, Nov 08, 2025 at 11:05:55PM +0100, Jens Reidel wrote:
> Compiling bpf_skel for mips currently fails because clang --target=bpf
> is invoked and the source files include byteorder.h, which uses the
> MIPS-specific macros to determine the endianness, rather than the generic
> __LITTLE_ENDIAN__ / __BIG_ENDIAN__. Fix this by using the generic
> macros, which are also defined when targeting bpf. This is already done
> similarly for powerpc.
> 
> Signed-off-by: Jens Reidel <adrian@mainlining.org>

As far as I can tell, this should be fine since clang defines these
macros in the generic case since [1] and I assume GCC does as well but
if there is a risk of this being a problem for userspace, these could be
added in addition to __MIPSEB__ / __MIPSEL__.

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

[1]: https://github.com/llvm/llvm-project/commit/2c942c64fb521357ed98c380823e79833a121d18

> ---
>  arch/mips/include/uapi/asm/byteorder.h | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/mips/include/uapi/asm/byteorder.h b/arch/mips/include/uapi/asm/byteorder.h
> index b4edc85f9c30c09aafbc189ec820e6e2f7cbe0d8..5e3c3baa24994a9f3637bf2b63ea7c3577cae541 100644
> --- a/arch/mips/include/uapi/asm/byteorder.h
> +++ b/arch/mips/include/uapi/asm/byteorder.h
> @@ -9,12 +9,10 @@
>  #ifndef _ASM_BYTEORDER_H
>  #define _ASM_BYTEORDER_H
>  
> -#if defined(__MIPSEB__)
> -#include <linux/byteorder/big_endian.h>
> -#elif defined(__MIPSEL__)
> +#ifdef __LITTLE_ENDIAN__
>  #include <linux/byteorder/little_endian.h>
>  #else
> -# error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
> +#include <linux/byteorder/big_endian.h>
>  #endif
>  
>  #endif /* _ASM_BYTEORDER_H */
> 
> ---
> base-commit: 9c0826a5d9aa4d52206dd89976858457a2a8a7ed
> change-id: 20251108-mips-bpf-fix-8d1f14bc4903
> 
> Best regards,
> -- 
> Jens Reidel <adrian@mainlining.org>

On Sun, 9 Nov 2025, Nathan Chancellor wrote:

> > Compiling bpf_skel for mips currently fails because clang --target=bpf
> > is invoked and the source files include byteorder.h, which uses the
> > MIPS-specific macros to determine the endianness, rather than the generic
> > __LITTLE_ENDIAN__ / __BIG_ENDIAN__. Fix this by using the generic
> > macros, which are also defined when targeting bpf. This is already done
> > similarly for powerpc.
> > 
> > Signed-off-by: Jens Reidel <adrian@mainlining.org>
> 
> As far as I can tell, this should be fine since clang defines these
> macros in the generic case since [1] and I assume GCC does as well but
> if there is a risk of this being a problem for userspace, these could be
> added in addition to __MIPSEB__ / __MIPSEL__.

 How was the change verified?

 Certainly GCC defines neither __BIG_ENDIAN__ nor __LITTLE_ENDIAN__, not 
at least for the MIPS target.  Either the current macros need to stay as 
they are, or the generic __BYTE_ORDER__ macro can be used instead if so 
desired, which is target-agnostic and well-documented.  Preferably with 
the #else clause retained.

 Why is a MIPS header used with another target anyway?  It seems like a 
bug elsewhere.  If it's not a bug indeed, for whatever odd reason, then a 
proper rationale needs to be given in the change description.

 Also please don't review changes based on assumptions, "I assume GCC 
does[...]" means that you just don't know (and it's trivial to check).

 NB the __BYTE_ORDER__ macro has only been there as from GCC 4.6 back in 
2010, while this header dates back to 1995 when it was necessary to use 
target macros.  Since our current GCC requirement is 5.1 it will be fine 
to use this macro instead.  But as I say a proper rationale is required.

  Maciej

On Mon, Nov 10, 2025 at 01:34:19AM +0000, Maciej W. Rozycki wrote:
>  Also please don't review changes based on assumptions, "I assume GCC 
> does[...]" means that you just don't know (and it's trivial to check).

Yes, that is totally valid. I hastily reviewed this when I should have
taken the time to check but I did not have a MIPS cross compiler
available locally to test and I forgot that I can use Godbolt for that
test. I'll be more mindful of that in the future (or at least being
clear that I did not actually check but it should be verified before the
change is merged without providing a tag).

> target macros.  Since our current GCC requirement is 5.1 it will be fine 

Just an FYI, the minimum GCC version is 8.1 since commit 118c40b7b503
("kbuild: require gcc-8 and binutils-2.30") in 6.16.

Cheers,
Nathan

On Mon, 10 Nov 2025, Nathan Chancellor wrote:

> >  Also please don't review changes based on assumptions, "I assume GCC 
> > does[...]" means that you just don't know (and it's trivial to check).
> 
> Yes, that is totally valid. I hastily reviewed this when I should have
> taken the time to check but I did not have a MIPS cross compiler
> available locally to test and I forgot that I can use Godbolt for that
> test. I'll be more mindful of that in the future (or at least being
> clear that I did not actually check but it should be verified before the
> change is merged without providing a tag).

 Well, `info cpp' would have sufficed, no need for a cross-compiler here.

> > target macros.  Since our current GCC requirement is 5.1 it will be fine 
> 
> Just an FYI, the minimum GCC version is 8.1 since commit 118c40b7b503
> ("kbuild: require gcc-8 and binutils-2.30") in 6.16.

 Indeed, thanks, I looked at an older checkout.

  Maciej