Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 5月, 2020 1 次提交
    • S
      mips: Add MIPS Release 5 support · ab7c01fd
      由 Serge Semin 提交于 
      There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.

Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
  must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
  are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
  ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
  accidentally clearing LL-bit when returning from an interrupt,
  exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
  introduced, which needs to have mfhc0/mthc0 instructions available.

So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.

So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.

Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: NAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: NAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      ab7c01fd
  3. 21 5月, 2020 2 次提交
  5. 20 5月, 2020 2 次提交
  7. 19 5月, 2020 3 次提交
  9. 18 5月, 2020 2 次提交
  11. 17 5月, 2020 6 次提交
  13. 15 5月, 2020 5 次提交
  15. 14 5月, 2020 5 次提交
  17. 13 5月, 2020 3 次提交
  19. 12 5月, 2020 5 次提交
    • N
      MIPS: VDSO: Allow ld.lld to link the VDSO · 22235ef3
      由 Nathan Chancellor 提交于 
      Currently, when linking with ld.lld, this warning pops up:

    arch/mips/vdso/Makefile:70: MIPS VDSO requires binutils >= 2.25

CONFIG_LD_VERSION is set with scripts/ld-version.sh, which is specific
to GNU ld. It returns 0 for ld.lld so CONFIG_MIPS_LD_CAN_LINK_VDSO does
not set.

