litmus-rt.git/arch/ia64, branch test The LITMUS^RT kernel. ia64: make cpu_callin_map non-volatile. 2015-06-02T17:07:03+00:00 Rusty Russell rusty@rustcorp.com.au 2015-06-01T06:23:53+00:00 5eda7861e347ffe927ecde5abd74d7b13ae938fa cpumask_test_cpu() doesn't take volatile, unlike the obsoleted cpu_isset. The only place ia64 really cares is the spin waiting for a bit; udelay() is probably a barrier but insert barrier() to be sure. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Tony Luck <tony.luck@intel.com> 
cpumask_test_cpu() doesn't take volatile, unlike the obsoleted
cpu_isset.  The only place ia64 really cares is the spin waiting for a
bit; udelay() is probably a barrier but insert barrier() to be sure.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Tony Luck <tony.luck@intel.com>
PCI / ACPI: Do not set ACPI companions for host bridges with parents 2015-05-27T23:39:53+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2015-05-27T23:39:53+00:00 dc4fdaf0e4839109169d8261814813816951c75f Commit 97badf873ab6 (device property: Make it possible to use secondary firmware nodes) uncovered a bug in the x86 (and ia64) PCI host bridge initialization code that assumes bridge->bus->sysdata to always point to a struct pci_sysdata object which need not be the case (in particular, the Xen PCI frontend driver sets it to point to a different data type). If it is not the case, an incorrect pointer (or a piece of data that is not a pointer at all) will be passed to ACPI_COMPANION_SET() and that may cause interesting breakage to happen going forward. To work around this problem use the observation that the ACPI host bridge initialization always passes NULL as parent to pci_create_root_bus(), so if pcibios_root_bridge_prepare() sees a non-NULL parent of the bridge, it should not attempt to set an ACPI companion for it, because that means that pci_create_root_bus() has been called by someone else. Fixes: 97badf873ab6 (device property: Make it possible to use secondary firmware nodes) Reported-and-tested-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> 
Commit 97badf873ab6 (device property: Make it possible to use
secondary firmware nodes) uncovered a bug in the x86 (and ia64) PCI
host bridge initialization code that assumes bridge->bus->sysdata
to always point to a struct pci_sysdata object which need not be
the case (in particular, the Xen PCI frontend driver sets it to point
to a different data type).  If it is not the case, an incorrect
pointer (or a piece of data that is not a pointer at all) will be
passed to ACPI_COMPANION_SET() and that may cause interesting
breakage to happen going forward.

To work around this problem use the observation that the ACPI
host bridge initialization always passes NULL as parent to
pci_create_root_bus(), so if pcibios_root_bridge_prepare() sees
a non-NULL parent of the bridge, it should not attempt to set
an ACPI companion for it, because that means that
pci_create_root_bus() has been called by someone else.

