<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/irqchip, branch v4.14.263</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-12-14T09:16:57+00:00</updated>
<entry>
<title>irqchip: nvic: Fix offset for Interrupt Priority Offsets</title>
<updated>2021-12-14T09:16:57+00:00</updated>
<author>
<name>Vladimir Murzin</name>
<email>vladimir.murzin@arm.com</email>
</author>
<published>2021-12-01T11:02:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d69903a8e0ed5d9f8c9fd5a18d589d2d876dd890'/>
<id>urn:sha1:d69903a8e0ed5d9f8c9fd5a18d589d2d876dd890</id>
<content type='text'>
commit c5e0cbe2858d278a27d5b3fe31890aea5be064c4 upstream.

According to ARM(v7M) ARM Interrupt Priority Offsets located at
0xE000E400-0xE000E5EC, while 0xE000E300-0xE000E33C covers read-only
Interrupt Active Bit Registers

Fixes: 292ec080491d ("irqchip: Add support for ARMv7-M NVIC")
Signed-off-by: Vladimir Murzin &lt;vladimir.murzin@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20211201110259.84857-1-vladimir.murzin@arm.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>irqchip/irq-gic-v3-its.c: Force synchronisation when issuing INVALL</title>
<updated>2021-12-14T09:16:57+00:00</updated>
<author>
<name>Wudi Wang</name>
<email>wangwudi@hisilicon.com</email>
</author>
<published>2021-12-08T01:54:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad5e14fe5349f4070322137ce7caa48ac719c4cc'/>
<id>urn:sha1:ad5e14fe5349f4070322137ce7caa48ac719c4cc</id>
<content type='text'>
commit b383a42ca523ce54bcbd63f7c8f3cf974abc9b9a upstream.

INVALL CMD specifies that the ITS must ensure any caching associated with
the interrupt collection defined by ICID is consistent with the LPI
configuration tables held in memory for all Redistributors. SYNC is
required to ensure that INVALL is executed.

Currently, LPI configuration data may be inconsistent with that in the
memory within a short period of time after the INVALL command is executed.

Signed-off-by: Wudi Wang &lt;wangwudi@hisilicon.com&gt;
Signed-off-by: Shaokun Zhang &lt;zhangshaokun@hisilicon.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
Link: https://lore.kernel.org/r/20211208015429.5007-1-zhangshaokun@hisilicon.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>irqchip/armada-370-xp: Fix support for Multi-MSI interrupts</title>
<updated>2021-12-14T09:16:57+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali@kernel.org</email>
</author>
<published>2021-11-25T13:00:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4692817240fb46604739176d01e936fbd389f6e7'/>
<id>urn:sha1:4692817240fb46604739176d01e936fbd389f6e7</id>
<content type='text'>
commit d0a553502efd545c1ce3fd08fc4d423f8e4ac3d6 upstream.

irq-armada-370-xp driver already sets MSI_FLAG_MULTI_PCI_MSI flag into
msi_domain_info structure. But allocated interrupt numbers for Multi-MSI
needs to be properly aligned otherwise devices send MSI interrupt with
wrong number.

Fix this issue by using function bitmap_find_free_region() instead of
bitmap_find_next_zero_area() to allocate aligned interrupt numbers.

Signed-off-by: Pali Rohár &lt;pali@kernel.org&gt;
Fixes: a71b9412c90c ("irqchip/armada-370-xp: Allow allocation of multiple MSIs")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20211125130057.26705-2-pali@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>irqchip/armada-370-xp: Fix return value of armada_370_xp_msi_alloc()</title>
<updated>2021-12-14T09:16:57+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali@kernel.org</email>
</author>
<published>2021-11-25T13:00:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7c778ccef92eeec9c0b93421f9f4e14fe4251740'/>
<id>urn:sha1:7c778ccef92eeec9c0b93421f9f4e14fe4251740</id>
<content type='text'>
commit ce20eff57361e72878a772ef08b5239d3ae102b6 upstream.

IRQ domain alloc function should return zero on success. Non-zero value
indicates failure.

