Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 5月, 2020 1 次提交
  3. 10 5月, 2020 3 次提交
  5. 19 4月, 2020 1 次提交
  7. 14 4月, 2020 1 次提交
  9. 25 3月, 2020 2 次提交
  11. 23 3月, 2020 1 次提交
    • T
      MIPS: Add support for Desktop Management Interface (DMI) · be8fa1cb
      由 Tiezhu Yang 提交于 
      Enable DMI scanning on the MIPS architecture, this setups DMI identifiers
(dmi_system_id) for printing it out on task dumps and prepares DIMM entry
information (dmi_memdev_info) from the SMBIOS table. With this patch, the
driver can easily match various of mainboards.

In the SMBIOS reference specification, the table anchor string "_SM_" is
present in the address range 0xF0000 to 0xFFFFF on a 16-byte boundary,
but there exists a special case for Loongson platform, when call function
dmi_early_remap, it should specify the start address to 0xFFFE000 due to
it is reserved for SMBIOS and can be normally access in the BIOS.

This patch works fine on the Loongson 3A3000 platform which belongs to
MIPS architecture and has no influence on the other architectures such
as x86 and ARM.

Additionally, in order to avoid the unknown risks on the mips platform
which is not MACH_LOONGSON64, the DMI config is better to depend on
MACH_LOONGSON64. If other mips platform also needs this DMI feature in
the future, the "depends on" condition can be modified.
Co-developed-by: NYinglu Yang <yangyinglu@loongson.cn>
Signed-off-by: NYinglu Yang <yangyinglu@loongson.cn>
[jiaxun.yang@flygoat.com: Refine definitions and Kconfig]
Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: NTiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: NHuacai Chen <chenhc@lemote.com>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
      be8fa1cb
  13. 16 3月, 2020 1 次提交
  15. 05 3月, 2020 1 次提交
  17. 18 2月, 2020 2 次提交
  19. 14 2月, 2020 1 次提交
    • F
      context-tracking: Introduce CONFIG_HAVE_TIF_NOHZ · 490f561b
      由 Frederic Weisbecker 提交于 
      A few archs (x86, arm, arm64) don't rely anymore on TIF_NOHZ to call
into context tracking on user entry/exit but instead use static keys
(or not) to optimize those calls. Ideally every arch should migrate to
that behaviour in the long run.

Settle a config option to let those archs remove their TIF_NOHZ
definitions.
Signed-off-by: NFrederic Weisbecker <frederic@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: David S. Miller <davem@davemloft.net>
      490f561b
  21. 24 1月, 2020 2 次提交
  23. 23 1月, 2020 4 次提交
    • A
      MIPS: sort MIPS and MIPS_GENERIC Kconfig selects alphabetically (again) · 34c01e41
      由 Alexander Lobakin 提交于 
      Cycles "sort selects alphabetically -> add new options at the end or at
