That's a leftover from the time where x86 supported SPARSE_IRQ=n.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20140507154338.967285614@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No more users outside of itanic. Confine it.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Tested-by: NTony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Link: http://lkml.kernel.org/r/20140507154338.700598389@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Get rid of the private allocator and switch over to sparse IRQs.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NChris Metcalf <cmetcalf@tilera.com>
Link: http://lkml.kernel.org/r/20140507154338.423715783@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No functional change. Just convert to the new interface.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NChris Metcalf <cmetcalf@tilera.com>
Link: http://lkml.kernel.org/r/20140507154338.132662495@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No functional change. Just convert to the new interface.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NChris Metcalf <cmetcalf@tilera.com>
Link: http://lkml.kernel.org/r/20140507154337.873477334@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No functional change. Just convert to the new interface.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NChris Metcalf <cmetcalf@tilera.com>
Link: http://lkml.kernel.org/r/20140507154337.643399187@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No functional change. Just convert to the new interface.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NChris Metcalf <cmetcalf@tilera.com>
Link: http://lkml.kernel.org/r/20140507154337.410843062@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No functional change. Just convert to the new interface.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NChris Metcalf <cmetcalf@tilera.com>
Link: http://lkml.kernel.org/r/20140507154337.177939962@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

We want to convert the drivers over to the new interface and finally
tile to sparse irqs. Implement irq_alloc/free_hwirq() for step by step
migration.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NChris Metcalf <cmetcalf@tilera.com>
Link: http://lkml.kernel.org/r/20140507154336.947853241@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No more users. Remove the cruft
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20140507154336.760446122@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Just stumbled over it when staring into ia64 irq handling.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Tested-by: NTony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Link: http://lkml.kernel.org/r/20140507154336.566531793@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

ia64 and x86 share this driver. x86 is moving to a different irq
allocation and ia64 keeps its private irq_create/destroy stuff.

Use macros to redirect to one or the other. Yes, macros to avoid
include hell.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: NJoerg Roedel <joro@8bytes.org>
Cc: x86@kernel.org
Cc: linux-ia64@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20140507154336.372289825@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

ia64 returns a negative error code when allocation fails andx86
returns 0. Make it handle both.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: x86@kernel.org
Acked-by: NJoerg Roedel <joro@8bytes.org>
Cc: linux-ia64@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20140507154336.178850165@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No need to expose this outside of the ioapic code. The dynamic
allocations are guaranteed not to happen in the gsi space. See commit
62a08ae2.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20140507154335.959870037@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No functional change just less crap.

This does not replace the requirement to move x86 to irq domains, but
it limits the mess to some degree.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20140507154335.749579081@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No functional change, just cleaned up a bit.

This does not replace the requirement to move x86 to irq domains, but
it limits the mess to some degree.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: x86@kernel.org
Cc: linux-pci@vger.kernel.org
Link: http://lkml.kernel.org/r/20140507154335.452206351@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No functional change. The request to allocate the irq above
NR_IRQS_LEGACY is completely pointless as the implementation enforces
that the dynamic allocations are above the GSI interrupts, which
includes the legacy PIT irqs.

This does not replace the requirement to move x86 to irq domains, but
it limits the mess to some degree.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20140507154335.252789823@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Use the new interfaces. No functional change.

This does not replace the requirement to move x86 to irq domains, but
it limits the mess to some degree.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20140507154334.991589924@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The create_irq variants are going away. Use the new interface. The
core and arch code already excludes the gsi interrupts from the
allocation, so no functional change.

This does not replace the requirement to move x86 to irq domains, but
it limits the mess to some degree.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NJoerg Roedel <joro@8bytes.org>
Cc: x86@kernel.org
Cc: iommu@lists.linux-foundation.org
Link: http://lkml.kernel.org/r/20140507154334.741805075@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

This is just a cleanup to get rid of the create/destroy_irq variants
which were designed in hell.

The long term solution for x86 is to switch over to irq domains and
cleanup the whole vector allocation mess.

The generic irq_alloc_hwirqs() interface deliberately prevents
multi-MSI vector allocation to further enforce the irq domain
conversion (aside of the desire to support ioapic hotplug).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20140507154334.482904047@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Not really the solution to the problem, but at least it confines the
mess in the core code and allows to get rid of the create/destroy_irq
variants from hell, i.e. 3 implementations with different semantics
plus the x86 specific variants __create_irqs and create_irq_nr
which have been invented in another circle of hell.

x86 : x86 should be converted to irq domains and I'm deliberately
      making it impossible to do the multi-vector MSI support by
      adding more crap to the current mess. It's not that hard to do
      and I'm really tired of the trainwrecks which have been invented
      by baindaid engineering so far. Any attempt to do multi-vector
      MSI or ioapic hotplug without converting to irq domains is NAKed
      hereby.

tile: Might use irq domains as well, but it has a very limited
      interrupt space, so handling it via this functionality might be
      the right thing to do even in the long run.

