1. 13 10月, 2017 1 次提交
  2. 27 9月, 2017 1 次提交
  3. 20 9月, 2017 4 次提交
    • F
      scripts/dtc: dtx_diff - 2nd update of include dts paths to match build · 35f3c984
      Frank Rowand 提交于
      Update dtx_diff include paths in the same manner as:
      commit b12869a8 ("of: remove drivers/of/testcase-data from
      include search path for CPP"), commit 5ffa2aed ("of: remove
      arch/$(SRCARCH)/boot/dts from include search path for CPP"), and
      commit 50f9ddaf ("of: search scripts/dtc/include-prefixes path
      for both CPP and DTC").
      
      Remove proposed include path kernel/dts/, which was never implemented
      for the dtb build.
      
      For the diff case, each source file is compiled separately.  For
      each of those compiles, provide the location of the source file
      as an include path, not the location of both source files.
      Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      35f3c984
    • 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
  4. 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
  5. 12 9月, 2017 2 次提交
  6. 10 9月, 2017 1 次提交
  7. 09 9月, 2017 6 次提交
  8. 07 9月, 2017 1 次提交
  9. 02 9月, 2017 1 次提交
  10. 01 9月, 2017 3 次提交
  11. 31 8月, 2017 1 次提交
  12. 24 8月, 2017 1 次提交
  13. 22 8月, 2017 3 次提交
  14. 21 8月, 2017 1 次提交
  15. 20 8月, 2017 1 次提交
  16. 10 8月, 2017 1 次提交
  17. 09 8月, 2017 5 次提交
  18. 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
  19. 02 8月, 2017 1 次提交
  20. 01 8月, 2017 1 次提交
  21. 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
  22. 25 7月, 2017 1 次提交
    • 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