We only support the generic GUP now, so rename the config option to
be more clear, and always use the mm/Kconfig definition of the
symbol and select it from the arch Kconfigs.

Link: http://lkml.kernel.org/r/20190625143715.1689-11-hch@lst.deSigned-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NKhalid Aziz <khalid.aziz@oracle.com>
Reviewed-by: NJason Gunthorpe <jgg@mellanox.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Miller <davem@davemloft.net>
Cc: James Hogan <jhogan@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Rich Felker <dalias@libc.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The mips code is mostly equivalent to the generic one, minus various
bugfixes and an arch override for gup_fast_permitted.

Note that this defines ARCH_HAS_PTE_SPECIAL for mips as mips has
pte_special and pte_mkspecial implemented and used in the existing gup
code.  They are no-op stubs, though which makes me a little unsure if this
is really right thing to do.

Note that this also adds back a missing cpu_has_dc_aliases check for
__get_user_pages_fast, which the old code was only doing for
get_user_pages_fast.  This clearly looks like an oversight, as any
condition that makes get_user_pages_fast unsafe also applies to
__get_user_pages_fast.

[hch@lst.de: MIPS: don't select ARCH_HAS_PTE_SPECIAL]
  Link: http://lkml.kernel.org/r/20190701151818.32227-3-hch@lst.de
Link: http://lkml.kernel.org/r/20190625143715.1689-5-hch@lst.deSigned-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NJason Gunthorpe <jgg@mellanox.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Miller <davem@davemloft.net>
Cc: James Hogan <jhogan@kernel.org>
Cc: Khalid Aziz <khalid.aziz@oracle.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Rich Felker <dalias@libc.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While mips might architecturally have the uncached segment all the time,
the infrastructure to use it is only need on platforms where DMA is
at least partially incoherent.  Only select it for those configuration
to fix a build failure as the arch_dma_prep_coherent symbol is also only
provided for non-coherent platforms.

Fixes: 2e96e04d ("MIPS: use the generic uncached segment support in dma-direct")
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NPaul Burton <paul.burton@mips.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>

Stop providing the arch alloc/free hooks and just expose the segment
offset instead.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NPaul Burton <paul.burton@mips.com>

Most architectures do not need the memblock memory after the page
allocator is initialized, but only few enable ARCH_DISCARD_MEMBLOCK in the
arch Kconfig.

Replacing ARCH_DISCARD_MEMBLOCK with ARCH_KEEP_MEMBLOCK and inverting the
logic makes it clear which architectures actually use memblock after
system initialization and skips the necessity to add ARCH_DISCARD_MEMBLOCK
to the architectures that are still missing that option.

Link: http://lkml.kernel.org/r/1556102150-32517-1-git-send-email-rppt@linux.ibm.comSigned-off-by: NMike Rapoport <rppt@linux.ibm.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Bridge ASIC is widely used in different SGI systems, but the connected
chipset is either HUB, HEART or BEDROCK. This commit switches to
irq domain hierarchy for hub and bridge interrupts to get bridge
setup out of hub interrupt code.
Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
[paul.burton@mips.com:
  Resolve conflict with commit 69a07a41 ("MIPS: SGI-IP27: rework HUB
  interrupts").]
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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Converted bridge code to a platform driver using the PCI generic driver
framework and use adding platform devices during xtalk scan. This allows
easier sharing bridge driver for other SGI platforms like IP30 (Octane) and
IP35 (Origin 3k, Fuel, Tezro).
Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
[paul.burton@mips.com:
  - Leave __phys_to_dma(), __dma_to_phys() & pcibus_to_node() in
    arch/mips/pci/pci-ip27.c since the motivation for moving them
    disappeared when the driver stopped being moved to drivers/pci.]
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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Currently, we have two different implementation of rwsem:

 1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
 2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)

As we are going to use a single generic implementation for rwsem-xadd.c
and no architecture-specific code will be needed, there is no point
in keeping two different implementations of rwsem. In most cases, the
performance of rwsem-spinlock.c will be worse. It also doesn't get all
the performance tuning and optimizations that had been implemented in
rwsem-xadd.c over the years.

For simplication, we are going to remove rwsem-spinlock.c and make all
architectures use a single implementation of rwsem - rwsem-xadd.c.

All references to RWSEM_GENERIC_SPINLOCK and RWSEM_XCHGADD_ALGORITHM
in the code are removed.
Suggested-by: NPeter Zijlstra <peterz@infradead.org>
Signed-off-by: NWaiman Long <longman@redhat.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-c6x-dev@linux-c6x.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-riscv@lists.infradead.org
Cc: linux-um@lists.infradead.org
Cc: linux-xtensa@linux-xtensa.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: nios2-dev@lists.rocketboards.org
Cc: openrisc@lists.librecores.org
Cc: uclinux-h8-devel@lists.sourceforge.jp
Link: https://lkml.kernel.org/r/20190322143008.21313-3-longman@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Formatting of Kconfig files doesn't look so pretty, so let the
Great White Handkerchief come around and clean it up.
Signed-off-by: NEnrico Weigelt, metux IT consult <info@metux.net>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-kernel@vger.kernel.org
Cc: hauke@hauke-m.de
Cc: zajec5@gmail.com
Cc: f.fainelli@gmail.com
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-mips@vger.kernel.org

Currently MIPS32 supports a JIT for classic BPF only, not extended BPF.
This patch adds JIT support for extended BPF on MIPS32, so code is
actually JIT'ed instead of being only interpreted. Instructions with
64-bit operands are not supported at this point.
We can delete classic BPF because the kernel will translate classic BPF
programs into extended BPF and JIT them, eliminating the need for
classic BPF.
Signed-off-by: NHassan Naveed <hnaveed@wavecomp.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: kafai@fb.com
Cc: songliubraving@fb.com
Cc: yhs@fb.com
Cc: netdev@vger.kernel.org
Cc: bpf@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: open list:MIPS <linux-mips@linux-mips.org>
Cc: open list <linux-kernel@vger.kernel.org>

Add support for booting the kernel from an externally-appended
devicetree, if no devicetree was built-in.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

This API is primarily used through DT entries, but two architectures
and two drivers call it directly.  So instead of selecting the config
symbol for random architectures pull it in implicitly for the actual
users.  Also rename the Kconfig option to describe the feature better.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: Paul Burton <paul.burton@mips.com> # MIPS
Acked-by: NLee Jones <lee.jones@linaro.org>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit rearranges the HUB interrupt code by using MIPS_IRQ_CPU
interrupt handling code and modern Linux IRQ framework features to get
rid of global arrays. It also adds support for irq affinity setting.
Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
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@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

All new 32-bit architectures should have 64-bit userspace off_t type, but
existing architectures has 32-bit ones.

To enforce the rule, new config option is added to arch/Kconfig that defaults
ARCH_32BIT_OFF_T to be disabled for new 32-bit architectures. All existing
32-bit architectures enable it explicitly.

New option affects force_o_largefile() behaviour. Namely, if userspace
off_t is 64-bits long, we have no reason to reject user to open big files.

Note that even if architectures has only 64-bit off_t in the kernel
(arc, c6x, h8300, hexagon, nios2, openrisc, and unicore32),
a libc may use 32-bit off_t, and therefore want to limit the file size
to 4GB unless specified differently in the open flags.
Signed-off-by: NYury Norov <ynorov@caviumnetworks.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NYury Norov <ynorov@marvell.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: Paul Burton <paul.burton@mips.com> # MIPS
Acked-by: Catalin Marinas <catalin.marinas@arm.com> # arm64

Commit a96d68ba ("MIPS: Loongson32: clarify we don't support MIPS16
and merge configs") attempted to reduce duplication in Kconfig by
consolidating some selects common to Loongson 1B & 1C CPUs under
CPU_LOONGSON1. Unfortunately it clearly wasn't tested because by
removing SYS_SUPPORTS_32BIT_KERNEL it prevented 32BIT from being enabled
leading to all sorts of strange build errors from a kernel configured to
build as neither 32 nor 64 bit.

Both loongson1b_defconfig & loongson1c_defconfig failed to build due to
this problem.

Revert the cleanup portions of commit a96d68ba ("MIPS: Loongson32:
clarify we don't support MIPS16 and merge configs"), keeping only its
removal of the selection of SYS_SUPPORTS_MIPS16.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Fixes: a96d68ba ("MIPS: Loongson32: clarify we don't support MIPS16 and merge configs")

Commit f263f2a2 ("MIPS: Compile post DMA flush only when needed")
pushed the selection of ARCH_HAS_SYNC_DMA_FOR_CPU down to various
SYS_HAS_CPU_* Kconfig entries corresponding to CPUs for which
cpu_needs_post_dma_flush() might return true, but unfortunately missed
the fact that some of these CPUs can be used in configurations with
DMA_NONCOHERENT=n. When this is the case the kernel build does not
include our definition of arch_sync_dma_for_cpu() from
arch/mips/mm/dma-noncoherent.c and the build fails with a link error.

One example of this problem is ip27_defconfig:

  kernel/dma/direct.o: In function `dma_direct_sync_single_for_cpu':
  direct.c:(.text+0x6c): undefined reference to `arch_sync_dma_for_cpu'
  kernel/dma/direct.o: In function `dma_direct_sync_sg_for_cpu':
  direct.c:(.text+0x1f0): undefined reference to `arch_sync_dma_for_cpu'
  kernel/dma/direct.o: In function `dma_direct_alloc':
  direct.c:(.text+0xc20): undefined reference to `arch_dma_alloc'
  kernel/dma/direct.o: In function `dma_direct_free':
  direct.c:(.text+0xc3c): undefined reference to `arch_dma_free'
  make[1]: *** [Makefile:1021: vmlinux] Error 1
  make: *** [Makefile:152: sub-make] Error 2

Fix this by selecting ARCH_HAS_SYNC_DMA_FOR_CPU only when
DMA_NONCOHERENT is also selected. The SYS_HAS_CPU_BMIPS5000 case is left
as-is because systems with that CPU always select DMA_NONCOHERENT
anyway.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Fixes: f263f2a2 ("MIPS: Compile post DMA flush only when needed")

Our hugepage support already exists for MIPS64 CPUs, and is already
enabled for older architecture revisions. There's nothing MIPSr6
specific involved, and our hugepage support already works fine for
MIPS64r6 CPUs such as the I6500, so allow it to be selected in Kconfig.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org

On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and
lld/scd is very weak ordering. We should add sync instructions "before
each ll/lld" and "at the branch-target between ll/sc" to workaround.
Otherwise, this flaw will cause deadlock occasionally (e.g. when doing
heavy load test with LTP).

Below is the explaination of CPU designer:

"For Loongson 3 family, when a memory access instruction (load, store,
or prefetch)'s executing occurs between the execution of LL and SC, the
success or failure of SC is not predictable. Although programmer would
not insert memory access instructions between LL and SC, the memory
instructions before LL in program-order, may dynamically executed
between the execution of LL/SC, so a memory fence (SYNC) is needed
before LL/LLD to avoid this situation.

Since Loongson-3A R2 (3A2000), we have improved our hardware design to
handle this case. But we later deduce a rarely circumstance that some
speculatively executed memory instructions due to branch misprediction
between LL/SC still fall into the above case, so a memory fence (SYNC)
at branch-target (if its target is not between LL/SC) is needed for
Loongson 3A1000, 3B1500, 3A2000 and 3A3000.

Our processor is continually evolving and we aim to to remove all these
workaround-SYNCs around LL/SC for new-come processor."

Here is an example:

Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var,
this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same
time('sc' return 1), and the variable is only *added by 1*, sometimes,
which is wrong and unacceptable(it should be added by 2).

Why disable fix-loongson3-llsc in compiler?
Because compiler fix will cause problems in kernel's __ex_table section.

This patch fix all the cases in kernel, but:

+. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target
of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix
the ll and branch-target coincidently such as atomic_sub_if_positive/
cmpxchg/xchg, just like this one.

+. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch
edac.h

+. local_ops and cmpxchg_local should not be affected by this bug since
only the owner can write.

+. mips_atomic_set for syscall.c is deprecated and rarely used, just let
it go
Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Signed-off-by: NHuang Pei <huangpei@loongson.cn>
[paul.burton@mips.com:
  - Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
    a comment describing why it's there.
  - Make loongson_llsc_mb() a no-op when
    CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory
    barrier.
  - Add a comment describing the bug & how loongson_llsc_mb() helps
    in asm/barrier.h.]
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: ambrosehua@gmail.com
Cc: Steven J . Hill <Steven.Hill@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Li Xuefeng <lixuefeng@loongson.cn>
Cc: Xu Chenghua <xuchenghua@loongson.cn>

GS232 core have implemented all necessary mips32r2 instructions.
Serval missing FP instructions can be emulated by kernel.

The issue of di instruction have been solved.
Thus we revert the ISA level back to MIPS32R2.
Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
Cc: keguang.zhang@gmail.com

Accorading to GS232 core user's manual, it doesn't support MIPS16.
Signed-off-by: NJiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
Cc: keguang.zhang@gmail.com

With the target now being fully OF based, we can drop the legacy mach
files. Boards can now boot fully of devicetree files.
Signed-off-by: NJohn Crispin <john@phrozen.org>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: Felix Fietkau <nbd@nbd.name>

dma_sync_phys() is only called for some CPUs when a mapping is removed.
Add ARCH_HAS_SYNC_DMA_FOR_CPU only for the CPUs listed in
cpu_needs_post_dma_flush() which need this extra call and do not compile
this code in for other CPUs. We need this for R10000, R12000, BMIPS5000
CPUs and CPUs supporting MAAR which was introduced in MIPS32r5.

This will hopefully improve the performance of the not affected devices.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: ralf@linux-mips.org
Cc: jhogan@kernel.org
Cc: linux-mips@vger.kernel.org
Cc: nbd@nbd.name

While reading through the sysvipc implementation, I noticed that the n32
semctl/shmctl/msgctl system calls behave differently based on whether
o32 support is enabled or not: Without o32, the IPC_64 flag passed by
user space is rejected but calls without that flag get IPC_64 behavior.

As far as I can tell, this was inadvertently changed by a cleanup patch
but never noticed by anyone, possibly nobody has tried using sysvipc
on n32 after linux-3.19.

Change it back to the old behavior now.

Fixes: 78aaf956 ("MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # 3.19+

All architectures except for sparc64 use the dma-direct code in some
form, and even for sparc64 we had the discussion of a direct mapping
mode a while ago.  In preparation for directly calling the direct
mapping code don't bother having it optionally but always build the
code in.  This is a minor hardship for some powerpc and arm configs
that don't pull it in yet (although they should in a relase ot two),
and sparc64 which currently doesn't need it at all, but it will
reduce the ifdef mess we'd otherwise need significantly.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
Tested-by: NJesper Dangaard Brouer <brouer@redhat.com>
Tested-by: NTony Luck <tony.luck@intel.com>

Let architectures opt into EISA support by selecting HAVE_EISA and
handle everything else in drivers/eisa.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

There is no good reason to duplicate the RAPIDIO menu in various
architectures.  Instead provide a selectable HAVE_RAPIDIO symbol
that indicates native availability of RAPIDIO support and the handle
the rest in drivers/pci.  This also means we now provide support
for PCI(e) to Rapidio bridges for every architecture instead of a
limited subset.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

There is nothing architecture specific in the PCMCIA core, so allow
building it everywhere.  The actual host controllers will depend on ISA,
PCI or a specific SOC.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NDominik Brodowski <linux@dominikbrodowski.net>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Move the definitions to drivers/pci and let the architectures select
them.  Two small differences to before: PCI_DOMAINS_GENERIC now selects
PCI_DOMAINS, cutting down the churn for modern architectures.  As the
only architectured arm did previously also offer PCI_DOMAINS as a user
visible choice in addition to selecting it from the relevant configs,
this is gone now.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

There is no good reason to duplicate the PCI menu in every architecture.
Instead provide a selectable HAVE_PCI symbol that indicates availability
of PCI support, and a FORCE_PCI symbol to for PCI on and the handle the
rest in drivers/pci.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Acked-by: NMax Filippov <jcmvbkbc@gmail.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This option is always selected from LOONGSON_MACH3X.  Switch to just
seleting PCI from that option and definining LOONGSON_PCIIO_BASE based
on CONFIG_LOONGSON_MACH3X.  PCI already selects PCI_DOMAINS.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Select CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION for MIPS, allowing the
user to enable dead code elimination. In order for this to work, ensure
that we keep the data bus exception table & the machine list by
annotating them with KEEP.

This shrinks both 32r2el_defconfig & 64r6el_defconfig builds by ~6%, as
shown by numbers from scripts/bloat-o-meter:

          | 32r2el_defconfig | 64r6el_defconfig
  --------|------------------|------------------
   No DCE | 8919864          | 8286307
      DCE | 8338988 (-6.51%) | 7741808 (-6.57%)
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/21187/
Cc: linux-mips@linux-mips.org

Select ARCH_HAS_UBSAN_SANITIZE_ALL in order to allow the user to
enable CONFIG_UBSAN_SANITIZE_ALL and instrument the entire kernel for
ubsan checks.
We exclude the VDSO from this because its build doesn't include the
__ubsan_handle_*() functions that the kernel proper defines in from
lib/ubsan.c, and the VDSO would have no sane way to report errors even
if it had definitions of these functions.
Signed-off-by: NHassan Naveed <hnaveed@wavecomp.com>
Reviewed-by: NPaul Burton <paul.burton@mips.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/21179/
Cc: <linux-mips@linux-mips.org>

The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
DRAM controller that supports memory amounts of up to 16GiB, and due to
how the address decoder has been wired in the SOC any memory beyond 1GiB
is actually mapped starting from 4GiB physical up, that is beyond the
32-bit addressable limit[1].  Consequently if the maximum amount of
memory has been installed, then it will span up to 19GiB.

Many of the evaluation boards we support that are based on one of these
SOCs have their memory soldered and the amount present fits in the
32-bit address range.  The BCM91250A SWARM board however has actual DIMM
slots and accepts, depending on the peripherals revision of the SOC, up
to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
I believe this is also the case with the BCM91250C2 LittleSur board.
This means that up to either 3GiB or 7GiB of memory requires 64-bit
addressing to access.

I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
accepts at least as much memory, although I have no documentation or
actual hardware available to verify that.

Both systems have PCI slots installed for use by any PCI option boards,
including ones that only support 32-bit addressing (additionally the
32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
addressing to 32-bits), and there is no IOMMU available.  Therefore for
PCI DMA to work in the presence of memory beyond enable swiotlb for the
affected systems.

All the other SOC onchip DMA devices use 40-bit addressing and therefore
can address the whole memory, so only enable swiotlb if PCI support and
support for DMA beyond 4GiB have been both enabled in the configuration
of the kernel.

This shows up as follows:

Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250A (SWARM)
Determined physical RAM map:
 memory: 000000000fe7fe00 @ 0000000000000000 (usable)
 memory: 000000001ffffe00 @ 0000000080000000 (usable)
 memory: 000000000ffffe00 @ 00000000c0000000 (usable)
 memory: 0000000087fffe00 @ 0000000100000000 (usable)
software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)

in the bootstrap log and removes failures like these:

defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi0: Receive buffer allocation failed
fddi0: Adapter open failed!
IP-Config: Failed to open fddi0
defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi1: Receive buffer allocation failed
fddi1: Adapter open failed!
IP-Config: Failed to open fddi1

when memory beyond 4GiB is handed out to devices that can only do 32-bit
addressing.

This updates commit cce335ae ("[MIPS] 64-bit Sibyte kernels need
DMA32.").

References:

[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
    Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
    "Memory Map", pp. 34-38

[2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
    Corporation, 18 May 2004, Section 3: "Physical Description",
    "Supported DRAM", p. 23
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
[paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Patchwork: https://patchwork.linux-mips.org/patch/21108/
References: cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.")
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org

The LittleSur board is marked for high memory support and therefore
clearly must provide a way to have enough memory installed for some to
be present outside the low 4GiB physical address range.  With the memory
map of the BCM1250 SOC it has been built around it means over 1GiB of
actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical
address range[1].

Complement commit cce335ae ("[MIPS] 64-bit Sibyte kernels need
DMA32.") then and also enable ZONE_DMA32 for LittleSur.

References:

[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
    Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
    "Memory Map", pp. 34-38
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Patchwork: https://patchwork.linux-mips.org/patch/21107/
Fixes: cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.")
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org

Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is
configured for a pre-MIPS32r1 CPU, rather than defining its equivalent
in asm/cpu-features.h based upon overrides of cpu_has_mips* macros.

The latter only works if a platform has an cpu-feature-overrides.h
header which defines cpu_has_mips* macros, which are not generally
needed. There are many cases where we know that the target ISA for a
kernel build is MIPS32r1 or later & thus includes the CLZ instruction,
without requiring any overrides from the platform. Using Kconfig allows
us to take those into account, and more naturally make a decision about
instruction support using information about the target ISA.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/21045/
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org

Sort configs in menu "Machine selection" under MIPS_MALTA.
Signed-off-by: NMaksym Kokhan <maksym.kokhan@globallogic.com>
Signed-off-by: NAndrii Bordunov <andrew.bordunov@gmail.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/21099/
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org

CONFIG_BUILTIN_DTB and CONFIG_LIBFDT selection is duplicated
in menu "Machine selection" under MIPS_MALTA.
Signed-off-by: NMaksym Kokhan <maksym.kokhan@globallogic.com>
Signed-off-by: NAndrii Bordunov <andrew.bordunov@gmail.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/21100/
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org

Allow the user to configure the kernel to omit support for floating
point, by setting CONFIG_MIPS_FP_SUPPORT=n. In an attempt to avoid
problems for users who don't understand the impact of this, only expose
the option when CONFIG_EXPERT=y.

When CONFIG_MIPS_FP_SUPPORT=n all support for FPU hardware, FPU
emulation & FP context will be removed from the kernel. If a userland
program attempts to execute a floating point instruction it will receive
a SIGILL.

Setting CONFIG_MIPS_FP_SUPPORT=n shaves around 112KB from a
64r6el_defconfig build using GCC 8.1.0.

This also helps prepare us for supporting the nanoMIPS ISA, for which
floating point support has not been finalized.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/21014/
Cc: linux-mips@linux-mips.org

When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we can
avoid needless checks of ELF headers specifying the FP ABI or NaN
encoding to use. Deselect CONFIG_ARCH_BINFMT_ELF_STATE in this case to
avoid the need for our arch_elf_pt_proc() & arch_check_elf() functions,
and stub out the mips_set_personality_nan() & mips_set_personality_fp()
functions such that SET_PERSONALITY() doesn't need to worry about any of
this.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/21011/
Cc: linux-mips@linux-mips.org