1. 29 6月, 2017 1 次提交
    • P
      MIPS: Use queued read/write locks (qrwlock) · 25da4e9d
      Paul Burton 提交于
      This patch switches MIPS to make use of generically implemented queued
      read/write locks, rather than the custom implementation used previously.
      This allows us to drop a whole load of inline assembly, share more
      generic code, and is also a performance win.
      
      Results from running the AIM7 short workload on a MIPS Creator Ci40 (ie.
      2 core 2 thread interAptiv CPU clocked at 546MHz) with v4.12-rc4
      pistachio_defconfig, with ftrace disabled due to a current bug, and both
      with & without use of queued rwlocks & spinlocks:
      
        Forks | v4.12-rc4 | +qlocks  | Change
       -------|-----------|----------|--------
           10 | 52630.32  | 53316.31 | +1.01%
           20 | 51777.80  | 52623.15 | +1.02%
           30 | 51645.92  | 52517.26 | +1.02%
           40 | 51634.88  | 52419.89 | +1.02%
           50 | 51506.75  | 52307.81 | +1.02%
           60 | 51500.74  | 52322.72 | +1.02%
           70 | 51434.81  | 52288.60 | +1.02%
           80 | 51423.22  | 52434.85 | +1.02%
           90 | 51428.65  | 52410.10 | +1.02%
      
      The kernels used for these tests also had my "MIPS: Hardcode cpu_has_*
      where known at compile time due to ISA" patch applied, which allows the
      kernel_uses_llsc checks in cmpxchg() & xchg() to be optimised away at
      compile time.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16357/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      25da4e9d
  2. 28 6月, 2017 1 次提交
    • D
      MIPS: Add support for eBPF JIT. · f381bf6d
      David Daney 提交于
      Since the eBPF machine has 64-bit registers, we only support this in
      64-bit kernels.  As of the writing of this commit log test-bpf is showing:
      
        test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
      
      All current test cases are successfully compiled.
      
      Many examples in samples/bpf are usable, specifically tracex5 which
      uses tail calls works.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16369/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f381bf6d
  3. 27 6月, 2017 1 次提交
  4. 27 4月, 2017 2 次提交
  5. 13 4月, 2017 1 次提交
  6. 12 4月, 2017 1 次提交
  7. 10 4月, 2017 3 次提交
  8. 06 4月, 2017 1 次提交
  9. 28 3月, 2017 1 次提交
    • J
      MIPS: Allow KVM to be enabled on Octeon CPUs · 0ae3abcd
      James Hogan 提交于
      Octeon III has VZ ASE support, so allow KVM to be enabled on Octeon
      CPUs as it should now be functional.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim Krčmář" <rkrcmar@redhat.com>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      0ae3abcd
  10. 08 3月, 2017 1 次提交
  11. 09 2月, 2017 1 次提交
  12. 25 1月, 2017 1 次提交
  13. 03 1月, 2017 7 次提交
  14. 10 10月, 2016 1 次提交
  15. 08 10月, 2016 1 次提交
    • V
      atomic64: no need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE · 51a02124
      Vineet Gupta 提交于
      This came to light when implementing native 64-bit atomics for ARCv2.
      
      The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
      to check whether atomic64_dec_if_positive() is available.  It seems it
      was needed when not every arch defined it.  However as of current code
      the Kconfig option seems needless
      
       - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
         generic definition of API is present lib/atomic64.c
       - arches with native 64-bit atomics select it in arch/*/Kconfig and
         define the API in their headers
      
      So I see no point in keeping the Kconfig option
      
      Compile tested for:
       - blackfin (CONFIG_GENERIC_ATOMIC64)
       - x86 (!CONFIG_GENERIC_ATOMIC64)
       - ia64
      
      Link: http://lkml.kernel.org/r/1473703083-8625-3-git-send-email-vgupta@synopsys.comSigned-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Ming Lin <ming.l@ssi.samsung.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      51a02124
  16. 07 10月, 2016 5 次提交
    • P
      MIPS: generic: Convert SEAD-3 to a generic board · 3f5f0a44
      Paul Burton 提交于
      Convert the MIPS SEAD-3 board support to be a generic board, supported
      by generic kernels.
      
      Because the SEAD-3 boot protocol was defined long ago and we don't want
      to force a switch to the UHI protocol, SEAD-3 is added as a legacy board
      which is detected by reading the REVISION register. This may technically
      not be a valid memory read & future work will include attempting to
      handle that gracefully. In practice since SEAD-3 is the only legacy
      board supported by the generic kernel so far the read will only happen
      on SEAD-3 boards, and even once Malta is converted the same REVISION
      register exists there too. Other boards such as Boston, Ci20 & Ci40 will
      use the UHI boot protocol & thus not run any of the legacy board detect
      functions.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14354/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      3f5f0a44
    • P
      MIPS: generic: Introduce generic DT-based board support · eed0eabd
      Paul Burton 提交于
      Introduce a "generic" platform, which aims to be board-agnostic by
      making use of device trees passed by the boot protocol defined in the
      MIPS UHI (Universal Hosting Interface) specification. Provision is made
      for supporting boards which use a legacy boot protocol that can't be
      changed, but adding support for such boards or any others is left to
      followon patches.
      
      Right now the built kernels expect to be loaded to 0x80100000, ie. in
      kseg0. This is fine for the vast majority of MIPS platforms, but
      nevertheless it would be good to remove this limitation in the future by
      mapping the kernel via the TLB such that it can be loaded anywhere & map
      itself appropriately.
      
      Configuration is handled by dynamically generating configs using
      scripts/kconfig/merge_config.sh, somewhat similar to the way powerpc
      makes use of it. This allows for variations upon the configuration, eg.
      differing architecture revisions or subsets of driver support for
      differing boards, to be handled without having a large number of
      defconfig files.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14353/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      eed0eabd
    • P
      MIPS: Support per-device DMA coherence · 20d33064
      Paul Burton 提交于
      On some MIPS systems, a subset of devices may have DMA coherent with CPU
      caches. For example in systems including a MIPS I/O Coherence Unit
      (IOCU), some devices may be connected to that IOCU whilst others are
      not.
      
      Prior to this patch, we have a plat_device_is_coherent() function but no
      implementation which does anything besides return a global true or
      false, optionally chosen at runtime. For devices such as those described
      above this is insufficient.
      
      Fix this by tracking DMA coherence on a per-device basis with a
      dma_coherent field in struct dev_archdata. Setting this from
      arch_setup_dma_ops() takes care of devices which set the dma-coherent
      property via device tree, and any PCI devices beneath a bridge described
      in DT, automatically.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14349/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      20d33064
    • P
      MIPS: PCI: Support generic drivers · 87dd9a4d
      Paul Burton 提交于
      Introduce support for PCI drivers using only functionality provided
      generically by the PCI subsystem, by adding the minimum arch-provided
      functions required.
      
      The driver this has been developed for & tested with the xilinx-pcie on
      a MIPS Boston development board.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14346/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      87dd9a4d
    • P
      MIPS: PCI: Introduce CONFIG_PCI_DRIVERS_LEGACY · c5611df9
      Paul Burton 提交于
      Introduce 2 Kconfig symbols, CONFIG_PCI_DRIVERS_GENERIC &
      CONFIG_PCI_DRIVERS_LEGACY, which indicate whether the system should be
      built to for PCI drivers using the MIPS-specific struct pci_controller
      API (hereafter "legacy" drivers) or more generic drivers using only
      functionality provided by the PCI core (hereafter "generic" drivers).
      
      The Kconfig entries are created such that platforms have to select
      CONFIG_PCI_DRIVERS_GENERIC if they wish to use it - that is, the default
      is CONFIG_PCI_DRIVERS_LEGACY so that existing platforms need no
      modification.
      
      The functions declared in pci.h are rearranged with those provided only
      by pci-legacy.c being guarded by an #ifdef CONFIG_PCI_DRIVERS_LEGACY to
      ensure they are only used in configurations where they are implemented.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14345/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c5611df9
  17. 06 10月, 2016 2 次提交
    • P
      MIPS: PCI: Support for CONFIG_PCI_DOMAINS_GENERIC · 88555b48
      Paul Burton 提交于
      Introduce support for CONFIG_PCI_DOMAINS_GENERIC, allowing for platforms
      to make use of generic PCI domains instead of the MIPS-specific
      implementation. The set_pci_need_domain_info function is introduced to
      abstract away the removed need_domain_info field in struct
      pci_controller, and pcibios_scanbus is adjusted to use the pci_domain_nr
      accessor instead of directly accessing the index field.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14341/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      88555b48
    • P
      MIPS: Malta: Probe interrupt controllers via DT · 38ec82fe
      Paul Burton 提交于
      Probe the CPU, GIC & i8259 interrupt controllers present in the Malta
      system using device tree. This enables interrupts to be provided to
      devices using device tree as they are moved over to being probed using
      it.
      
      Since Malta is very configurable it's unknown whether a GIC will be
      present at compile time. In order to support both cases the
      malta_dt_shim code is added in order to detect whether a GIC is present,
      adjusting the DT to route interrupts correctly and nop out the GIC node
      if no GIC is found.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: devicetree@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14274/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      38ec82fe
  18. 05 10月, 2016 1 次提交
  19. 04 10月, 2016 1 次提交
  20. 20 9月, 2016 1 次提交
  21. 02 8月, 2016 3 次提交
    • J
      MIPS: ZBOOT: copy appended dtb to the end of the kernel · b8f54f2c
      Jonas Gorski 提交于
      Instead of rewriting the arguments, just move the appended dtb to where
      the decompressed kernel expects it. This eliminates the need for special
      casing vmlinuz.bin appended dtb files.
      Signed-off-by: NJonas Gorski <jogo@openwrt.org>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Alban Bedel <albeu@free.fr>
      Cc: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Cc: Antony Pavlov <antonynpavlov@gmail.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13698/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b8f54f2c
    • P
      MIPS: Use per-mm page to execute branch delay slot instructions · 432c6bac
      Paul Burton 提交于
      In some cases the kernel needs to execute an instruction from the delay
      slot of an emulated branch instruction. These cases include:
      
        - Emulated floating point branch instructions (bc1[ft]l?) for systems
          which don't include an FPU, or upon which the kernel is run with the
          "nofpu" parameter.
      
        - MIPSr6 systems running binaries targeting older revisions of the
          architecture, which may include branch instructions whose encodings
          are no longer valid in MIPSr6.
      
      Executing instructions from such delay slots is done by writing the
      instruction to memory followed by a trap, as part of an "emuframe", and
      executing it. This avoids the requirement of an emulator for the entire
      MIPS instruction set. Prior to this patch such emuframes are written to
      the user stack and executed from there.
      
      This patch moves FP branch delay emuframes off of the user stack and
      into a per-mm page. Allocating a page per-mm leaves userland with access
      to only what it had access to previously, and compared to other
      solutions is relatively simple.
      
      When a thread requires a delay slot emulation, it is allocated a frame.
      A thread may only have one frame allocated at any one time, since it may
      only ever be executing one instruction at any one time. In order to
      ensure that we can free up allocated frame later, its index is recorded
      in struct thread_struct. In the typical case, after executing the delay
      slot instruction we'll execute a break instruction with the BRK_MEMU
      code. This traps back to the kernel & leads to a call to do_dsemulret
      which frees the allocated frame & moves the user PC back to the
      instruction that would have executed following the emulated branch.
      In some cases the delay slot instruction may be invalid, such as a
      branch, or may trigger an exception. In these cases the BRK_MEMU break
      instruction will not be hit. In order to ensure that frames are freed
      this patch introduces dsemul_thread_cleanup() and calls it to free any
      allocated frame upon thread exit. If the instruction generated an
      exception & leads to a signal being delivered to the thread, or indeed
      if a signal simply happens to be delivered to the thread whilst it is
      executing from the struct emuframe, then we need to take care to exit
      the frame appropriately. This is done by either rolling back the user PC
      to the branch or advancing it to the continuation PC prior to signal
      delivery, using dsemul_thread_rollback(). If this were not done then a
      sigreturn would return to the struct emuframe, and if that frame had
      meanwhile been used in response to an emulated branch instruction within
      the signal handler then we would execute the wrong user code.
      
      Whilst a user could theoretically place something like a compact branch
      to self in a delay slot and cause their thread to become stuck in an
      infinite loop with the frame never being deallocated, this would:
      
        - Only affect the users single process.
      
        - Be architecturally invalid since there would be a branch in the
          delay slot, which is forbidden.
      
        - Be extremely unlikely to happen by mistake, and provide a program
          with no more ability to harm the system than a simple infinite loop
          would.
      
      If a thread requires a delay slot emulation & no frame is available to
      it (ie. the process has enough other threads that all frames are
      currently in use) then the thread joins a waitqueue. It will sleep until
      a frame is freed by another thread in the process.
      
      Since we now know whether a thread has an allocated frame due to our
      tracking of its index, the cookie field of struct emuframe is removed as
      we can be more certain whether we have a valid frame. Since a thread may
      only ever have a single frame at any given time, the epc field of struct
      emuframe is also removed & the PC to continue from is instead stored in
      struct thread_struct. Together these changes simplify & shrink struct
      emuframe somewhat, allowing twice as many frames to fit into the page
      allocated for them.
      
      The primary benefit of this patch is that we are now free to mark the
      user stack non-executable where that is possible.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Maciej Rozycki <maciej.rozycki@imgtec.com>
      Cc: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
      Cc: Raghu Gandham <raghu.gandham@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13764/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      432c6bac
    • J
      MIPS: Select HAVE_KVM for MIPS64_R{2,6} · 40a2df49
      James Hogan 提交于
      We are now able to support KVM T&E with MIPS32 guests on some MIPS64r2
      and MIPS64r6 hosts, so select HAVE_KVM so it can be enabled.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim Krčmář" <rkrcmar@redhat.com>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      40a2df49
  22. 24 7月, 2016 3 次提交