1. 12 Feb, 2019 1 commit
  2. 14 Dec, 2018 1 commit
  3. 28 Nov, 2018 1 commit
    • Steven Rostedt (VMware)'s avatar
      sh/function_graph: Simplify with function_graph_enter() · bc715ee4
      Steven Rostedt (VMware) authored
      The function_graph_enter() function does the work of calling the function
      graph hook function and the management of the shadow stack, simplifying the
      work done in the architecture dependent prepare_ftrace_return().
      Have superh use the new code, and remove the shadow stack management as well as
      having to set up the trace structure.
      This is needed to prepare for a fix of a design bug on how the curr_ret_stack
      is used.
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-sh@vger.kernel.org
      Cc: stable@kernel.org
      Fixes: 03274a3f ("tracing/fgraph: Adjust fgraph depth before calling trace return callback")
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
  4. 31 Oct, 2018 6 commits
  5. 26 Oct, 2018 10 commits
  6. 03 Oct, 2018 3 commits
  7. 02 Oct, 2018 1 commit
  8. 28 Sep, 2018 1 commit
    • Rob Herring's avatar
      SH: use for_each_of_cpu_node iterator · 8cabf5bc
      Rob Herring authored
      Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This
      has the side effect of defaulting to iterating using "cpu" node names in
      preference to the deprecated (for FDT) device_type == "cpu".
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: Rob Herring's avatarRob Herring <robh@kernel.org>
  9. 20 Sep, 2018 1 commit
  10. 17 Sep, 2018 1 commit
    • Linus Walleij's avatar
      regulator: fixed: Convert to use GPIO descriptor only · efdfeb07
      Linus Walleij authored
      As we augmented the regulator core to accept a GPIO descriptor instead
      of a GPIO number, we can augment the fixed GPIO regulator to look up
      and pass that descriptor directly from device tree or board GPIO
      descriptor look up tables.
      Some boards just auto-enumerate their fixed regulator platform devices
      and I have assumed they get names like "fixed-regulator.0" but it's
      pretty hard to guess this. I need some testing from board maintainers to
      be sure. Other boards are straight forward, using just plain
      "fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
      device ID.
      It seems the da9055 and da9211 has never got around to actually passing
      any enable gpio into its platform data (not the in-tree code anyway) so we
      can just decide to simply pass a descriptor instead.
      The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named
      "*_dummy_supply_device" while it is a very real device backed by a GPIO
      line. There is nothing dummy about it at all, so I renamed it with the
      infix *_regulator_* as part of this patch set.
      Intel MID portions tested by Andy.
      Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Check the x86 BCM stuff
      Acked-by: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
      Reviewed-by: default avatarMike Rapoport <rppt@linux.vnet.ibm.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
  11. 29 Aug, 2018 2 commits
    • Arnd Bergmann's avatar
      asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro · caf6f9c8
      Arnd Bergmann authored
      The sys_llseek sytem call is needed on all 32-bit architectures and
      none of the 64-bit ones, so we can remove the __ARCH_WANT_SYS_LLSEEK guard
      and simplify the include/asm-generic/unistd.h header further.
      Since 32-bit tasks can run either natively or in compat mode on 64-bit
      architectures, we have to check for both !CONFIG_64BIT and CONFIG_COMPAT.
      There are a few 64-bit architectures that also reference sys_llseek
      in their 64-bit ABI (e.g. sparc), but I verified that those all
      select CONFIG_COMPAT, so the #if check is still correct here. It's
      a bit odd to include it in the syscall table though, as it's the
      same as sys_lseek() on 64-bit, but with strange calling conventions.
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
    • Arnd Bergmann's avatar
      y2038: Remove newstat family from default syscall set · 82b355d1
      Arnd Bergmann authored
      We have four generations of stat() syscalls:
      - the oldstat syscalls that are only used on the older architectures
      - the newstat family that is used on all 64-bit architectures but
        lacked support for large files on 32-bit architectures.
      - the stat64 family that is used mostly on 32-bit architectures to
        replace newstat
      - statx() to replace all of the above, adding 64-bit timestamps among
        other things.
      We already compile stat64 only on those architectures that need it,
      but newstat is always built, including on those that don't reference
      it. This adds a new __ARCH_WANT_NEW_STAT symbol along the lines of
      __ARCH_WANT_OLD_STAT and __ARCH_WANT_STAT64 to control compilation of
      newstat. All architectures that need it use an explict define, the
      others now get a little bit smaller, and future architecture (including
      64-bit targets) won't ever see it.
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
  12. 23 Aug, 2018 1 commit
  13. 17 Aug, 2018 3 commits
  14. 02 Aug, 2018 5 commits
  15. 01 Aug, 2018 3 commits