Signed-off-by: Pali Rohár &lt;pali@kernel.org&gt;
Fixes: fcc392d501bd ("irqchip/armada-370-xp: Use the generic MSI infrastructure")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20211125130057.26705-1-pali@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ARM: s3c: irq-s3c24xx: Fix return value check for s3c24xx_init_intc()</title>
<updated>2021-11-26T10:40:32+00:00</updated>
<author>
<name>Jackie Liu</name>
<email>liuyun01@kylinos.cn</email>
</author>
<published>2021-09-01T12:35:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2899ca1c157e8f8f6736277ef83816d3cd0dbf52'/>
<id>urn:sha1:2899ca1c157e8f8f6736277ef83816d3cd0dbf52</id>
<content type='text'>
[ Upstream commit 2aa717473ce96c93ae43a5dc8c23cedc8ce7dd9f ]

The s3c24xx_init_intc() returns an error pointer upon failure, not NULL.
let's add an error pointer check in s3c24xx_handle_irq.

s3c_intc[0] is not NULL or ERR, we can simplify the code.

Fixes: 1f629b7a3ced ("ARM: S3C24XX: transform irq handling into a declarative form")
Signed-off-by: Jackie Liu &lt;liuyun01@kylinos.cn&gt;
Link: https://lore.kernel.org/r/20210901123557.1043953-1-liu.yun@linux.dev
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>irq: mips: avoid nested irq_enter()</title>
<updated>2021-11-26T10:40:31+00:00</updated>
<author>
<name>Mark Rutland</name>
<email>mark.rutland@arm.com</email>
</author>
<published>2021-10-20T16:25:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=080f7bffd69ef30752c4fc5dc3d704e1bfcec486'/>
<id>urn:sha1:080f7bffd69ef30752c4fc5dc3d704e1bfcec486</id>
<content type='text'>
[ Upstream commit c65b52d02f6c1a06ddb20cba175ad49eccd6410d ]

As bcm6345_l1_irq_handle() is a chained irqchip handler, it will be
invoked within the context of the root irqchip handler, which must have
entered IRQ context already.

When bcm6345_l1_irq_handle() calls arch/mips's do_IRQ() , this will nest
another call to irq_enter(), and the resulting nested increment to
`rcu_data.dynticks_nmi_nesting` will cause rcu_is_cpu_rrupt_from_idle()
to fail to identify wakeups from idle, resulting in failure to preempt,
and RCU stalls.

Chained irqchip handlers must invoke IRQ handlers by way of thee core
irqchip code, i.e. generic_handle_irq() or generic_handle_domain_irq()
and should not call do_IRQ(), which is intended only for root irqchip
handlers.

Fix bcm6345_l1_irq_handle() by calling generic_handle_irq() directly.

Fixes: c7c42ec2baa1de7a ("irqchips/bmips: Add bcm6345-l1 interrupt controller")
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Reviewed-by: Marc Zyngier &lt;maz@kernel.org&gt;
Acked-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>irqchip/gic-v3-its: Fix potential VPE leak on error</title>
<updated>2021-10-06T13:05:06+00:00</updated>
<author>
<name>Kaige Fu</name>
<email>kaige.fu@linux.alibaba.com</email>
</author>
<published>2021-09-15T02:20:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7d39992d45acd6f2d6b2f62389c55b61fb3d486b'/>
<id>urn:sha1:7d39992d45acd6f2d6b2f62389c55b61fb3d486b</id>
<content type='text'>
[ Upstream commit 280bef512933b2dda01d681d8cbe499b98fc5bdd ]

In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error,
there is an off-by-one in the number of VPEs to be freed.

Fix it by simply passing the number of VPEs allocated, which is the
index of the loop iterating over the VPEs.

Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown")
Signed-off-by: Kaige Fu &lt;kaige.fu@linux.alibaba.com&gt;
[maz: fixed commit message]
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/d9e36dee512e63670287ed9eff884a5d8d6d27f2.1631672311.git.kaige.fu@linux.alibaba.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>irqchip/mips-cpu: Set IPI domain parent chip</title>
<updated>2021-01-30T12:31:13+00:00</updated>
<author>
<name>Mathias Kresin</name>
<email>dev@kresin.me</email>
</author>
<published>2021-01-07T21:36:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b5ea72b2da495ec40035b5dfccf72c0d840aba9a'/>
<id>urn:sha1:b5ea72b2da495ec40035b5dfccf72c0d840aba9a</id>
<content type='text'>
commit 599b3063adf4bf041a87a69244ee36aded0d878f upstream.

