Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 1月, 2020 2 次提交
  3. 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
  5. 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
  7. 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
  9. 13 12月, 2019 1 次提交
  11. 23 11月, 2019 1 次提交
  13. 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
  15. 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
  17. 02 11月, 2019 3 次提交
  19. 01 11月, 2019 1 次提交
  21. 24 10月, 2019 1 次提交
  23. 10 10月, 2019 2 次提交
  25. 08 10月, 2019 4 次提交
    • 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
    • M
      mips: sgi-ip27: switch from DISCONTIGMEM to SPARSEMEM · 397dc00e
      由 Mike Rapoport 提交于 
      The memory initialization of SGI-IP27 is already half-way to support
SPARSEMEM. It only had free_bootmem_with_active_regions() left-overs
interfering with sparse_memory_present_with_active_regions().

Replace these calls with simpler memblocks_present() call in prom_meminit()
and adjust arch/mips/Kconfig to enable SPARSEMEM and SPARSEMEM_EXTREME for
SGI-IP27.
Co-developed-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: NMike Rapoport <rppt@linux.ibm.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      397dc00e
    • P
      MIPS: r4k-bugs64: Limit R4k bug checks to affected systems · 071d2f0b
      由 Paul Burton 提交于 
      Only build the checks for R4k errata workarounds if we expect that the
kernel might actually run on a system with an R4k CPU - ie.
CONFIG_SYS_HAS_CPU_R4X00=y & we're targeting a pre-MIPSr1 ISA revision.

Rename cpu-bugs64.c to r4k-bugs64.c to indicate the fact that the code
is specific to R4k CPUs.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
      071d2f0b
  27. 25 9月, 2019 1 次提交
  29. 21 9月, 2019 1 次提交
    • P
      MIPS: Disable pte_special() for MIPS32 with RiXi · d1af2ab3
      由 Paul Burton 提交于 
      Commit 61cbfff4 ("MIPS: pte_special()/pte_mkspecial() support")
added a _PAGE_SPECIAL bit to the pgprot bits of our PTEs. Unfortunately
for MIPS32 configurations with RiXi support this pushed the number of
pgprot bits to 13. Since the PFN field in EntryLo begins at bit 12 this
results in us shifting the most significant bit of the physical address
beyond the end of the PTE, leading any mapped access to a physical
address above 2GB to incorrectly access an address 2GB lower than
intended.

For now, disable the pte_special() support for MIPS32 configurations
that support RiXi.

Fixes: 61cbfff4 ("MIPS: pte_special()/pte_mkspecial() support")
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: Dmitry Korotin <dkorotin@wavecomp.com>
Cc: linux-mips@vger.kernel.org
      d1af2ab3
  31. 03 9月, 2019 1 次提交
  33. 29 8月, 2019 2 次提交
    • C
      MIPS: document mixing "slightly different CCAs" · db91427b
      由 Christoph Hellwig 提交于 
      Based on an email from Paul Burton, quoting section 4.8 "Cacheability and
Coherency Attributes and Access Types" of "MIPS Architecture Volume 1:
Introduction to the MIPS32 Architecture" (MD00080, revision 6.01).
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NPaul Burton <paul.burton@mips.com>
      db91427b
    • C
      dma-mapping: remove arch_dma_mmap_pgprot · 419e2f18
      由 Christoph Hellwig 提交于 
      arch_dma_mmap_pgprot is used for two things:

 1) to override the "normal" uncached page attributes for mapping
    memory coherent to devices that can't snoop the CPU caches
 2) to provide the special DMA_ATTR_WRITE_COMBINE semantics on older
    arm systems and some mips platforms

Replace one with the pgprot_dmacoherent macro that is already provided
by arm and much simpler to use, and lift the DMA_ATTR_WRITE_COMBINE
handling to common code with an explicit arch opt-in.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>	# m68k
Acked-by: Paul Burton <paul.burton@mips.com>		# mips
      419e2f18
  35. 22 8月, 2019 1 次提交
  37. 31 7月, 2019 1 次提交
  39. 26 7月, 2019 1 次提交
  41. 24 7月, 2019 3 次提交
  43. 22 7月, 2019 1 次提交