linux-stable.git/drivers/irqchip, branch linux-3.13.y

irq-metag*: stop set_affinity vectoring to offline cpus

2014-03-07T06:06:29+00:00

commit f229006ec6beabf7b844653d92fa61f025fe3dcf upstream.

Fix irq_set_affinity callbacks in the Meta IRQ chip drivers to AND
cpu_online_mask into the cpumask when picking a CPU to vector the
interrupt to.

As Thomas pointed out, the /proc/irq/$N/smp_affinity interface doesn't
filter out offline CPUs, so without this patch if you offline CPU0 and
set an IRQ affinity to 0x3 it vectors the interrupt onto CPU0 even
though it is offline.

Reported-by: Thomas Gleixner 
Signed-off-by: James Hogan 
Cc: Thomas Gleixner 
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

irqchip: orion: Fix getting generic chip pointer.

2014-03-07T06:06:27+00:00

commit d86e9af6336c0ad586a5dbd70064253d40bbb5ff upstream.

Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
handler. The bridge interrupt is implemented using a single generic
chip. Thus the parameter passed to irq_get_domain_generic_chip()
should always be zero.

Signed-off-by: Andrew Lunn 
Acked-by: Sebastian Hesselbarth 
Fixes: 9dbd90f17e4f ("irqchip: Add support for Marvell Orion SoCs")
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

irqchip: orion: clear stale interrupts in irq_startup

2014-03-07T06:06:27+00:00

commit e0318ec3bf3f1502cd11b21b1eb00aa355b40b67 upstream.

Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
them before unmask. This installs an .irq_startup callback to ensure stale
irqs are cleared before initial unmask.

Signed-off-by: Sebastian Hesselbarth 
Tested-by: Ezequiel Garcia 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

irqchip: orion: use handle_edge_irq on bridge irqs

2014-03-07T06:06:27+00:00

commit 5f40067fc86f0e49329ad4a852c278998ff4394e upstream.

Bridge irqs are edge-triggered, i.e. they get asserted on low-to-high
transitions and not on the level of the downstream interrupt line.
This replaces handle_level_irq by the more appropriate handle_edge_irq.

Signed-off-by: Sebastian Hesselbarth 
Tested-by: Ezequiel Garcia 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

irqchip: orion: clear bridge cause register on init

2014-03-07T06:06:27+00:00

commit 7b119fd1bdc59a8060df5b659b9f7a70e0169fd6 upstream.

It is good practice to mask and clear pending irqs on init. We already
mask all irqs, so also clear the bridge irq cause register.

Signed-off-by: Sebastian Hesselbarth 
Tested-by: Ezequiel Garcia 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

irqchip: armada-370-xp: fix MSI race condition

2014-02-20T19:10:07+00:00

commit c7f7bd4a136e4b02dd2a66bf95aec545bd93e8db upstream.

In the Armada 370/XP driver, when we receive an IRQ 1, we read the
list of doorbells that caused the interrupt from register
ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of MSIs that
were generated. However, instead of acknowledging only the MSIs that
were generated, we acknowledge *all* the MSIs, by writing
~MSI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register.

This creates a race condition: if a new MSI that isn't part of the
ones read into the temporary "msimask" variable is fired before we
acknowledge all MSIs, then we will simply loose it.

It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS
register has the following behavior: "A CPU write of 0 clears the bits
in this field. A CPU write of 1 has no effect". This is what allows us
to simply write ~msimask to acknoledge the handled MSIs.

Notice that the same problem is present in the IPI implementation, but
it is fixed as a separate patch, so that this IPI fix can be pushed to
older stable versions as appropriate (all the way to 3.8), while the
MSI code only appeared in 3.13.

Signed-off-by: Lior Amsalem 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

irqchip: armada-370-xp: fix IPI race condition

2014-02-20T19:10:07+00:00

commit a6f089e95b1e08cdea9633d50ad20aa5d44ba64d upstream.

In the Armada 370/XP driver, when we receive an IRQ 0, we read the
list of doorbells that caused the interrupt from register
ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of IPIs that
were generated. However, instead of acknowledging only the IPIs that
were generated, we acknowledge *all* the IPIs, by writing
~IPI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register.

This creates a race condition: if a new IPI that isn't part of the
ones read into the temporary "ipimask" variable is fired before we
acknowledge all IPIs, then we will simply loose it. This is causing
scheduling hangs on SMP intensive workloads.

It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS
register has the following behavior: "A CPU write of 0 clears the bits
in this field. A CPU write of 1 has no effect". This is what allows us
to simply write ~ipimask to acknoledge the handled IPIs.

Notice that the same problem is present in the MSI implementation, but
it will be fixed as a separate patch, so that this IPI fix can be
pushed to older stable versions as appropriate (all the way to 3.8),
while the MSI code only appeared in 3.13.

Signed-off-by: Lior Amsalem 
Signed-off-by: Thomas Petazzoni 
Fixes: 344e873e5657e8dc0 'arm: mvebu: Add IPI support via doorbells'
Cc: Thomas Gleixner 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'renesas-fixes-for-v3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes

2013-12-20T19:28:30+00:00

From Simon Horman:
Renesas ARM based SoC fixes for v3.13

* r8a7790 (R-Car H1) SoC
  - Correct GPIO resources in DT.

    This problem has been present since GPIOs were added to the r8a7790 SoC
    by f98e10c88aa95bf7 ("ARM: shmobile: r8a7790: Add GPIO controller
    devices to device tree") in v3.12-rc1.

* irqchip renesas-intc-irqpin
  - Correct register bitfield shift calculation

    This bug has been present since the renesas-intc-irqpin driver was
    introduced by 443580486e3b9657 ("irqchip: Renesas INTC External IRQ pin
    driver") in v3.10-rc1

* Lager board
  - Do not build the phy fixup unless CONFIG_PHYLIB is enabled

    This problem was introduced by 48c8b96f21817aad

* tag 'renesas-fixes-for-v3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
  ARM: shmobile: r8a7790: Fix GPIO resources in DTS
  irqchip: renesas-intc-irqpin: Fix register bitfield shift calculation
  ARM: shmobile: lager: phy fixup needs CONFIG_PHYLIB

Signed-off-by: Kevin Hilman

Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2013-12-02T18:15:39+00:00

Pull irq fixes from Thomas Gleixner:
 - Correction of fuzzy and fragile IRQ_RETVAL macro
 - IRQ related resume fix affecting only XEN
 - ARM/GIC fix for chained GIC controllers

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip: Gic: fix boot for chained gics
  irq: Enable all irqs unconditionally in irq_resume
  genirq: Correct fuzzy and fragile IRQ_RETVAL() definition

irqchip: Gic: fix boot for chained gics

2013-11-28T14:41:53+00:00

As of c0114709ed: "irqchip: gic: Perform the gic_secondary_init() call
via CPU notifier", booting on a platform with chained gics (e.g.
Realview EB ARM11MPCore) will result in the gic_cpu_notifier being
registered twice, corrupting the cpu notifier list and rendering the
platform unbootable.

This patch ensures that we only register the notifier for the first
gic, allowing platforms with chained gics to boot. At the same time we
limit the pointlessly duplicated calls to set_smp_cross_call and
set_handle_irq to the first gic registered.

Signed-off-by: Mark Rutland 
Reviewed-by: Catalin Marinas 
Cc: linux-arm-kernel@lists.infradead.org
Cc: marc.zyngier@arm.com
Cc: rob.herring@calxeda.com
Cc: olof@lixom.net
Link: http://lkml.kernel.org/r/1385648500-29048-1-git-send-email-mark.rutland@arm.com
Signed-off-by: Thomas Gleixner