random place -> repeat" go on and on.
Please double-check when adding new options and make sure that they
don't break the existing order to prevent dumb commits like this one
from appearing.
Signed-off-by: NAlexander Lobakin <alobakin@dlink.ru>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Cc: Will Deacon <will@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      34c01e41
    • A
      MIPS: make CPU_HAS_LOAD_STORE_LR opt-out · 18d84e2e
      由 Alexander Lobakin 提交于 
      CPU_HAS_LOAD_STORE_LR was introduced in 932afdee ("MIPS: Add Kconfig
variable for CPUs with unaligned load/store instructions") to make code
in kernel/unaligned.c and lib/mem{cpy,set}.S more intuitive and give a
possibility to easily add new CPUs without these instruction sets in
future.

Hovewer, this variant is not optimal for mainly two reasons:
* For now, we have 20+ CPUs with such instructions and only two (MIPS R6)
  without. It will obviously be more effective and straightforward to
  have an option for these two rather than for the rest.
* You can easily miss the fact that you need to select this option when
  adding a new CPU, while all processors lacking these sets are
  well-known, so the probability of missing something is way much lower.

We can address both points by turning CPU_HAS_LOAD_STORE_LR into opt-out
CPU_NO_LOAD_STORE_LR. This also makes MIPS root Kconfig more clear and
understandable.
Signed-off-by: NAlexander Lobakin <alobakin@dlink.ru>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Cc: Will Deacon <will@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      18d84e2e
    • A
      MIPS: generic: don't unconditionally select PINCTRL · 7de86604
      由 Alexander Lobakin 提交于 
      CONFIG_PINCTRL was converted from hidden selectable to a visible option
with commit d219b924 ("pinctrl: change Kconfig PINCTRL variable to
a menuconfig"). Remove unconditional select and enable this symbol in
Ocelot config, which currently is the only user among generic boards.
Signed-off-by: NAlexander Lobakin <alobakin@dlink.ru>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Cc: Will Deacon <will@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      7de86604
    • A
      MIPS: don't explicitly select LIBFDT in Kconfig · 7c8f1379
      由 Alexander Lobakin 提交于 
      It gets selected anyway through USE_OF -> OF_EARLY_FLATTREE ->
OF_FLATTREE -> LIBFDT, no need to double-check.
Signed-off-by: NAlexander Lobakin <alobakin@dlink.ru>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Cc: Will Deacon <will@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      7c8f1379
  25. 10 1月, 2020 2 次提交
    • P
      MIPS: BPF: Restore MIPS32 cBPF JIT · 36366e36
      由 Paul Burton 提交于 
      Commit 716850ab ("MIPS: eBPF: Initial eBPF support for MIPS32
architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has
previously only been availailable for MIPS64. It was my understanding at
the time that the BPF test suite was passing & JITing a comparable
number of tests to our cBPF JIT [1], but it turns out that was not the
case.

The eBPF JIT has a number of problems on MIPS32:

- Most notably various code paths still result in emission of MIPS64
  instructions which will cause reserved instruction exceptions & kernel
  panics when run on MIPS32 CPUs.

- The eBPF JIT doesn't account for differences between the O32 ABI used
  by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably
  arguments beyond the first 4 are passed on the stack in O32, and this
  is entirely unhandled when JITing a BPF_CALL instruction. Stack space
  must be reserved for arguments even if they all fit in registers, and
  the callee is free to assume that stack space has been reserved for
  its use - with the eBPF JIT this is not the case, so calling any
  function can result in clobbering values on the stack & unpredictable
  behaviour. Function arguments in eBPF are always 64-bit values which
  is also entirely unhandled - the JIT still uses a single (32-bit)
  register per argument. As a result all function arguments are always
  passed incorrectly when JITing a BPF_CALL instruction, leading to
  kernel crashes or strange behavior.

- The JIT attempts to bail our on use of ALU64 instructions or 64-bit
  memory access instructions. The code doing this at the start of
  build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW,
  when it should really be checking BPF_SIZE() & only doing so when
  BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false
  positives that cause more bailouts than intended, and that in turns
  hides some of the problems described above.

- The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF
  instructions that the MIPS32 eBPF JIT bails out on, leading to most
  cBPF programs not being JITed at all.

Until these problems are resolved, revert the removal of the cBPF JIT
performed by commit 716850ab ("MIPS: eBPF: Initial eBPF support for
MIPS32 architecture."). Together with commit f8fffebd ("MIPS: BPF:
Disable MIPS32 eBPF JIT") this restores MIPS32 BPF JIT behavior back to
the same state it was prior to the introduction of the broken eBPF JIT
support.

[1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/Signed-off-by: NPaul Burton <paulburton@kernel.org>
Fixes: 716850ab ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: Tony Ambardar <itugrok@yahoo.com>
Cc: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      36366e36
    • T
      MIPS: mm: Place per_cpu on different nodes, if NUMA is enabled · f3c560a6
      由 Thomas Bogendoerfer 提交于 
      Implement placing of per_cpu into memory, which is local to the CPU.
Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      f3c560a6
  27. 19 12月, 2019 2 次提交
    • A
      MIPS: BPF: eBPF JIT: check for MIPS ISA compliance in Kconfig · f596cf0d
      由 Alexander Lobakin 提交于 
      It is completely wrong to check for compile-time MIPS ISA revision in
the body of bpf_int_jit_compile() as it may lead to get MIPS JIT fully
omitted by the CC while the rest system will think that the JIT is
actually present and works [1].
We can check if the selected CPU really supports MIPS eBPF JIT at
configure time and avoid such situations when kernel can be built
without both JIT and interpreter, but with CONFIG_BPF_SYSCALL=y.

[1] https://lore.kernel.org/linux-mips/09d713a59665d745e21d021deeaebe0a@dlink.ru/

Fixes: 716850ab ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
Cc: <stable@vger.kernel.org> # v5.2+
Signed-off-by: NAlexander Lobakin <alobakin@dlink.ru>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: Andrii Nakryiko <andriin@fb.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: bpf@vger.kernel.org
      f596cf0d
    • P
      MIPS: BPF: Disable MIPS32 eBPF JIT · f8fffebd
      由 Paul Burton 提交于 
      Commit 716850ab ("MIPS: eBPF: Initial eBPF support for MIPS32
architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has
previously only been availailable for MIPS64. It was my understanding at
the time that the BPF test suite was passing & JITing a comparable
number of tests to our cBPF JIT [1], but it turns out that was not the
case.

The eBPF JIT has a number of problems on MIPS32:

- Most notably various code paths still result in emission of MIPS64
  instructions which will cause reserved instruction exceptions & kernel
  panics when run on MIPS32 CPUs.

- The eBPF JIT doesn't account for differences between the O32 ABI used
  by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably
  arguments beyond the first 4 are passed on the stack in O32, and this
  is entirely unhandled when JITing a BPF_CALL instruction. Stack space
  must be reserved for arguments even if they all fit in registers, and
  the callee is free to assume that stack space has been reserved for
  its use - with the eBPF JIT this is not the case, so calling any
  function can result in clobbering values on the stack & unpredictable
  behaviour. Function arguments in eBPF are always 64-bit values which
  is also entirely unhandled - the JIT still uses a single (32-bit)
  register per argument. As a result all function arguments are always
  passed incorrectly when JITing a BPF_CALL instruction, leading to
  kernel crashes or strange behavior.

- The JIT attempts to bail our on use of ALU64 instructions or 64-bit
  memory access instructions. The code doing this at the start of
  build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW,
  when it should really be checking BPF_SIZE() & only doing so when
  BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false
  positives that cause more bailouts than intended, and that in turns
  hides some of the problems described above.

- The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF
  instructions that the MIPS32 eBPF JIT bails out on, leading to most
  cBPF programs not being JITed at all.

Until these problems are resolved, revert the enabling of the eBPF JIT
on MIPS32 done by commit 716850ab ("MIPS: eBPF: Initial eBPF support
for MIPS32 architecture.").

Note that this does not undo the changes made to the eBPF JIT by that
commit, since they are a useful starting point to providing MIPS32
support - they're just not nearly complete.

[1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/Signed-off-by: NPaul Burton <paulburton@kernel.org>
Fixes: 716850ab ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: Tony Ambardar <itugrok@yahoo.com>
Cc: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: <stable@vger.kernel.org> # v5.2+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      f8fffebd
  29. 13 12月, 2019 1 次提交
  31. 23 11月, 2019 1 次提交
  33. 12 11月, 2019 4 次提交
    • A
      MIPS: allow building with kcov coverage · dcf78ee6
      由 Alexey Khoroshilov 提交于 
      Add ARCH_HAS_KCOV and HAVE_GCC_PLUGINS to MIPS config.
Disable instrumentation of vdso to avoid build failure.
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      dcf78ee6
    • J
      MIPS: Drop CPU_SUPPORTS_UNCACHED_ACCELERATED · 2a598436
      由 Jiaxun Yang 提交于 
      CPU_SUPPORTS_UNCACHED_ACCELERATED was introduced when kernel can't handle
writecombine remap well. Nowadays drivers can try writecombine remap by
themselves so this function is nolonger needed.
Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: chenhe@lemote.com
      2a598436
    • H
      MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage · caed1d1b
      由 Huacai Chen 提交于 
      There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:

1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.

2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.

All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
      caed1d1b
    • H
      MIPS: Loongson: Rename LOONGSON1 to LOONGSON32 · b2afb64c
      由 Huacai Chen 提交于 
      Now old Loongson-2E/2F use LOONGSON2EF and will be removed in future,
newer Loongson-2/3 use LOONGSON64. So rename LOONGSON1 to LOONGSON32
will make the naming style more unified.
Signed-off-by: NHuacai Chen <chenhc@lemote.com>
[paulburton@kernel.org: Fix checkpatch whitespace warning in irqflags.h]
Signed-off-by: NPaul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
      b2afb64c
  35. 11 11月, 2019 1 次提交
    • C
      dma-direct: provide mmap and get_sgtable method overrides · 34dc0ea6
      由 Christoph Hellwig 提交于 
      For dma-direct we know that the DMA address is an encoding of the
physical address that we can trivially decode.  Use that fact to
provide implementations that do not need the arch_dma_coherent_to_pfn
architecture hook.  Note that we still can only support mmap of
non-coherent memory only if the architecture provides a way to set an
uncached bit in the page tables.  This must be true for architectures
that use the generic remap helpers, but other architectures can also
manually select it.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMax Filippov <jcmvbkbc@gmail.com>
      34dc0ea6
  37. 02 11月, 2019 3 次提交
  39. 01 11月, 2019 1 次提交
  41. 24 10月, 2019 1 次提交
  43. 10 10月, 2019 2 次提交
  45. 08 10月, 2019 2 次提交
    • D
      mips: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE · a2ecb233
      由 Dmitry Korotin 提交于 
      FORTIFY_SOURCE detects various overflows at compile and run time.
(6974f0c4 ("include/linux/string.h:
add the option of fortified string.h functions)

ARCH_HAS_FORTIFY_SOURCE means that the architecture can be built and
run with CONFIG_FORTIFY_SOURCE.

Since mips can be built and run with that flag,
select ARCH_HAS_FORTIFY_SOURCE as default.
Signed-off-by: NDmitry Korotin <dkorotin@wavecomp.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
      a2ecb233
    • H
      MIPS: Loongson: Add Loongson-3A R4 basic support · 7507445b
      由 Huacai Chen 提交于 
      All Loongson-3 CPU family:

Code-name         Brand-name       PRId
Loongson-3A R1    Loongson-3A1000  0x6305
Loongson-3A R2    Loongson-3A2000  0x6308
Loongson-3A R2.1  Loongson-3A2000  0x630c
Loongson-3A R3    Loongson-3A3000  0x6309
Loongson-3A R3.1  Loongson-3A3000  0x630d
Loongson-3A R4    Loongson-3A4000  0xc000
Loongson-3B R1    Loongson-3B1000  0x6306
Loongson-3B R2    Loongson-3B1500  0x6307

Features of R4 revision of Loongson-3A:

  - All R2/R3 features, including SFB, V-Cache, FTLB, RIXI, DSP, etc.
  - Support variable ASID bits.
  - Support MSA and VZ extensions.
  - Support CPUCFG (CPU config) and CSR (Control and Status Register)
      extensions.
  - 64 entries of VTLB (classic TLB), 2048 entries of FTLB (8-way
      set-associative).

Now 64-bit Loongson processors has three types of PRID.IMP: 0x6300 is
the classic one so we call it PRID_IMP_LOONGSON_64C (e.g., Loongson-2E/
2F/3A1000/3B1000/3B1500/3A2000/3A3000), 0x6100 is for some processors
which has reduced capabilities so we call it PRID_IMP_LOONGSON_64R
(e.g., Loongson-2K), 0xc000 is supposed to cover all new processors in
general (e.g., Loongson-3A4000+) so we call it PRID_IMP_LOONGSON_64G.
Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
      7507445b