Since commit 55567976629e ("genirq/irqdomain: Allow partial trimming of
irq_data hierarchy") the irq_data chain is valided.

The irq_domain_trim_hierarchy() function doesn't consider the irq + ipi
domain hierarchy as valid, since the ipi domain has the irq domain set
as parent, but the parent domain has no chip set. Hence the boot ends in
a kernel panic.

Set the chip for the parent domain as it is done in the mips gic irq
driver, to have a valid irq_data chain.

Fixes: 3838a547fda2 ("irqchip: mips-cpu: Introduce IPI IRQ domain support")
Cc: &lt;stable@vger.kernel.org&gt; # v5.10+
Signed-off-by: Mathias Kresin &lt;dev@kresin.me&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20210107213603.1637781-1-dev@kresin.me
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>irqchip/alpine-msi: Fix freeing of interrupts on allocation error path</title>
<updated>2020-12-29T12:47:01+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-11-29T13:55:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=38cbc6d06a37449fdf563c03111604f22effaac6'/>
<id>urn:sha1:38cbc6d06a37449fdf563c03111604f22effaac6</id>
<content type='text'>
[ Upstream commit 3841245e8498a789c65dedd7ffa8fb2fee2c0684 ]

The alpine-msi driver has an interesting allocation error handling,
where it frees the same interrupts repeatedly. Hilarity follows.

This code is probably never executed, but let's fix it nonetheless.

Fixes: e6b78f2c3e14 ("irqchip: Add the Alpine MSIX interrupt controller")
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Reviewed-by: Antoine Tenart &lt;atenart@kernel.org&gt;
Cc: Tsahee Zidenberg &lt;tsahee@annapurnalabs.com&gt;
Cc: Antoine Tenart &lt;atenart@kernel.org&gt;
Link: https://lore.kernel.org/r/20201129135525.396671-1-maz@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>genirq/affinity: Make affinity setting if activated opt-in</title>
<updated>2020-08-21T07:48:23+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2020-07-24T20:44:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a7a29935d98567331ae26b183422e22f4d0ae90'/>
<id>urn:sha1:6a7a29935d98567331ae26b183422e22f4d0ae90</id>
<content type='text'>
commit f0c7baca180046824e07fc5f1326e83a8fd150c7 upstream.

John reported that on a RK3288 system the perf per CPU interrupts are all
affine to CPU0 and provided the analysis:

 "It looks like what happens is that because the interrupts are not per-CPU
  in the hardware, armpmu_request_irq() calls irq_force_affinity() while
  the interrupt is deactivated and then request_irq() with IRQF_PERCPU |
  IRQF_NOBALANCING.

  Now when irq_startup() runs with IRQ_STARTUP_NORMAL, it calls
  irq_setup_affinity() which returns early because IRQF_PERCPU and
  IRQF_NOBALANCING are set, leaving the interrupt on its original CPU."

This was broken by the recent commit which blocked interrupt affinity
setting in hardware before activation of the interrupt. While this works in
general, it does not work for this particular case. As contrary to the
initial analysis not all interrupt chip drivers implement an activate
callback, the safe cure is to make the deferred interrupt affinity setting
at activation time opt-in.

Implement the necessary core logic and make the two irqchip implementations
for which this is required opt-in. In hindsight this would have been the
right thing to do, but ...

Fixes: baedb87d1b53 ("genirq/affinity: Handle affinity setting on inactive interrupts correctly")
Reported-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Marc Zyngier &lt;maz@kernel.org&gt;
Acked-by: Marc Zyngier &lt;maz@kernel.org&gt;
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/87blk4tzgm.fsf@nanos.tec.linutronix.de
[fllinden@amazon.com - backported to 4.14]
Signed-off-by: Frank van der Linden &lt;fllinden@amazon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