Fixes: 97badf873ab6 (device property: Make it possible to use secondary firmware nodes)
Reported-and-tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs 2015-04-27T00:22:07+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-04-26T22:48:49+00:00 9ec3a646fe09970f801ab15e0f1694060b9f19af Pull fourth vfs update from Al Viro: "d_inode() annotations from David Howells (sat in for-next since before the beginning of merge window) + four assorted fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: RCU pathwalk breakage when running into a symlink overmounting something fix I_DIO_WAKEUP definition direct-io: only inc/dec inode->i_dio_count for file systems fs/9p: fix readdir() VFS: assorted d_backing_inode() annotations VFS: fs/inode.c helpers: d_inode() annotations VFS: fs/cachefiles: d_backing_inode() annotations VFS: fs library helpers: d_inode() annotations VFS: assorted weird filesystems: d_inode() annotations VFS: normal filesystems (and lustre): d_inode() annotations VFS: security/: d_inode() annotations VFS: security/: d_backing_inode() annotations VFS: net/: d_inode() annotations VFS: net/unix: d_backing_inode() annotations VFS: kernel/: d_inode() annotations VFS: audit: d_backing_inode() annotations VFS: Fix up some ->d_inode accesses in the chelsio driver VFS: Cachefiles should perform fs modifications on the top layer only VFS: AF_UNIX sockets should call mknod on the top layer only 
Pull fourth vfs update from Al Viro:
 "d_inode() annotations from David Howells (sat in for-next since before
  the beginning of merge window) + four assorted fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  RCU pathwalk breakage when running into a symlink overmounting something
  fix I_DIO_WAKEUP definition
  direct-io: only inc/dec inode->i_dio_count for file systems
  fs/9p: fix readdir()
  VFS: assorted d_backing_inode() annotations
  VFS: fs/inode.c helpers: d_inode() annotations
  VFS: fs/cachefiles: d_backing_inode() annotations
  VFS: fs library helpers: d_inode() annotations
  VFS: assorted weird filesystems: d_inode() annotations
  VFS: normal filesystems (and lustre): d_inode() annotations
  VFS: security/: d_inode() annotations
  VFS: security/: d_backing_inode() annotations
  VFS: net/: d_inode() annotations
  VFS: net/unix: d_backing_inode() annotations
  VFS: kernel/: d_inode() annotations
  VFS: audit: d_backing_inode() annotations
  VFS: Fix up some ->d_inode accesses in the chelsio driver
  VFS: Cachefiles should perform fs modifications on the top layer only
  VFS: AF_UNIX sockets should call mknod on the top layer only
Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux 2015-04-24T15:23:45+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-04-24T15:23:45+00:00 836ee4874e201a5907f9658fb2bf3527dd952d30 Pull initial ACPI support for arm64 from Will Deacon: "This series introduces preliminary ACPI 5.1 support to the arm64 kernel using the "hardware reduced" profile. We don't support any peripherals yet, so it's fairly limited in scope: - MEMORY init (UEFI) - ACPI discovery (RSDP via UEFI) - CPU init (FADT) - GIC init (MADT) - SMP boot (MADT + PSCI) - ACPI Kconfig options (dependent on EXPERT) ACPI for arm64 has been in development for a while now and hardware has been available that can boot with either FDT or ACPI tables. This has been made possible by both changes to the ACPI spec to cater for ARM-based machines (known as "hardware-reduced" in ACPI parlance) but also a Linaro-driven effort to get this supported on top of the Linux kernel. This pull request is the result of that work. These changes allow us to initialise the CPUs, interrupt controller, and timers via ACPI tables, with memory information and cmdline coming from EFI. We don't support a hybrid ACPI/FDT scheme. Of course, there is still plenty of work to do (a serial console would be nice!) but I expect that to happen on a per-driver basis after this core series has been merged. Anyway, the diff stat here is fairly horrible, but splitting this up and merging it via all the different subsystems would have been extremely painful. Instead, we've got all the relevant Acks in place and I've not seen anything other than trivial (Kconfig) conflicts in -next (for completeness, I've included my resolution below). Nearly half of the insertions fall under Documentation/. So, we'll see how this goes. Right now, it all depends on EXPERT and I fully expect people to use FDT by default for the immediate future" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (31 commits) ARM64 / ACPI: make acpi_map_gic_cpu_interface() as void function ARM64 / ACPI: Ignore the return error value of acpi_map_gic_cpu_interface() ARM64 / ACPI: fix usage of acpi_map_gic_cpu_interface ARM64: kernel: acpi: honour acpi=force command line parameter ARM64: kernel: acpi: refactor ACPI tables init and checks ARM64: kernel: psci: let ACPI probe PSCI version ARM64: kernel: psci: factor out probe function ACPI: move arm64 GSI IRQ model to generic GSI IRQ layer ARM64 / ACPI: Don't unflatten device tree if acpi=force is passed ARM64 / ACPI: additions of ACPI documentation for arm64 Documentation: ACPI for ARM64 ARM64 / ACPI: Enable ARM64 in Kconfig XEN / ACPI: Make XEN ACPI depend on X86 ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 clocksource / arch_timer: Parse GTDT to initialize arch timer irqchip: Add GICv2 specific ACPI boot support ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi ACPI / processor: Make it possible to get CPU hardware ID via GICC ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID ARM64 / ACPI: Parse MADT for SMP initialization ... 
Pull initial ACPI support for arm64 from Will Deacon:
 "This series introduces preliminary ACPI 5.1 support to the arm64
  kernel using the "hardware reduced" profile.  We don't support any
  peripherals yet, so it's fairly limited in scope:

   - MEMORY init (UEFI)

   - ACPI discovery (RSDP via UEFI)

   - CPU init (FADT)

   - GIC init (MADT)

   - SMP boot (MADT + PSCI)

   - ACPI Kconfig options (dependent on EXPERT)

  ACPI for arm64 has been in development for a while now and hardware
  has been available that can boot with either FDT or ACPI tables.  This
  has been made possible by both changes to the ACPI spec to cater for
  ARM-based machines (known as "hardware-reduced" in ACPI parlance) but
  also a Linaro-driven effort to get this supported on top of the Linux
  kernel.  This pull request is the result of that work.

  These changes allow us to initialise the CPUs, interrupt controller,
  and timers via ACPI tables, with memory information and cmdline coming
  from EFI.  We don't support a hybrid ACPI/FDT scheme.  Of course,
  there is still plenty of work to do (a serial console would be nice!)
  but I expect that to happen on a per-driver basis after this core
  series has been merged.

  Anyway, the diff stat here is fairly horrible, but splitting this up
  and merging it via all the different subsystems would have been
  extremely painful.  Instead, we've got all the relevant Acks in place
  and I've not seen anything other than trivial (Kconfig) conflicts in
  -next (for completeness, I've included my resolution below).  Nearly
  half of the insertions fall under Documentation/.

  So, we'll see how this goes.  Right now, it all depends on EXPERT and
  I fully expect people to use FDT by default for the immediate future"

* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (31 commits)
  ARM64 / ACPI: make acpi_map_gic_cpu_interface() as void function
  ARM64 / ACPI: Ignore the return error value of acpi_map_gic_cpu_interface()
  ARM64 / ACPI: fix usage of acpi_map_gic_cpu_interface
  ARM64: kernel: acpi: honour acpi=force command line parameter
  ARM64: kernel: acpi: refactor ACPI tables init and checks
  ARM64: kernel: psci: let ACPI probe PSCI version
  ARM64: kernel: psci: factor out probe function
  ACPI: move arm64 GSI IRQ model to generic GSI IRQ layer
  ARM64 / ACPI: Don't unflatten device tree if acpi=force is passed
  ARM64 / ACPI: additions of ACPI documentation for arm64
  Documentation: ACPI for ARM64
  ARM64 / ACPI: Enable ARM64 in Kconfig
  XEN / ACPI: Make XEN ACPI depend on X86
  ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64
  clocksource / arch_timer: Parse GTDT to initialize arch timer
  irqchip: Add GICv2 specific ACPI boot support
  ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi
  ACPI / processor: Make it possible to get CPU hardware ID via GICC
  ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID
  ARM64 / ACPI: Parse MADT for SMP initialization
  ...
Merge tag 'pci-v4.1-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci 2015-04-22T18:26:00+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-04-22T18:26:00+00:00 9b60afee50425064fa0a69bea22f07b6ea55ebc1 Pull PCI fixes from Bjorn Helgaas: "These fix an ia64 regression caused by tighter resource checking we merged during the merge window and remove an invalid email address from MAINTAINERS. Resource management: - ia64: Treat all Address Space Descriptors as windows (Bjorn Helgaas) Miscellaneous: - MAINTAINERS: Remove Mohit Kumar (email bounces) (Bjorn Helgaas)" * tag 'pci-v4.1-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows MAINTAINERS: Remove Mohit Kumar (email bounces) 
Pull PCI fixes from Bjorn Helgaas:
 "These fix an ia64 regression caused by tighter resource checking we
  merged during the merge window and remove an invalid email address
  from MAINTAINERS.

  Resource management:
    - ia64: Treat all Address Space Descriptors as windows (Bjorn Helgaas)

  Miscellaneous:
    - MAINTAINERS: Remove Mohit Kumar (email bounces) (Bjorn Helgaas)"

* tag 'pci-v4.1-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows
  MAINTAINERS: Remove Mohit Kumar (email bounces)
ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows 2015-04-21T20:29:39+00:00 Bjorn Helgaas bhelgaas@google.com 2015-04-21T19:57:26+00:00 9fbbda5c8e0ab9c391e4160a0eb3a06260f9f668 Prior to c770cb4cb505 ("PCI: Mark invalid BARs as unassigned"), if we tried to claim a PCI BAR but could not find an upstream bridge window that matched it, we complained but still allowed the device to be enabled. c770cb4cb505 broke devices that previously worked (mptsas and igb in the case Tony reported, but it could be any devices) because it marks those BARs as IORESOURCE_UNSET, which makes pci_enable_device() complain and return failure: igb 0000:81:00.0: can't enable device: BAR 0 [mem size 0x00020000] not assigned igb: probe of 0000:81:00.0 failed with error -22 The underlying cause is an ACPI Address Space Descriptor for a PCI host bridge window that is marked as "consumer". This is a firmware defect: resources that are produced on the downstream side of a bridge should be marked "producer". But rejecting these BARs that we previously allowed is a functionality regression, and firmware has not used the producer/consumer bit consistently, so we can't rely on it anyway. Stop checking the producer/consumer bit, and assume all bridge Address Space Descriptors are for bridge windows. Note that this change does not affect I/O Port or Fixed Location I/O Port Descriptors, which are commonly used for the [io 0x0cf8-0x0cff] config access range. That range is a "consumer" range and should not be treated as a window. Fixes: c770cb4cb505 ("PCI: Mark invalid BARs as unassigned") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96961 Reported-and-tested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Prior to c770cb4cb505 ("PCI: Mark invalid BARs as unassigned"), if we tried
to claim a PCI BAR but could not find an upstream bridge window that
matched it, we complained but still allowed the device to be enabled.

c770cb4cb505 broke devices that previously worked (mptsas and igb in the
case Tony reported, but it could be any devices) because it marks those
BARs as IORESOURCE_UNSET, which makes pci_enable_device() complain and
return failure:

  igb 0000:81:00.0: can't enable device: BAR 0 [mem size 0x00020000] not assigned
  igb: probe of 0000:81:00.0 failed with error -22

The underlying cause is an ACPI Address Space Descriptor for a PCI host
bridge window that is marked as "consumer".  This is a firmware defect:
resources that are produced on the downstream side of a bridge should be
marked "producer".  But rejecting these BARs that we previously allowed is
a functionality regression, and firmware has not used the producer/consumer
bit consistently, so we can't rely on it anyway.

Stop checking the producer/consumer bit, and assume all bridge Address
Space Descriptors are for bridge windows.

Note that this change does not affect I/O Port or Fixed Location I/O Port
Descriptors, which are commonly used for the [io 0x0cf8-0x0cff] config
access range.  That range is a "consumer" range and should not be treated
as a window.

Fixes: c770cb4cb505 ("PCI: Mark invalid BARs as unassigned")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96961
Reported-and-tested-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge tag 'cpumask-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux 2015-04-20T17:19:03+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-04-20T17:19:03+00:00 6496edfce95f943e1da43631c2f437509e56af7f Pull final removal of deprecated cpus_* cpumask functions from Rusty Russell: "This is the final removal (after several years!) of the obsolete cpus_* functions, prompted by their mis-use in staging. With these function removed, all cpu functions should only iterate to nr_cpu_ids, so we finally only allocate that many bits when cpumasks are allocated offstack" * tag 'cpumask-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (25 commits) cpumask: remove __first_cpu / __next_cpu cpumask: resurrect CPU_MASK_CPU0 linux/cpumask.h: add typechecking to cpumask_test_cpu cpumask: only allocate nr_cpumask_bits. Fix weird uses of num_online_cpus(). cpumask: remove deprecated functions. mips: fix obsolete cpumask_of_cpu usage. x86: fix more deprecated cpu function usage. ia64: remove deprecated cpus_ usage. powerpc: fix deprecated CPU_MASK_CPU0 usage. CPU_MASK_ALL/CPU_MASK_NONE: remove from deprecated region. staging/lustre/o2iblnd: Don't use cpus_weight staging/lustre/libcfs: replace deprecated cpus_ calls with cpumask_ staging/lustre/ptlrpc: Do not use deprecated cpus_* functions blackfin: fix up obsolete cpu function usage. parisc: fix up obsolete cpu function usage. tile: fix up obsolete cpu function usage. arm64: fix up obsolete cpu function usage. mips: fix up obsolete cpu function usage. x86: fix up obsolete cpu function usage. ... 
Pull final removal of deprecated cpus_* cpumask functions from Rusty Russell:
 "This is the final removal (after several years!) of the obsolete
  cpus_* functions, prompted by their mis-use in staging.

  With these function removed, all cpu functions should only iterate to
  nr_cpu_ids, so we finally only allocate that many bits when cpumasks
  are allocated offstack"

* tag 'cpumask-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (25 commits)
  cpumask: remove __first_cpu / __next_cpu
  cpumask: resurrect CPU_MASK_CPU0
  linux/cpumask.h: add typechecking to cpumask_test_cpu
  cpumask: only allocate nr_cpumask_bits.
  Fix weird uses of num_online_cpus().
  cpumask: remove deprecated functions.
  mips: fix obsolete cpumask_of_cpu usage.
  x86: fix more deprecated cpu function usage.
  ia64: remove deprecated cpus_ usage.
  powerpc: fix deprecated CPU_MASK_CPU0 usage.
  CPU_MASK_ALL/CPU_MASK_NONE: remove from deprecated region.
  staging/lustre/o2iblnd: Don't use cpus_weight
  staging/lustre/libcfs: replace deprecated cpus_ calls with cpumask_
  staging/lustre/ptlrpc: Do not use deprecated cpus_* functions
  blackfin: fix up obsolete cpu function usage.
  parisc: fix up obsolete cpu function usage.
  tile: fix up obsolete cpu function usage.
  arm64: fix up obsolete cpu function usage.
  mips: fix up obsolete cpu function usage.
  x86: fix up obsolete cpu function usage.
  ...
Merge branch 'exec_domain_rip_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc 2015-04-15T20:53:55+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-04-15T20:53:55+00:00 fa2e5c073a355465a2a8c9a2fbecf404f9857c3a Pull exec domain removal from Richard Weinberger: "This series removes execution domain support from Linux. The idea behind exec domains was to support different ABIs. The feature was never complete nor stable. Let's rip it out and make the kernel signal handling code less complicated" * 'exec_domain_rip_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc: (27 commits) arm64: Removed unused variable sparc: Fix execution domain removal Remove rest of exec domains. arch: Remove exec_domain from remaining archs arc: Remove signal translation and exec_domain xtensa: Remove signal translation and exec_domain xtensa: Autogenerate offsets in struct thread_info x86: Remove signal translation and exec_domain unicore32: Remove signal translation and exec_domain um: Remove signal translation and exec_domain tile: Remove signal translation and exec_domain sparc: Remove signal translation and exec_domain sh: Remove signal translation and exec_domain s390: Remove signal translation and exec_domain mn10300: Remove signal translation and exec_domain microblaze: Remove signal translation and exec_domain m68k: Remove signal translation and exec_domain m32r: Remove signal translation and exec_domain m32r: Autogenerate offsets in struct thread_info frv: Remove signal translation and exec_domain ... 
Pull exec domain removal from Richard Weinberger:
 "This series removes execution domain support from Linux.

  The idea behind exec domains was to support different ABIs.  The
  feature was never complete nor stable.  Let's rip it out and make the
  kernel signal handling code less complicated"

* 'exec_domain_rip_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc: (27 commits)
  arm64: Removed unused variable
  sparc: Fix execution domain removal
  Remove rest of exec domains.
  arch: Remove exec_domain from remaining archs
  arc: Remove signal translation and exec_domain
  xtensa: Remove signal translation and exec_domain
  xtensa: Autogenerate offsets in struct thread_info
  x86: Remove signal translation and exec_domain
  unicore32: Remove signal translation and exec_domain
  um: Remove signal translation and exec_domain
  tile: Remove signal translation and exec_domain
  sparc: Remove signal translation and exec_domain
  sh: Remove signal translation and exec_domain
  s390: Remove signal translation and exec_domain
  mn10300: Remove signal translation and exec_domain
  microblaze: Remove signal translation and exec_domain
  m68k: Remove signal translation and exec_domain
  m32r: Remove signal translation and exec_domain
  m32r: Autogenerate offsets in struct thread_info
  frv: Remove signal translation and exec_domain
  ...
VFS: assorted weird filesystems: d_inode() annotations 2015-04-15T19:06:58+00:00 David Howells dhowells@redhat.com 2015-03-17T22:26:12+00:00 75c3cfa855dcedc84e7964269c9b6baf26137959 Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Merge branch 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild 2015-04-15T18:19:18+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-04-15T18:19:18+00:00 b422b75875a3663f08a9ab5aeb265ed2383cbe2f Pull kbuild updates from Michal Marek: "Here is the first round of kbuild changes for v4.1-rc1: - kallsyms fix for ARM and cleanup - make dep(end) removed (developers have no sense of nostalgia these days...) - include Makefiles by relative path - stop useless rebuilds of asm-offsets.h and bounds.h" * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: Kbuild: kallsyms: drop special handling of pre-3.0 GCC symbols Kbuild: kallsyms: ignore veneers emitted by the ARM linker kbuild: ia64: use $(src)/Makefile.gate rather than particular path kbuild: include $(src)/Makefile rather than $(obj)/Makefile kbuild: use relative path more to include Makefile kbuild: use relative path to include Makefile kbuild: do not add $(bounds-file) and $(offsets-file) to targets kbuild: remove warning about "make depend" kbuild: Don't reset timestamps in include/generated if not needed 
Pull kbuild updates from Michal Marek:
 "Here is the first round of kbuild changes for v4.1-rc1:

   - kallsyms fix for ARM and cleanup

   - make dep(end) removed (developers have no sense of nostalgia these
     days...)

   - include Makefiles by relative path

   - stop useless rebuilds of asm-offsets.h and bounds.h"

* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
  Kbuild: kallsyms: drop special handling of pre-3.0 GCC symbols
  Kbuild: kallsyms: ignore veneers emitted by the ARM linker
  kbuild: ia64: use $(src)/Makefile.gate rather than particular path
  kbuild: include $(src)/Makefile rather than $(obj)/Makefile
  kbuild: use relative path more to include Makefile
  kbuild: use relative path to include Makefile
  kbuild: do not add $(bounds-file) and $(offsets-file) to targets
  kbuild: remove warning about "make depend"
  kbuild: Don't reset timestamps in include/generated if not needed