1. 03 10月, 2017 1 次提交
    • M
      thunderbolt: Add support for XDomain discovery protocol · d1ff7024
      Mika Westerberg 提交于
      When two hosts are connected over a Thunderbolt cable, there is a
      protocol they can use to communicate capabilities supported by the host.
      The discovery protocol uses automatically configured control channel
      (ring 0) and is build on top of request/response transactions using
      special XDomain primitives provided by the Thunderbolt base protocol.
      
      The capabilities consists of a root directory block of basic properties
      used for identification of the host, and then there can be zero or more
      directories each describing a Thunderbolt service and its capabilities.
      
      Once both sides have discovered what is supported the two hosts can
      setup high-speed DMA paths and transfer data to the other side using
      whatever protocol was agreed based on the properties. The software
      protocol used to communicate which DMA paths to enable is service
      specific.
      
      This patch adds support for the XDomain discovery protocol to the
      Thunderbolt bus. We model each remote host connection as a Linux XDomain
      device. For each Thunderbolt service found supported on the XDomain
      device, we create Linux Thunderbolt service device which Thunderbolt
      service drivers can then bind to based on the protocol identification
      information retrieved from the property directory describing the
      service.
      
      This code is based on the work done by Amir Levy and Michael Jamet.
      Signed-off-by: NMichael Jamet <michael.jamet@intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NYehezkel Bernat <yehezkel.bernat@intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1ff7024
  2. 20 9月, 2017 3 次提交
    • M
      kbuild: rpm-pkg: fix version number handling · 25b080bd
      Masahiro Yamada 提交于
      The "Release:" field of the spec file is determined based on the
      .version file.
      
      However, the .version file is not copied to the source tar file.
      So, when we build the kernel from the source package, the UTS_VERSION
      always indicates #1.  This does not match with "rpm -q".
      
      The kernel UTS_VERSION and "rpm -q" do not agree for binrpm-pkg, either.
      Please note the kernel has already been built before the spec file is
      created.  Currently, mkspec invokes mkversion.  This script returns an
      incremented version.  So, the "Release:" field of the spec file is
      greater than the version in the kernel by one.
      
      For the source package build (where .version file is missing), we can
      give KBUILD_BUILD_VERSION=%{release} to the build command.
      
      For the binary package build, we can simply read out the .version file
      because it contains the version number that was used for building the
      kernel image.
      
      We can remove scripts/mkversion because scripts/package/Makefile need
      not touch the .version file.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      25b080bd
    • M
      kbuild: deb-pkg: remove firmware package support · cc18abbe
      Masahiro Yamada 提交于
      Commit 5620a0d1 ("firmware: delete in-kernel firmware") deleted
      in-kernel firmware support, including the firmware install command.
      
      So, the firmware package does not make sense any more.  Remove it.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NRiku Voipio <riku.voipio@linaro.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc18abbe
    • M
      kbuild: rpm-pkg: delete firmware_install to fix build error · 9e090074
      Masahiro Yamada 提交于
      Commit 5620a0d1 ("firmware: delete in-kernel firmware") deleted
      in-kernel firmware support, including "make firmware_install".
      
      Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
      the error:
      
        make[2]: *** No rule to make target `firmware_install'.  Stop.
      
      Commit df85b2d7 ("firmware: Restore support for built-in firmware")
      restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
      is out of the scope of "make firmware_install".  So, the right thing to
      do is to kill the use of "make firmware_install".
      
      Fixes: 5620a0d1 ("firmware: delete in-kernel firmware")
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e090074
  3. 15 9月, 2017 1 次提交
    • G
      firmware: delete in-kernel firmware · 5620a0d1
      Greg Kroah-Hartman 提交于
      The last firmware change for the in-kernel firmware source code was back
      in 2013.  Everyone has been relying on the out-of-tree linux-firmware
      package for a long long time.
      
      So let's drop it, it's baggage we don't need to keep dragging around
      (and having to fix random kbuild issues over time...)
      
      Cc: Kyle McMartin <kyle@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5620a0d1
  4. 12 9月, 2017 2 次提交
  5. 10 9月, 2017 1 次提交
  6. 09 9月, 2017 6 次提交
  7. 07 9月, 2017 1 次提交
  8. 02 9月, 2017 1 次提交
  9. 01 9月, 2017 3 次提交
  10. 31 8月, 2017 1 次提交
  11. 24 8月, 2017 1 次提交
  12. 22 8月, 2017 3 次提交
  13. 21 8月, 2017 1 次提交
  14. 20 8月, 2017 1 次提交
  15. 10 8月, 2017 1 次提交
  16. 09 8月, 2017 5 次提交
  17. 08 8月, 2017 2 次提交
    • M
      scripts/sphinx-pre-install: add minimum support for RHEL · 9b756a9d
      Mauro Carvalho Chehab 提交于
      RHEL 7.x and clone distros are shipped with Sphinx 1.1.x,
      with is incompatible with Kernel ReST markups.
      
      So, on those systems, the only alternative is to install
      it via a Python virtual environment.
      
      While seeking for "pip" on CentOS 7.3, I noticed that it
      is not really needed, as python-virtualenv has its version
      packaged there already. So, remove this from the list of
      requirements for all distributions.
      
      With regards to PDF, we need at least texlive-tabulary
      extension, but that is not shipped there (at least on
      CentOS). So, disable PDF packages as a whole.
      
      Please notice, however, that texlive + amsmath is needed for
      ReST to properly handle ReST ".. math::" tags. Yet, Sphinx
      fall back to display the LaTeX math expressions as-is, if
      such extension is not available.
      
      So, let's just disable all texlive packages as a whole.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      9b756a9d
    • A
      gcc-plugins: structleak: add option to init all vars used as byref args · f7dd2507
      Ard Biesheuvel 提交于
      In the Linux kernel, struct type variables are rarely passed by-value,
      and so functions that initialize such variables typically take an input
      reference to the variable rather than returning a value that can
      subsequently be used in an assignment.
      
      If the initalization function is not part of the same compilation unit,
      the lack of an assignment operation defeats any analysis the compiler
      can perform as to whether the variable may be used before having been
      initialized. This means we may end up passing on such variables
      uninitialized, resulting in potential information leaks.
      
      So extend the existing structleak GCC plugin so it will [optionally]
      apply to all struct type variables that have their address taken at any
      point, rather than only to variables of struct types that have a __user
      annotation.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      f7dd2507
  18. 02 8月, 2017 1 次提交
  19. 01 8月, 2017 1 次提交
  20. 26 7月, 2017 1 次提交
    • J
      x86/unwind: Add the ORC unwinder · ee9f8fce
      Josh Poimboeuf 提交于
      Add the new ORC unwinder which is enabled by CONFIG_ORC_UNWINDER=y.
      It plugs into the existing x86 unwinder framework.
      
      It relies on objtool to generate the needed .orc_unwind and
      .orc_unwind_ip sections.
      
      For more details on why ORC is used instead of DWARF, see
      Documentation/x86/orc-unwinder.txt - but the short version is
      that it's a simplified, fundamentally more robust debugninfo
      data structure, which also allows up to two orders of magnitude
      faster lookups than the DWARF unwinder - which matters to
      profiling workloads like perf.
      
      Thanks to Andy Lutomirski for the performance improvement ideas:
      splitting the ORC unwind table into two parallel arrays and creating a
      fast lookup table to search a subset of the unwind table.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/0a6cbfb40f8da99b7a45a1a8302dc6aef16ec812.1500938583.git.jpoimboe@redhat.com
      [ Extended the changelog. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ee9f8fce
  21. 25 7月, 2017 2 次提交
    • W
      modpost: abort if module name is too long · 4fd3e4ef
      Wanlong Gao 提交于
      Module name has a limited length, but currently the build system
      allows the build finishing even if the module name is too long.
      
        CC      /root/kprobe_example/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.mod.o
       /root/kprobe_example/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.mod.c:9:2:
       warning: initializer-string for array of chars is too long [enabled by default]
        .name = KBUILD_MODNAME,
        ^
      
      but it's merely a warning.
      
      This patch adds the check of the module name length in modpost and stops
      the build properly.
      Signed-off-by: NWanlong Gao <wanlong.gao@gmail.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      4fd3e4ef
    • J
      objtool: Fix gcov check for older versions of GCC · 867ac9d7
      Josh Poimboeuf 提交于
      Objtool tries to silence 'unreachable instruction' warnings when it
      detects gcov is enabled, because gcov produces a lot of unreachable
      instructions and they don't really matter.
      
      However, the 0-day bot is still reporting some unreachable instruction
      warnings with CONFIG_GCOV_KERNEL=y on GCC 4.6.4.
      
      As it turns out, objtool's gcov detection doesn't work with older
      versions of GCC because they don't create a bunch of symbols with the
      'gcov.' prefix like newer versions of GCC do.
      
      Move the gcov check out of objtool and instead just create a new
      '--no-unreachable' flag which can be passed in by the kernel Makefile
      when CONFIG_GCOV_KERNEL is defined.
      
      Also rename the 'nofp' variable to 'no_fp' for consistency with the new
      'no_unreachable' variable.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 9cfffb11 ("objtool: Skip all "unreachable instruction" warnings for gcov kernels")
      Link: http://lkml.kernel.org/r/c243dc78eb2ffdabb6e927844dea39b6033cd395.1500939244.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      867ac9d7
  22. 24 7月, 2017 1 次提交
    • L
      Properly alphabetize MAINTAINERS file · 7683e9e5
      Linus Torvalds 提交于
      This adds a perl script to actually parse the MAINTAINERS file, clean up
      some whitespace in it, warn about errors in it, and then properly sort
      the end result.
      
      My perl-fu is atrocious, so the script has basically been created by
      randomly putting various characters in a pile, mixing them around, and
      then looking it the end result does anything interesting when used as a
      perl script.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7683e9e5