ia64: That's an hopeless case, as I doubt that anyone has the stomach
      to rewrite the homebrewn dynamic allocation facilities. I stared
      at it for a couple of hours and gave up. The create/destroy_irq
      mess could be made private to itanic right away if there
      wouldn't be the iommu/dmar driver being shared with x86. So to
      do that I'm going to add a separate ia64 specific implementation
      later in order not to deep-six itanic right away.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20140507154334.208629358@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Copy and paste leftovers with no functionality at all.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Jayachandran C <jchandra@broadcom.com>
Cc: linux-mips@linux-mips.org
Link: http://lkml.kernel.org/r/20140507154334.008113902@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

No need for a private allocator. The core code handles it
already. 

Allocate the non MSI irqs right at boot time via machine_desc->nr_irqs
and let the sparse core handle the MSI space.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NGrant Likely <grant.likely@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/20140507154333.809210026@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Reason: Get the upstream and urgent fixes before applying more complex
changes.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Thomas Gleixner has asked me to assist with the review and merging of
patches for the irqchip subsystem.
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
Link: http://lkml.kernel.org/r/1400006821-32145-1-git-send-email-jason@lakedaemon.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Pull x86 fixes from Peter Anvin:
 "A somewhat unpleasantly large collection of small fixes.  The big ones
  are the __visible tree sweep and a fix for 'earlyprintk=efi,keep'.  It
  was using __init functions with predictably suboptimal results.

  Another key fix is a build fix which would produce output that simply
  would not decompress correctly in some configuration, due to the
  existing Makefiles picking up an unfortunate local label and mistaking
  it for the global symbol _end.

  Additional fixes include the handling of 64-bit numbers when setting
  the vdso data page (a latent bug which became manifest when i386
  started exporting a vdso with time functions), a fix to the new MSR
  manipulation accessors which would cause features to not get properly
  unblocked, a build fix for 32-bit userland, and a few new platform
  quirks"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, vdso, time: Cast tv_nsec to u64 for proper shifting in update_vsyscall()
  x86: Fix typo in MSR_IA32_MISC_ENABLE_LIMIT_CPUID macro
  x86: Fix typo preventing msr_set/clear_bit from having an effect
  x86/intel: Add quirk to disable HPET for the Baytrail platform
  x86/hpet: Make boot_hpet_disable extern
  x86-64, build: Fix stack protector Makefile breakage with 32-bit userland
  x86/reboot: Add reboot quirk for Certec BPC600
  asmlinkage: Add explicit __visible to drivers/*, lib/*, kernel/*
  asmlinkage, x86: Add explicit __visible to arch/x86/*
  asmlinkage: Revert "lto: Make asmlinkage __visible"
  x86, build: Don't get confused by local symbols
  x86/efi: earlyprintk=efi,keep fix

With tk->wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit
systems, (tk->wall_to_monotonic.tv_nsec << tk->shift) in update_vsyscall()
may lose upper bits or, worse, add them since compiler will do this:
	(u64)(tk->wall_to_monotonic.tv_nsec << tk->shift)
instead of
	((u64)tk->wall_to_monotonic.tv_nsec << tk->shift)

So if, for example, tv_nsec is 0x800000 and shift is 8 we will end up
with 0xffffffff80000000 instead of 0x80000000. And then we are stuck in
the subsequent 'while' loop.

We need an explicit cast.
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Link: http://lkml.kernel.org/r/1399648287-15178-1-git-send-email-boris.ostrovsky@oracle.comAcked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <stable@vger.kernel.org> # v3.14
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

The spuriously added semicolon didn't have any effect because the
macro isn't currently in use.

c0a639adSigned-off-by: NAndres Freund <andres@anarazel.de>
Link: http://lkml.kernel.org/r/1399598957-7011-3-git-send-email-andres@anarazel.de
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Due to a typo the msr accessor function introduced in
22085a66 didn't have any lasting
effects because they accidentally wrote the old value back.

After c0a639ad this at the very least
this causes cpuid limits not to be lifted on some cpus leading to
missing capabilities for those.
Signed-off-by: NAndres Freund <andres@anarazel.de>
Link: http://lkml.kernel.org/r/1399598957-7011-2-git-send-email-andres@anarazel.de
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Pull xfs fixes from Dave Chinner:
 "The main fix is adding support for default ACLs on O_TMPFILE opened
  inodes to bring XFS into line with other filesystems.  Metadata CRCs
  are now also considered well enough tested to be fully supported, so
  we're removing the shouty warnings issued at mount time for
  filesystems with that format.  And there's transaction block
  reservation overrun fix.

  Summary:
   - fix a remote attribute size calculation bug that leads to a
     transaction overrun
   - add default ACLs to O_TMPFILE files
   - Remove the EXPERIMENTAL tag from filesystems with metadata CRC
     support"

* tag 'xfs-for-linus-3.15-rc5' of git://oss.sgi.com/xfs/xfs:
  xfs: remote attribute overwrite causes transaction overrun
  xfs: initialize default acls for ->tmpfile()
  xfs: fully support v5 format filesystems

Merge tag 'trace-fixes-v3.15-rc4-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull tracing fixes from Steven Rostedt:
 "This contains two fixes.

  The first is a long standing bug that causes bogus data to show up in
  the refcnt field of the module_refcnt tracepoint.  It was introduced
  by a merge conflict resolution back in 2.6.35-rc days.

  The result should be 'refcnt = incs - decs', but instead it did
  'refcnt = incs + decs'.

  The second fix is to a bug that was introduced in this merge window
  that allowed for a tracepoint funcs pointer to be used after it was
  freed.  Moving the location of where the probes are released solved
  the problem"

* tag 'trace-fixes-v3.15-rc4-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracepoint: Fix use of tracepoint funcs after rcu free
  trace: module: Maintain a valid user count

Pull input subsystem fixes from Dmitry Torokhov:
 "Just a few fixups to various drivers"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: elantech - fix touchpad initialization on Gigabyte U2442
  Input: tca8418 - fix loading this driver as a module from a device tree
  Input: bma150 - extend chip detection for bma180
  Input: atkbd - fix keyboard not working on some LG laptops
  Input: synaptics - add min/max quirk for ThinkPad Edge E431

Pull sound fixes from Takashi Iwai:
 "A bunch of small fixes for USB-audio and HD-audio, where most of them
  are for regressions: USB-audio PM fixes, ratelimit annoyance fix, HDMI
  offline state fix, and a couple of device-specific quirks"

* tag 'sound-3.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - hdmi: Set converter channel count even without sink
  ALSA: usb-audio: work around corrupted TEAC UD-H01 feedback data
  ALSA: usb-audio: Fix deadlocks at resuming
  ALSA: usb-audio: Save mixer status only once at suspend
  ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined
  ALSA: hda - add headset mic detect quirk for a Dell laptop

Pull mmc/rtsx revert from Lee Jones.

* tag 'mfd-mmc-fixes-3.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
  mmc: rtsx: Revert "mmc: rtsx: add support for pre_req and post_req"

irqchip mvebu changes for v3.16 from Jason Cooper:
* orion: reverse irq handling priority
* armada-370-xp: do set_smp_cross_call in the driver
* armada-370-xp use cpu notifier to init secondary cpus
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Non-DT irq handlers were working through irq causes from most-significant
to least-significant bit, while DT irqchip driver does it the other way
round. This revealed some more HW issues on Kirkwood peripheral IP, where
spurious sdio irqs can happen although irqs are masked.

Also, the generated binaries show that original non-DT order compared
to DT order save two instructions for each bit count check:

irqchip DT order with ffs():
  60:   e3a06001        mov     r6, #1
  64:   e2643000        rsb     r3, r4, #0
  68:   e0033004        and     r3, r3, r4
  6c:   e16f3f13        clz     r3, r3
  70:   e263301f        rsb     r3, r3, #31
  74:   e1c44316        bic     r4, r4, r6, lsl r3
  78:   e5971004        ldr     r1, [r7, #4]

Original non-DT order with fls():
  60:   e3a07001        mov     r7, #1
  64:   e16f3f14        clz     r3, r4
  68:   e263301f        rsb     r3, r3, #31
  6c:   e1c44317        bic     r4, r4, r7, lsl r3
  70:   e5951004        ldr     r1, [r5, #4]

Therefore, reverse irq bit handling back to original order by replacing
ffs() with fls().
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Link: https://lkml.kernel.org/r/1398719528-23607-1-git-send-email-sebastian.hesselbarth@gmail.comAcked-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Some irqchip initialization must be done on secondary CPUs. On mvebu
platforms, this is currently achieved by having the
arch/arm/mach-mvebu/platsmp.c code directly call into a function
exported by the irqchip driver, which isn't really nice.

This commit changes this by using the same solution as the one used in
the GIC driver: the irqchip driver registers a CPU notifier, which is
used to do the secondary CPU IRQ initialization. This way, the irqchip
driver is completely autonomous, and the function no longer needs to
be exposed from the irqchip driver to the SoC code.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-6-git-send-email-thomas.petazzoni@free-electrons.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

Instead of having the SoC code in arch/arm/mach-mvebu/platsmp.c do the
set_smp_cross_call() to register the IPI-triggering function, it makes
more sense to do exactly what the GIC driver is doing: let the irqchip
driver do it. This way, it avoids having to expose the
armada_mpic_send_doorbell() function between the irqchip driver and
the SoC code.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-5-git-send-email-thomas.petazzoni@free-electrons.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

Commit de7b2973 "tracepoint: Use struct pointer instead of name hash
for reg/unreg tracepoints" introduces a use after free by calling
release_probes on the old struct tracepoint array before the newly
allocated array is published with rcu_assign_pointer. There is a race
window where tracepoints (RCU readers) can perform a
"use-after-grace-period-after-free", which shows up as a GPF in
stress-tests.

Link: http://lkml.kernel.org/r/53698021.5020108@oracle.com
Link: http://lkml.kernel.org/p/1399549669-25465-1-git-send-email-mathieu.desnoyers@efficios.comReported-by: NSasha Levin <sasha.levin@oracle.com>
CC: Oleg Nesterov <oleg@redhat.com>
CC: Dave Jones <davej@redhat.com>
Fixes: de7b2973 "tracepoint: Use struct pointer instead of name hash for reg/unreg tracepoints"
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>