1. 13 Nov, 2018 1 commit
  2. 31 Oct, 2018 2 commits
  3. 23 Oct, 2018 8 commits
  4. 24 Sep, 2018 1 commit
    • James Cowgill's avatar
      RISC-V: include linux/ftrace.h in asm-prototypes.h · 57a48978
      James Cowgill authored
      
      
      Building a riscv kernel with CONFIG_FUNCTION_TRACER and
      CONFIG_MODVERSIONS enabled results in these two warnings:
      
        MODPOST vmlinux.o
      WARNING: EXPORT symbol "return_to_handler" [vmlinux] version generation failed, symbol will not be versioned.
      WARNING: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.
      
      When exporting symbols from an assembly file, the MODVERSIONS code
      requires their prototypes to be defined in asm-prototypes.h (see
      scripts/Makefile.build). Since both of these symbols have prototypes
      defined in linux/ftrace.h, include this header from RISC-V's
      asm-prototypes.h.
      Reported-by: default avatarKarsten Merker <merker@debian.org>
      Signed-off-by: default avatarJames Cowgill <jcowgill@debian.org>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      57a48978
  5. 05 Sep, 2018 1 commit
    • Guenter Roeck's avatar
      RISC-V: Request newstat syscalls · 67314ec7
      Guenter Roeck authored
      Since commit 82b355d1 ("y2038: Remove newstat family from default
      syscall set"), riscv images fail to boot with the following error.
      
      /sbin/init: error while loading shared libraries: libc.so.6:
      	cannot stat shared object: Error 38
      Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
      
      Explicitly request newstat syscalls to fix the problem.
      
      Fixes: 82b355d1
      
       ("y2038: Remove newstat family from default syscall set")
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      67314ec7
  6. 28 Aug, 2018 1 commit
  7. 20 Aug, 2018 3 commits
    • Deepa Dinamani's avatar
      riscv: Delete asm/compat.h · 66eb957d
      Deepa Dinamani authored
      
      
      riscv does not enable CONFIG_COMPAT in default configurations:
      defconfig, allmodconfig and allnoconfig.
      Remove the asm/compat.h as it does not seem to add any value to
      the architecture without CONFIG_COMPAT.
      
      Now that time compat syscalls are being reused in non CONFIG_COMPAT
      modes, asm-generic/compat.h provides definitions for riscv 32 bit
      mode.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Cc: palmer@sifive.com
      Cc: linux-riscv@lists.infradead.org
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      66eb957d
    • Palmer Dabbelt's avatar
      RISC-V: Don't use a global include guard for uapi/asm/syscalls.h · e45c7aca
      Palmer Dabbelt authored
      
      
      This file is expected to be included multiple times in the same file in
      order to allow the __SYSCALL macro to generate system call tables.  With
      a global include guard we end up missing __NR_riscv_flush_icache in the
      syscall table, which results in icache flushes that escape the vDSO call
      to not actually do anything.
      
      The fix is to move to per-#define include guards, which allows the
      system call tables to actually be populated.  Thanks to Macrus Comstedt
      for finding and fixing the bug!
      
      Cc: Marcus Comstedt <marcus@mc.pp.se>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      e45c7aca
    • Palmer Dabbelt's avatar
      RISC-V: Define sys_riscv_flush_icache when SMP=n · 7847e705
      Palmer Dabbelt authored
      
      
      This would be necessary to make non-SMP builds work, but there is
      another error in the implementation of our syscall linkage that actually
      just causes sys_riscv_flush_icache to never build.  I've build tested
      this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
      normal.
      
      CC: Christoph Hellwig <hch@infradead.org>
      CC: Guenter Roeck <linux@roeck-us.net>
      In-Reply-To: <20180809055830.GA17533@infradead.org>
      In-Reply-To: <20180809132612.GA31058@roeck-us.net>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      7847e705
  8. 13 Aug, 2018 5 commits
  9. 25 Jul, 2018 1 commit
    • Mark Rutland's avatar
      locking/atomics: Rework ordering barriers · fd2efaa4
      Mark Rutland authored
      
      
      Currently architectures can override __atomic_op_*() to define the barriers
      used before/after a relaxed atomic when used to build acquire/release/fence
      variants.
      
      This has the unfortunate property of requiring the architecture to define the
      full wrapper for the atomics, rather than just the barriers they care about,
      and gets in the way of generating atomics which can be easily read.
      
      Instead, this patch has architectures define an optional set of barriers:
      
      * __atomic_acquire_fence()
      * __atomic_release_fence()
      * __atomic_pre_full_fence()
      * __atomic_post_full_fence()
      
      ... which <linux/atomic.h> uses to build the wrappers.
      
      It would be nice if we could undef these, along with the __atomic_op_*()
      wrappers, but that would break the cmpxchg() wrappers, which are written
      in preprocessor. Undefs would have been nice, but alas.
      
      There should be no functional change as a result of this patch.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Andrea Parri <parri.andrea@gmail.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: andy.shevchenko@gmail.com
      Cc: arnd@arndb.de
      Cc: aryabinin@virtuozzo.com
      Cc: catalin.marinas@arm.com
      Cc: dvyukov@google.com
      Cc: glider@google.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: peter@hurleysoftware.com
      Link: http://lkml.kernel.org/r/20180716113017.3909-7-mark.rutland@arm.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      fd2efaa4
  10. 21 Jun, 2018 7 commits
  11. 09 Jun, 2018 1 commit
    • Luc Van Oostenryck's avatar
      riscv: split the declaration of __copy_user · 86406d51
      Luc Van Oostenryck authored
      
      
      We use a single __copy_user assembly function to copy memory both from
      and to userspace. While this works, it triggers sparse errors because
      we're implicitly casting between the kernel and user address spaces by
      calling __copy_user.
      
      This patch splits the C declaration into a pair of functions,
      __asm_copy_{to,from}_user, that have sane semantics WRT __user. This
      split make things fine from sparse's point of view. The assembly
      implementation keeps a single definition but add a double ENTRY() for it,
      one for __asm_copy_to_user and another one for __asm_copy_from_user.
      The result is a spare-safe implementation that pays no performance
      or code size penalty.
      Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      86406d51
  12. 08 Jun, 2018 1 commit
    • Laurent Dufour's avatar
      mm: introduce ARCH_HAS_PTE_SPECIAL · 3010a5ea
      Laurent Dufour authored
      Currently the PTE special supports is turned on in per architecture
      header files.  Most of the time, it is defined in
      arch/*/include/asm/pgtable.h depending or not on some other per
      architecture static definition.
      
      This patch introduce a new configuration variable to manage this
      directly in the Kconfig files.  It would later replace
      __HAVE_ARCH_PTE_SPECIAL.
      
      Here notes for some architecture where the definition of
      __HAVE_ARCH_PTE_SPECIAL is not obvious:
      
      arm
       __HAVE_ARCH_PTE_SPECIAL which is currently defined in
      arch/arm/include/asm/pgtable-3level.h which is included by
      arch/arm/include/asm/pgtable.h when CONFIG_ARM_LPAE is set.
      So select ARCH_HAS_PTE_SPECIAL if ARM_LPAE.
      
      powerpc
      __HAVE_ARCH_PTE_SPECIAL is defined in 2 files:
       - arch/powerpc/include/asm/book3s/64/pgtable.h
       - arch/powerpc/include/asm/pte-common.h
      The first one is included if (PPC_BOOK3S & PPC64) while the second is
      included in all the other cases.
      So select ARCH_HAS_PTE_SPECIAL all the time.
      
      sparc:
      __HAVE_ARCH_PTE_SPECIAL is defined if defined(__sparc__) &&
      defined(__arch64__) which are defined through the compiler in
      sparc/Makefile if !SPARC32 which I assume to be if SPARC64.
      So select ARCH_HAS_PTE_SPECIAL if SPARC64
      
      There is no functional change introduced by this patch.
      
      Link: http://lkml.kernel.org/r/1523433816-14460-2-git-send-email-ldufour@linux.vnet.ibm.com
      
      Signed-off-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Suggested-by: default avatarJerome Glisse <jglisse@redhat.com>
      Reviewed-by: default avatarJerome Glisse <jglisse@redhat.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Albert Ou <albert@sifive.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Christophe LEROY <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3010a5ea
  13. 07 Jun, 2018 1 commit
  14. 04 Jun, 2018 1 commit
    • Alan Kao's avatar
      perf: riscv: preliminary RISC-V support · 178e9fc4
      Alan Kao authored
      This patch provide a basic PMU, riscv_base_pmu, which supports two
      general hardware event, instructions and cycles.  Furthermore, this
      PMU serves as a reference implementation to ease the portings in
      the future.
      
      riscv_base_pmu should be able to run on any RISC-V machine that
      conforms to the Priv-Spec.  Note that the latest qemu model hasn't
      fully support a proper behavior of Priv-Spec 1.10 yet, but work
      around should be easy with very small fixes.  Please check
      https://github.com/riscv/riscv-qemu/pull/115
      
       for future updates.
      
      Cc: Nick Hu <nickhu@andestech.com>
      Cc: Greentime Hu <greentime@andestech.com>
      Signed-off-by: default avatarAlan Kao <alankao@andestech.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      178e9fc4
  15. 19 May, 2018 1 commit
    • Christoph Hellwig's avatar
      riscv: add swiotlb support · 10314e09
      Christoph Hellwig authored
      
      
      All RISC-V platforms today lack an IOMMU. However, legacy PCI devices
      sometimes require DMA-memory to be in the low 32 bits.  To make this work,
      we enable the software-based bounce buffers from swiotlb.  They only impose
      overhead when the device in question cannot address the full 64-bit address
      space, so a perfect fit.
      
      This patch assumes that DMA is coherent with the processor and the PCI
      bus.  It also assumes that the processor and devices share a common
      address space. This is true for all RISC-V platforms so far.
      
      [changelog stolen from an earlier patch by Palmer Dabbelt that did the
       more complicated swiotlb wireup before the recent consolidation]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      10314e09
  16. 07 May, 2018 1 commit
    • Christoph Hellwig's avatar
      PCI: remove PCI_DMA_BUS_IS_PHYS · 325ef185
      Christoph Hellwig authored
      
      
      This was used by the ide, scsi and networking code in the past to
      determine if they should bounce payloads.  Now that the dma mapping
      always have to support dma to all physical memory (thanks to swiotlb
      for non-iommu systems) there is no need to this crude hack any more.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: Palmer Dabbelt <palmer@sifive.com> (for riscv)
      Reviewed-by: default avatarJens Axboe <axboe@kernel.dk>
      325ef185
  17. 24 Apr, 2018 1 commit
  18. 03 Apr, 2018 3 commits
    • Zong Li's avatar
      RISC-V: Add section of GOT.PLT for kernel module · b8bde0ef
      Zong Li authored
      
      
      Separate the function symbol address from .plt to .got.plt section.
      
      The original plt entry has trampoline code with symbol address,
      there is a 32-bit padding bwtween jar instruction and symbol address.
      
      Extract the symbol address to .got.plt to reduce the module size.
      Signed-off-by: default avatarZong Li <zong@andestech.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      b8bde0ef
    • Zong Li's avatar
      RISC-V: Add sections of PLT and GOT for kernel module · ab1ef68e
      Zong Li authored
      
      
      The address of external symbols will locate more than 32-bit offset
      in 64-bit kernel with sv39 or sv48 virtual addressing.
      
      Module loader emits the GOT and PLT entries for data symbols and
      function symbols respectively.
      
      The PLT entry is a trampoline code for jumping to the 64-bit
      real address. The GOT entry is just the data symbol address.
      Signed-off-by: default avatarZong Li <zong@andestech.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      ab1ef68e
    • Andrea Parri's avatar
      riscv/atomic: Strengthen implementations with fences · 5ce6c1f3
      Andrea Parri authored
      Atomics present the same issue with locking: release and acquire
      variants need to be strengthened to meet the constraints defined
      by the Linux-kernel memory consistency model [1].
      
      Atomics present a further issue: implementations of atomics such
      as atomic_cmpxchg() and atomic_add_unless() rely on LR/SC pairs,
      which do not give full-ordering with .aqrl; for example, current
      implementations allow the "lr-sc-aqrl-pair-vs-full-barrier" test
      below to end up with the state indicated in the "exists" clause.
      
      In order to "synchronize" LKMM and RISC-V's implementation, this
      commit strengthens the implementations of the atomics operations
      by replacing .rl and .aq with the use of ("lightweigth") fences,
      and by replacing .aqrl LR/SC pairs in sequences such as:
      
        0:      lr.w.aqrl  %0, %addr
                bne        %0, %old, 1f
                ...
                sc.w.aqrl  %1, %new, %addr
                bnez       %1, 0b
        1:
      
      with sequences of the form:
      
        0:      lr.w       %0, %addr
                bne        %0, %old, 1f
                ...
                sc.w.rl    %1, %new, %addr   /* SC-release   */
                bnez       %1, 0b
                fence      rw, rw            /* "full" fence */
        1:
      
      following Daniel's suggestion.
      
      These modifications were validated with simulation of the RISC-V
      memory consistency model.
      
      C lr-sc-aqrl-pair-vs-full-barrier
      
      {}
      
      P0(int *x, int *y, atomic_t *u)
      {
      	int r0;
      	int r1;
      
      	WRITE_ONCE(*x, 1);
      	r0 = atomic_cmpxchg(u, 0, 1);
      	r1 = READ_ONCE(*y);
      }
      
      P1(int *x, int *y, atomic_t *v)
      {
      	int r0;
      	int r1;
      
      	WRITE_ONCE(*y, 1);
      	r0 = atomic_cmpxchg(v, 0, 1);
      	r1 = READ_ONCE(*x);
      }
      
      exists (u=1 /\ v=1 /\ 0:r1=0 /\ 1:r1=0)
      
      [1] https://marc.info/?l=linux-kernel&m=151930201102853&w=2
          https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/hKywNHBkAXM
          https://marc.info/?l=linux-kernel&m=151633436614259&w=2
      
      Suggested-by: default avatarDaniel Lustig <dlustig@nvidia.com>
      Signed-off-by: default avatarAndrea Parri <parri.andrea@gmail.com>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Albert Ou <albert@sifive.com>
      Cc: Daniel Lustig <dlustig@nvidia.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jade Alglave <j.alglave@ucl.ac.uk>
      Cc: Luc Maranget <luc.maranget@inria.fr>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Akira Yokosawa <akiyks@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: linux-riscv@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      5ce6c1f3