1. 30 Nov, 2018 2 commits
    • Jose Abreu's avatar
      ARC: io.h: Implement reads{x}()/writes{x}() · 10d44343
      Jose Abreu authored
      Some ARC CPU's do not support unaligned loads/stores. Currently, generic
      implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
      This can lead to misfunction of some drivers as generic functions do a
      plain dereference of a pointer that can be unaligned.
      
      Let's use {get/put}_unaligned() helpers instead of plain dereference of
      pointer in order to fix. The helpers allow to get and store data from an
      unaligned address whilst preserving the CPU internal alignment.
      According to [1], the use of these helpers are costly in terms of
      performance so we added an initial check for a buffer already aligned so
      that the usage of the helpers can be avoided, when possible.
      
      [1] Documentation/unaligned-memory-access.txt
      
      Cc: Alexey Brodkin <abrodkin@synopsys.com>
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Tested-by: default avatarVitor Soares <soares@synopsys.com>
      Signed-off-by: default avatarJose Abreu <joabreu@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      10d44343
    • Kevin Hilman's avatar
      ARC: change defconfig defaults to ARCv2 · b7cc40c3
      Kevin Hilman authored
      Change the default defconfig (used with 'make defconfig') to the ARCv2
      nsim_hs_defconfig, and also switch the default Kconfig ISA selection to
      ARCv2.
      
      This allows several default defconfigs (e.g. make defconfig, make
      allnoconfig, make tinyconfig) to all work with ARCv2 by default.
      
      Note since we change default architecture from ARCompact to ARCv2
      it's required to explicitly mention architecture type in ARCompact
      defconfigs otherwise ARCv2 will be implied and binaries will be
      generated for ARCv2.
      
      Cc: <stable@vger.kernel.org> # 4.4.x
      Signed-off-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: Alexey Brodkin's avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      b7cc40c3
  2. 21 Nov, 2018 1 commit
  3. 12 Nov, 2018 5 commits
  4. 31 Oct, 2018 7 commits
  5. 11 Oct, 2018 1 commit
  6. 05 Oct, 2018 1 commit
  7. 02 Oct, 2018 1 commit
    • Rob Herring's avatar
      kbuild: consolidate Devicetree dtb build rules · 37c8a5fa
      Rob Herring authored
      There is nothing arch specific about building dtb files other than their
      location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
      The dependencies and supported targets are all slightly different.
      Also, a cross-compiler for each arch is needed, but really the host
      compiler preprocessor is perfectly fine for building dtbs. Move the
      build rules to a common location and remove the arch specific ones. This
      is done in a single step to avoid warnings about overriding rules.
      
      The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
      These pull in several dependencies some of which need a target compiler
      (specifically devicetable-offsets.h) and aren't needed to build dtbs.
      All that is really needed is dtc, so adjust the dependencies to only be
      dtc.
      
      This change enables support 'dtbs_install' on some arches which were
      missing the target.
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarPaul Burton <paul.burton@mips.com>
      Acked-by: default avatarLey Foon Tan <ley.foon.tan@intel.com>
      Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: linux-kbuild@vger.kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: uclinux-h8-devel@lists.sourceforge.jp
      Cc: linux-mips@linux-mips.org
      Cc: nios2-dev@lists.rocketboards.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-xtensa@linux-xtensa.org
      Signed-off-by: Rob Herring's avatarRob Herring <robh@kernel.org>
      37c8a5fa
  8. 27 Sep, 2018 2 commits
  9. 20 Sep, 2018 2 commits
    • Christoph Hellwig's avatar
      dma-mapping: consolidate the dma mmap implementations · 58b04406
      Christoph Hellwig authored
      The only functional differences (modulo a few missing fixes in the arch
      code) is that architectures without coherent caches need a hook to
      convert a virtual or dma address into a pfn, given that we don't have
      the kernel linear mapping available for the otherwise easy virt_to_page
      call.  As a side effect we can support mmap of the per-device coherent
      area even on architectures not providing the callback, and we make
      previous dangerous default methods dma_common_mmap actually save for
      non-coherent architectures by rejecting it without the right helper.
      
      In addition to that we need a hook so that some architectures can
      override the protection bits when mmaping a dma coherent allocations.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: Paul Burton <paul.burton@mips.com> # MIPS parts
      58b04406
    • Christoph Hellwig's avatar
      dma-mapping: merge direct and noncoherent ops · bc3ec75d
      Christoph Hellwig authored
      All the cache maintainance is already stubbed out when not enabled,
      but merging the two allows us to nicely handle the case where
      cache maintainance is required for some devices, but not others.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: Paul Burton <paul.burton@mips.com> # MIPS parts
      bc3ec75d
  10. 18 Sep, 2018 1 commit
  11. 14 Sep, 2018 1 commit
  12. 13 Sep, 2018 1 commit
    • Alexey Brodkin's avatar
      ARC: build: Get rid of toolchain check · 615f6445
      Alexey Brodkin authored
      This check is very naive: we simply test if GCC invoked without
      "-mcpu=XXX" has ARC700 define set. In that case we think that GCC
      was built with "--with-cpu=arc700" and has libgcc built for ARC700.
      
      Otherwise if ARC700 is not defined we think that everythng was built
      for ARCv2.
      
      But in reality our life is much more interesting.
      
      1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
         it may generate code for any ARC core).
      
      2. libgcc might be built with explicitly specified "--mcpu=YYY"
      
      That's exactly what happens in case of multilibbed toolchains:
       - GCC is configured with default settings
       - All the libs built for many different CPU flavors
      
      I.e. that check gets in the way of usage of multilibbed
      toolchains. And even non-multilibbed toolchains are affected.
      OpenEmbedded also builds GCC without "--with-cpu" because
      each and every target component later is compiled with explicitly
      set "-mcpu=ZZZ".
      Acked-by: Rob Herring's avatarRob Herring <robh@kernel.org>
      Signed-off-by: Alexey Brodkin's avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      615f6445
  13. 10 Sep, 2018 1 commit
    • Vineet Gupta's avatar
      ARCv2: build: use mcpu=hs38 iso generic mcpu=archs · 00a99339
      Vineet Gupta authored
      helps gcc with better instruction selections such as 64-bit multiply MPYD
      
      before
      ------
      82c34b58 <sched_clock>:
      82c34b58:	ld	r2,[0x83068d00]
      82c34b60:	add_s	r2,r2,0x7530
      82c34b66:	mov_s	r0,0x989680
      82c34b6c:	mpymu	r5,r2,r0
      82c34b70:	mpy	r4,r2,r0
      82c34b74:	mov_s	r0,r4
      82c34b76:	j_s.d	[blink]
      82c34b78:	mov_s	r1,r5
      82c34b7a:	nop_s
      
      after
      ------
      82c34b7c <sched_clock>:
      82c34b7c:	ld	r0,[0x83064d00]
      82c34b84:	add_s	r0,r0,0x7530
      82c34b8a:	mpydu	r0,r0,0x989680
      82c34b92:	j_s	[blink]
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      00a99339
  14. 04 Sep, 2018 3 commits
  15. 31 Aug, 2018 3 commits
  16. 29 Aug, 2018 1 commit
    • Arnd Bergmann's avatar
      y2038: Remove stat64 family from default syscall set · bf4b6a7d
      Arnd Bergmann authored
      New architectures should no longer need stat64, which is not y2038
      safe and has been replaced by statx(). This removes the 'select
      __ARCH_WANT_STAT64' statement from asm-generic/unistd.h and instead
      moves it into the respective asm/unistd.h UAPI header files for each
      architecture that uses it today.
      
      In the generic file, the system call number and entry points are now
      made conditional, so newly added architectures (e.g. riscv32 or csky)
      will never need to carry backwards compatiblity for it.
      
      arm64 is the only 64-bit architecture using the asm-generic/unistd.h
      file, and it already sets __ARCH_WANT_NEW_STAT in its headers, and I
      use the same #ifdef here: future 64-bit architectures therefore won't
      see newstat or stat64 any more. They don't suffer from the y2038 time_t
      overflow, but for consistency it seems best to also let them use statx().
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      bf4b6a7d
  17. 27 Aug, 2018 5 commits
  18. 23 Aug, 2018 1 commit
  19. 17 Aug, 2018 1 commit
    • Souptick Joarder's avatar
      mm: convert return type of handle_mm_fault() caller to vm_fault_t · 50a7ca3c
      Souptick Joarder authored
      Use new return type vm_fault_t for fault handler.  For now, this is just
      documenting that the function returns a VM_FAULT value rather than an
      errno.  Once all instances are converted, vm_fault_t will become a
      distinct type.
      
      Ref-> commit 1c8f4220 ("mm: change return type to vm_fault_t")
      
      In this patch all the caller of handle_mm_fault() are changed to return
      vm_fault_t type.
      
      Link: http://lkml.kernel.org/r/20180617084810.GA6730@jordon-HP-15-Notebook-PCSigned-off-by: default avatarSouptick Joarder <jrdr.linux@gmail.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      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: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      50a7ca3c