ld.lld has a completely different versioning scheme (as it follows
LLVM's versioning) and it does not have the issue mentioned in the
comment block so it should be allowed to link the VDSO.

With this patch, the VDSO successfully links and shows P_MIPS_PC32 in
vgettimeofday.o.

$ llvm-objdump -Dr arch/mips/vdso/vgettimeofday.o | grep R_MIPS_PC32
			00000024:  R_MIPS_PC32	_start
			000000b0:  R_MIPS_PC32	_start
			000002bc:  R_MIPS_PC32	_start
			0000036c:  R_MIPS_PC32	_start
			00000468:  R_MIPS_PC32	_start
Reported-by: NDmitry Golovin <dima@golovin.in>
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/785
Link: https://github.com/llvm/llvm-project/commit/e364e2e9ce50c12eb2bf093560e1a1a8544d455aSigned-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      22235ef3
    • N
      MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO · 2ff90699
      由 Nathan Chancellor 提交于 
      Currently, the VDSO is being linked through $(CC). This does not match
how the rest of the kernel links objects, which is through the $(LD)
variable.

When clang is built in a default configuration, it first attempts to use
the target triple's default linker then the system's default linker,
unless told otherwise through -fuse-ld=... We do not use -fuse-ld=
because it can be brittle and we have support for invoking $(LD)
directly. See commit fe00e50b ("ARM: 8858/1: vdso: use $(LD)
instead of $(CC) to link VDSO") and commit 691efbed ("arm64: vdso:
use $(LD) instead of $(CC) to link VDSO") for examples of doing this in
the VDSO.

Do the same thing here. Replace the custom linking logic with $(cmd_ld)
and ldflags-y so that $(LD) is respected. We need to explicitly add two
flags to the linker that were implicitly passed by the compiler:
-G 0 (which comes from ccflags-vdso) and --eh-frame-hdr.

Before this patch (generated by adding '-v' to VDSO_LDFLAGS):

<gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/collect2 \
-plugin <gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/liblto_plugin.so \
-plugin-opt=<gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/lto-wrapper \
-plugin-opt=-fresolution=/tmp/ccGEi5Ka.res \
--eh-frame-hdr \
-G 0 \
-EB \
-mips64r2 \
-shared \
-melf64btsmip \
-o arch/mips/vdso/vdso.so.dbg.raw \
-L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0/64 \
-L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0 \
-L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0/../../../../mips64-linux/lib \
-Bsymbolic \
--no-undefined \
-soname=linux-vdso.so.1 \
-EB \
--hash-style=sysv \
--build-id \
-T arch/mips/vdso/vdso.lds \
arch/mips/vdso/elf.o \
arch/mips/vdso/vgettimeofday.o \
arch/mips/vdso/sigreturn.o

After this patch:

<gcc_prefix>/bin/mips64-linux-ld \
-m elf64btsmip \
-Bsymbolic \
--no-undefined \
-soname=linux-vdso.so.1 \
-EB \
-nostdlib \
-shared \
-G 0 \
--eh-frame-hdr \
--hash-style=sysv \
--build-id \
-T  arch/mips/vdso/vdso.lds \
arch/mips/vdso/elf.o \
arch/mips/vdso/vgettimeofday.o
arch/mips/vdso/sigreturn.o \
-o arch/mips/vdso/vdso.so.dbg.raw

Note that we leave behind -mips64r2. Turns out that ld ignores it (see
get_emulation in ld/ldmain.c). This is true of current trunk and 2.23,
which is the minimum supported version for the kernel:

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldmain.c;hb=aa4209e7b679afd74a3860ce25659e71cc4847d5#l593
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldmain.c;hb=a55e30b51bc6227d8d41f707654d0a5620978dcf#l641

Before this patch, LD=ld.lld did nothing:

$ llvm-readelf -p.comment arch/mips/vdso/vdso.so.dbg | sed 's/(.*//'
String dump of section '.comment':
[     0] ClangBuiltLinux clang version 11.0.0

After this patch, it does:

$ llvm-readelf -p.comment arch/mips/vdso/vdso.so.dbg | sed 's/(.*//'
String dump of section '.comment':
[     0] Linker: LLD 11.0.0
[    62] ClangBuiltLinux clang version 11.0.0

Link: https://github.com/ClangBuiltLinux/linux/issues/785Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      2ff90699
    • N
      MIPS: Unconditionally specify '-EB' or '-EL' · fd9d0ca2
      由 Nathan Chancellor 提交于 
      This was all done to work around a GCC bug that has been fixed after
4.2. The kernel requires GCC 4.6 or newer so remove all of these hacks
and just use the traditional flags.

 $ mips64-linux-gcc --version | head -n1
 mips64-linux-gcc (GCC) 4.6.3

 $ mips64-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE
 #define MIPSEB 1
 #define __MIPSEB__ 1
 #define _MIPSEB 1
 #define __MIPSEB 1

 $ mips64-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE
 #define __MIPSEL__ 1
 #define MIPSEL 1
 #define _MIPSEL 1
 #define __MIPSEL 1

This is necessary when converting the MIPS VDSO to use $(LD) instead of
$(CC) to link because the OUTPUT_FORMAT is defaulted to little endian
and only flips to big endian when '-EB' is set on the command line.
There is no issue currently because the compiler explicitly passes
'-EB' or '-EL' to the linker regardless of whether or not it was
provided by the user. Passing '-v' to VDSO_LDFLAGS shows:

<gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/collect2 ... -EB ...

even though '-EB' is nowhere to be found in KBUILD_CFLAGS. The VDSO
Makefile already supports getting '-EB' or '-EL' from KBUILD_CFLAGS
through a filter directive but '-EB' or '-EL' is not always present.

If we do not do this, we will see the following error when compiling
for big endian:

$ make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64-linux- \
  64r2el_defconfig arch/mips/vdso/
...
mips64-linux-ld: arch/mips/vdso/elf.o: compiled for a big endian system
and target is little endian
mips64-linux-ld: arch/mips/vdso/elf.o: endianness incompatible with that
of the selected emulation
mips64-linux-ld: failed to merge target specific data of file
arch/mips/vdso/elf.o
...

Remove this legacy hack and just use '-EB' and '-EL' unconditionally.
Reported-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      fd9d0ca2
    • N
      MIPS: VDSO: Move disabling the VDSO logic to Kconfig · e91946d6
      由 Nathan Chancellor 提交于 
      After commit 9553d16f ("init/kconfig: Add LD_VERSION Kconfig"), we
have access to GNU ld's version at configuration time. As a result, we
can make it clearer under what configuration circumstances the MIPS VDSO
needs to be disabled.

This is a prerequisite for getting rid of the MIPS VDSO binutils
warning and linking the VDSO when LD is ld.lld. Wrapping the call to
ld-ifversion with CONFIG_LD_IS_LLD does not work because the config
values are wiped away during 'make clean'.
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      e91946d6
    • S
      kbuild: add CONFIG_LD_IS_LLD · b744b43f
      由 Sami Tolvanen 提交于 
      Similarly to the CC_IS_CLANG config, add LD_IS_LLD to avoid GNU ld
specific logic such as ld-version or ld-ifversion and gain the
ability to select potential features that depend on the linker at
configuration time such as LTO.
Signed-off-by: NSami Tolvanen <samitolvanen@google.com>
Acked-by: NMasahiro Yamada <masahiroy@kernel.org>
[nc: Reword commit message]
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      b744b43f
  21. 11 5月, 2020 1 次提交
  23. 10 5月, 2020 3 次提交
  25. 08 5月, 2020 2 次提交
    • G
      MIPS: Replace zero-length array with flexible-array · c4ad6ea9
      由 Gustavo A. R. Silva 提交于 
      The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      c4ad6ea9
    • T
      MIPS: Loongson: Add DMA support for LS7A · 68fbb972
      由 Tiezhu Yang 提交于 
      In the current market, the most used bridge chip on the Loongson platform
are RS780E and LS7A, the RS780E bridge chip is already supported by the
mainline kernel.

If use the default implementation of __phys_to_dma() and __dma_to_phys()
in dma-direct.h when CONFIG_ARCH_HAS_PHYS_TO_DMA is not set, it works
well used with LS7A on the Loongson single-way and multi-way platform,
and also works well used with RS780E on the Loongson single-way platform,
but the DMA address will be wrong on the non-node0 used with RS780E on
the Loongson multi-way platform.

Just as the description in the code comment, the devices get node id from
40 bit of HyperTransport bus, so we extract 2 bit node id (bit 44~45) from
48 bit address space of Loongson CPU and embed it into HyperTransport bus
(bit 37-38), this operation can be done only at the software level used
with RS780E on the Loongson multi-way platform, because it has no hardware
function to translate address of node id, this is a hardware compatibility
problem.

Device
    |
    | DMA address
    |
Host Bridge
    |
    | HT bus address (40 bit)
    |
   CPU
    |
    | physical address (48 bit)
    |
   RAM

The LS7A has dma_node_id_offset field in the DMA route config register,
the hardware can use the dma_node_id_offset to translate address of
node id automatically, so we can get correct address when just use the
dma_pfn_offset field in struct device.

For the above reasons, in order to maintain downward compatibility
to support the RS780E bridge chip, it is better to use the platform
dependent implementation of __phys_to_dma() and __dma_to_phys().
Signed-off-by: NTiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      68fbb972