12 Feb, 2019
16 commits
-
Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.Let's set the required flags on the irq_chip structures.
Reported-by: Lina Iyer
Tested-by: Lina Iyer
Reviewed-by: Sudeep Holla
Signed-off-by: Marc Zyngier
(cherry picked from commit 4110b5cbb014ebaaeb3d18ac8b98470b7251847d) -
This reverts commit 1d965a3e12797e6561df8b5fcc16ad1d60182dab.
Shrinking the udelay from 50 to 10 causes lost IPIs and hangs on
suspend so let's revert to behavior from previous releases.Signed-off-by: Leonard Crestez
Acked-by: Jun Li -
Shorten the delay time from 50us to be 10us introduced by
commit 58cef5f23bd0 ("MLK-16804-04 driver: irqchip: Add IPI SW workaround for imx8mq"),
tested various basic cases and didn't find issues.CC: Bai Ping
Acked-by: Peter Chen
Signed-off-by: Li Jun -
Fixes: a2e6a7833495 (MLK-16136-9 irqchip: imx-irqsteer: adjust irq config
via 'endian')This patch fixes mask register offset calculation, when endian is not
default value 0 (i.e imx8mq).Signed-off-by: Antoine Bouyer
Signed-off-by: Fugang Duan -
Fix iMX8MQ workaround to be specific to that
machine.Signed-off-by: Nitin Garg
-
Add runtime pm to manage irqsteer clock and its power domain in system
idle and suspend status to save power.Signed-off-by: Fugang Duan
Signed-off-by: Frank Li
Tested-by: Guoniu.Zhou
Reviewed-by: Frank Li -
Once irqsteer controller is power off during suspend, the registers
are lost, it should restore the registers after resume back.BuildInfo:
- SCFW a479ff78, IMX-MKIMAGE ff9860c5, ATF 923651a
- U-Boot 2017.03-00691-g96cf020Signed-off-by: Fugang Duan
Tested-by: Pandy.gao
Acked-by: Pandy.gao -
On i.MX8MQ, when the CPU core is in power down state,
the IPI can NOT wakeup the core anymore(ERR011171), so using the
external IRQ32 to wakeup the core in power down idle
state successfully.Signed-off-by: Bai Ping
Reviewed-by: Anson Huang -
Irqsteer block only supports level interrupts.
(BuildInfo: SCFW 3e70523d, IMX-MKIMAGE 0, ATF 0)
Signed-off-by: Seb Laveze
Signed-off-by: Fugang Duan
Reviewed-by: Richard Zhu -
Fix the offset of CHANIPR register address. Document is KL28Z
reference manualSigned-off-by: Shengjiu Wang
-
Change the irq configurations with adding endianness
determination for different platforms which may choose
different kinds of endianess.Signed-off-by: Fancy Fang
-
Correct several macro definitions related with irqsteer
to avoid incorrect expression calculation due to operators
priority.Signed-off-by: Fancy Fang
-
The intmux module is used to output internal interrupt in subsystem
to system with 32-to-8 configuration. It has several multiplex
channels depends on system. intmux is introduced in KL28Z reference
manual.Signed-off-by: Shengjiu Wang
-
The type of irqstat in irqsteer_irqchip_data unsigned long, actually
it needs to be 32bits width, so use unsigned int.And use sizeof(irqsteer_data->irqstat[0]), instead of 4 when alloc
memory for irqsteer_data.for_each_set_bit needs the second param type is unsigned long *, so
cast the irqsteer_data->irqstat to unsigned long *, this is safe here.Signed-off-by: Peng Fan
-
Some subsystems have lpcg sw_bit to control the ipg_clk to LIS,
so add the ipg clock for the module.Signed-off-by: Fugang Duan
-
The IrqSteer module redirects/steers the incoming interrupts to output
interrupts of a selected/designated channel as specified by a set of
configuration registers.NXP i.MX8x chips integrate IrqSteer controller for some DSC to share irq
line for all modules in the subsystem which can reduce the IRQ lines
connected to the parent interrupt controller GIC, so IrqSteer irqchip
acts as the second irq domain in the system.Signed-off-by: Fugang Duan
31 Jan, 2019
1 commit
-
commit 8208d1708b88b412ca97f50a6d951242c88cbbac upstream.
The way we allocate events works fine in most cases, except
when multiple PCI devices share an ITS-visible DevID, and that
one of them is trying to use MultiMSI allocation.In that case, our allocation is not guaranteed to be zero-based
anymore, and we have to make sure we allocate it on a boundary
that is compatible with the PCI Multi-MSI constraints.Fix this by allocating the full region upfront instead of iterating
over the number of MSIs. MSI-X are always allocated one by one,
so this shouldn't change anything on that front.Fixes: b48ac83d6bbc2 ("irqchip: GICv3: ITS: MSI support")
Cc: stable@vger.kernel.org
Reported-by: Ard Biesheuvel
Tested-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
15 Sep, 2018
1 commit
-
[ Upstream commit 0702bc4d2fe793018ad9aa0eb14bff7f526c4095 ]
When compiling bmips with SMP disabled, the build fails with:
drivers/irqchip/irq-bcm7038-l1.o: In function `bcm7038_l1_cpu_offline':
drivers/irqchip/irq-bcm7038-l1.c:242: undefined reference to `irq_set_affinity_locked'
make[5]: *** [vmlinux] Error 1Fix this by adding and setting bcm7038_l1_cpu_offline only when actually
compiling for SMP. It wouldn't have been used anyway, as it requires
CPU_HOTPLUG, which in turn requires SMP.Fixes: 34c535793bcb ("irqchip/bcm7038-l1: Implement irq_cpu_offline() callback")
Signed-off-by: Jonas Gorski
Signed-off-by: Marc Zyngier
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
03 Aug, 2018
1 commit
-
[ Upstream commit 0cdd431c337e99177e68597f3de34bedd3a20a74 ]
Add the required iommu_dma_map_msi_msg() when composing the MSI message,
otherwise the interrupts will not work.Signed-off-by: Laurentiu Tudor
Signed-off-by: Thomas Gleixner
Cc: jason@lakedaemon.net
Cc: marc.zyngier@arm.com
Cc: zhiqiang.hou@nxp.com
Cc: minghuan.lian@nxp.com
Link: https://lkml.kernel.org/r/20180605122727.12831-1-laurentiu.tudor@nxp.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2018
1 commit
-
commit c1797b11a09c8323c92b074fd48b89a936c991d0 upstream.
On a NUMA system, if an ITS is local to an offline node, the ITS driver may
pick an offline CPU to bind the LPI. In this case, pick an online CPU (and
the first one will do).But on some systems, binding an LPI to non-local node CPU may cause
deadlock (see Cavium erratum 23144). In this case, just fail the activate
and return an error code.Signed-off-by: Yang Yingliang
Signed-off-by: Marc Zyngier
Signed-off-by: Thomas Gleixner
Cc: Jason Cooper
Cc: Alexandre Belloni
Cc: Sumit Garg
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180622095254.5906-5-marc.zyngier@arm.com
Signed-off-by: Greg Kroah-Hartman
09 May, 2018
1 commit
-
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias
Signed-off-by: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: timur@codeaurora.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv@codeaurora.org
Signed-off-by: Greg Kroah-Hartman
26 Apr, 2018
2 commits
-
[ Upstream commit b6dd4d83dc2f78cebc9a7e6e7e4bc2be4d29b94d ]
The pr_debug() in gic-v3 gic_send_sgi() can trigger a circular locking
warning:GICv3: CPU10: ICC_SGI1R_EL1 5000400
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #1 Tainted: G W
------------------------------------------------------
dynamic_debug01/1873 is trying to acquire lock:
((console_sem).lock){-...}, at: [] down_trylock+0x20/0x4cbut task is already holding lock:
(&rq->lock){-.-.}, at: [] __task_rq_lock+0x54/0xdcwhich lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&rq->lock){-.-.}:
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock+0x4c/0x60
task_fork_fair+0x3c/0x148
sched_fork+0x10c/0x214
copy_process.isra.32.part.33+0x4e8/0x14f0
_do_fork+0xe8/0x78c
kernel_thread+0x48/0x54
rest_init+0x34/0x2a4
start_kernel+0x45c/0x488-> #1 (&p->pi_lock){-.-.}:
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
try_to_wake_up+0x48/0x600
wake_up_process+0x28/0x34
__up.isra.0+0x60/0x6c
up+0x60/0x68
__up_console_sem+0x4c/0x7c
console_unlock+0x328/0x634
vprintk_emit+0x25c/0x390
dev_vprintk_emit+0xc4/0x1fc
dev_printk_emit+0x88/0xa8
__dev_printk+0x58/0x9c
_dev_info+0x84/0xa8
usb_new_device+0x100/0x474
hub_port_connect+0x280/0x92c
hub_event+0x740/0xa84
process_one_work+0x240/0x70c
worker_thread+0x60/0x400
kthread+0x110/0x13c
ret_from_fork+0x10/0x18-> #0 ((console_sem).lock){-...}:
validate_chain.isra.34+0x6e4/0xa20
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
down_trylock+0x20/0x4c
__down_trylock_console_sem+0x3c/0x9c
console_trylock+0x20/0xb0
vprintk_emit+0x254/0x390
vprintk_default+0x58/0x90
vprintk_func+0xbc/0x164
printk+0x80/0xa0
__dynamic_pr_debug+0x84/0xac
gic_raise_softirq+0x184/0x18c
smp_cross_call+0xac/0x218
smp_send_reschedule+0x3c/0x48
resched_curr+0x60/0x9c
check_preempt_curr+0x70/0xdc
wake_up_new_task+0x310/0x470
_do_fork+0x188/0x78c
SyS_clone+0x44/0x50
__sys_trace_return+0x0/0x4other info that might help us debug this:
Chain exists of:
(console_sem).lock --> &p->pi_lock --> &rq->lockPossible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&rq->lock);
lock(&p->pi_lock);
lock(&rq->lock);
lock((console_sem).lock);*** DEADLOCK ***
2 locks held by dynamic_debug01/1873:
#0: (&p->pi_lock){-.-.}, at: [] wake_up_new_task+0x40/0x470
#1: (&rq->lock){-.-.}, at: [] __task_rq_lock+0x54/0xdcstack backtrace:
CPU: 10 PID: 1873 Comm: dynamic_debug01 Tainted: G W 4.15.0+ #1
Hardware name: GIGABYTE R120-T34-00/MT30-GS2-00, BIOS T48 10/02/2017
Call trace:
dump_backtrace+0x0/0x188
show_stack+0x24/0x2c
dump_stack+0xa4/0xe0
print_circular_bug.isra.31+0x29c/0x2b8
check_prev_add.constprop.39+0x6c8/0x6dc
validate_chain.isra.34+0x6e4/0xa20
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
down_trylock+0x20/0x4c
__down_trylock_console_sem+0x3c/0x9c
console_trylock+0x20/0xb0
vprintk_emit+0x254/0x390
vprintk_default+0x58/0x90
vprintk_func+0xbc/0x164
printk+0x80/0xa0
__dynamic_pr_debug+0x84/0xac
gic_raise_softirq+0x184/0x18c
smp_cross_call+0xac/0x218
smp_send_reschedule+0x3c/0x48
resched_curr+0x60/0x9c
check_preempt_curr+0x70/0xdc
wake_up_new_task+0x310/0x470
_do_fork+0x188/0x78c
SyS_clone+0x44/0x50
__sys_trace_return+0x0/0x4
GICv3: CPU0: ICC_SGI1R_EL1 12000This could be fixed with printk_deferred() but that might lessen its
usefulness for debugging. So change it to pr_devel to keep it out of
production kernels. Developers working on gic-v3 can enable it as
needed in their kernels.Signed-off-by: Mark Salter
Signed-off-by: Marc Zyngier
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 95a2562590c2f64a0398183f978d5cf3db6d0284 ]
On some platforms there's an ITS available but it's not enabled
because reading or writing the registers is denied by the
firmware. In fact, reading or writing them will cause the system
to reset. We could remove the node from DT in such a case, but
it's better to skip nodes that are marked as "disabled" in DT so
that we can describe the hardware that exists and use the status
property to indicate how the firmware has configured things.Cc: Stuart Yoder
Cc: Laurentiu Tudor
Cc: Greg Kroah-Hartman
Cc: Marc Zyngier
Cc: Rajendra Nayak
Signed-off-by: Stephen Boyd
Signed-off-by: Marc Zyngier
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
24 Apr, 2018
1 commit
-
commit aa08192a254d362a4d5317647a81de6996961aef upstream.
Most MMIO GIC register accesses use a 1-hot bit scheme that
avoids requiring any form of locking. This isn't true for the
GICD_ICFGRn registers, which require a RMW sequence.Unfortunately, we seem to be missing a lock for these particular
accesses, which could result in a race condition if changing the
trigger type on any two interrupts within the same set of 16
interrupts (and thus controlled by the same CFGR register).Introduce a private lock in the GIC common comde for this
particular case, making it cover both GIC implementations
in one go.Cc: stable@vger.kernel.org
Signed-off-by: Aniruddha Banerjee
[maz: updated changelog]
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
12 Apr, 2018
1 commit
-
[ Upstream commit ebe2f8718007d5a1238bb3cb8141b5bb2b4d5773 ]
The ACPI specification says OS shouldn't attempt to use GICC configuration
parameters if the flag ACPI_MADT_ENABLED is cleared. The ARM64-SMP code
skips the disabled GICC entries but not causing any issue. However the
current GICv3 driver probe bails out causing kernel panic() instead of
skipping the disabled GICC interfaces. This issue happens on systems
where redistributor regions are not in the always-on power domain and
one of GICC interface marked with ACPI_MADT_ENABLED=0.This patch does the two things to fix the panic.
- Don't return an error in gic_acpi_match_gicc() for disabled GICC entry.
- No need to keep GICR region information for disabled GICC entry.Observed kernel crash on QDF2400 platform GICC entry is disabled.
Kernel crash traces:
Kernel panic - not syncing: No interrupt controller found.
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26
[] dump_backtrace+0x0/0x218
[] show_stack+0x14/0x20
[] dump_stack+0x98/0xb8
[] panic+0x118/0x26c
[] init_IRQ+0x24/0x2c
[] start_kernel+0x230/0x394
[] __primary_switched+0x64/0x6c
---[ end Kernel panic - not syncing: No interrupt controller found.Disabled GICC subtable example:
Subtable Type : 0B [Generic Interrupt Controller]
Length : 50
Reserved : 0000
CPU Interface Number : 0000003D
Processor UID : 0000003D
Flags (decoded below) : 00000000
Processor Enabled : 0
Performance Interrupt Trig Mode : 0
Virtual GIC Interrupt Trig Mode : 0
Parking Protocol Version : 00000000
Performance Interrupt : 00000017
Parked Address : 0000000000000000
Base Address : 0000000000000000
Virtual GIC Base Address : 0000000000000000
Hypervisor GIC Base Address : 0000000000000000
Virtual GIC Interrupt : 00000019
Redistributor Base Address : 0000FFFF88F40000
ARM MPIDR : 000000000000000D
Efficiency Class : 00
Reserved : 000000
Signed-off-by: Shanker Donthineni
Signed-off-by: Marc ZyngierSigned-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
21 Mar, 2018
1 commit
-
commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream.
When struct its_device instances are created, the nr_ites member
will be set to a power of 2 that equals or exceeds the requested
number of MSIs passed to the msi_prepare() callback. At the same
time, the LPI map is allocated to be some multiple of 32 in size,
where the allocated size may be less than the requested size
depending on whether a contiguous range of sufficient size is
available in the global LPI bitmap.This may result in the situation where the nr_ites < nr_lpis, and
since nr_ites is what we program into the hardware when we map the
device, the additional LPIs will be non-functional.For bog standard hardware, this does not really matter. However,
in cases where ITS device IDs are shared between different PCIe
devices, we may end up allocating these additional LPIs without
taking into account that they don't actually work.So let's make nr_ites at least 32. This ensures that all allocated
LPIs are 'live', and that its_alloc_device_irq() will fail when
attempts are made to allocate MSIs beyond what was allocated in
the first place.Signed-off-by: Ard Biesheuvel
[maz: updated comment]
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
28 Feb, 2018
2 commits
-
commit 285cb4f62319737e6538252cf1a67ce9da5cf3d5 upstream.
Commit 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading
GIC_SH_MASK*") removed the read of the hardware mask register when
handling shared interrupts, instead using the driver's shadow pcpu_masks
entry as the effective mask. Unfortunately this did not take account of
the write to pcpu_masks during gic_shared_irq_domain_map, which
effectively unmasks the interrupt early. If an interrupt is asserted,
gic_handle_shared_int decodes and processes the interrupt even though it
has not yet been unmasked via gic_unmask_irq, which also sets the
appropriate bit in pcpu_masks.On the MIPS Boston board, when a console command line of
"console=ttyS0,115200n8r" is passed, the modem status IRQ is enabled in
the UART, which is immediately raised to the GIC. The interrupt has been
mapped, but no handler has yet been registered, nor is it expected to be
unmasked. However, the write to pcpu_masks in gic_shared_irq_domain_map
has effectively unmasked it, resulting in endless reports of:[ 5.058454] irq 13, desc: ffffffff80a7ad80, depth: 1, count: 0, unhandled: 0
[ 5.062057] ->handle_irq(): ffffffff801b1838,
[ 5.062175] handle_bad_irq+0x0/0x2c0Where IRQ 13 is the UART interrupt.
To fix this, just remove the write to pcpu_masks in
gic_shared_irq_domain_map. The existing write in gic_unmask_irq is the
correct place for what is now the effective unmasking.Cc: stable@vger.kernel.org
Fixes: 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading GIC_SH_MASK*")
Signed-off-by: Matt Redfearn
Reviewed-by: Paul Burton
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman -
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.Cc: stable@vger.kernel.org
Acked-by: Will Deacon ,
Signed-off-by: Shanker Donthineni
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
14 Dec, 2017
1 commit
-
[ Upstream commit e9990d70e8a063a7b894c5cbb99f630a0f41200d ]
The comparison of u32 nregs being less than zero is never true since
nregs is unsigned. Fix this by making nregs a signed integer.Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Colin Ian King
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
Cc: kernel-janitors@vger.kernel.org
Cc: Jason Cooper
Link: https://lkml.kernel.org/r/20171117183553.2739-1-colin.king@canonical.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
30 Nov, 2017
1 commit
-
commit 00ee9a1ca5080202bc37b44e998c3b2c74d45817 upstream.
Fix child-node lookup during initialisation, which ended up searching
the whole device tree depth-first starting at the parent rather than
just matching on its children.To make things worse, the parent gic node was prematurely freed, while
the ppi-partitions node was leaked.Fixes: e3825ba1af3a ("irqchip/gic-v3: Add support for partitioned PPIs")
Signed-off-by: Johan Hovold
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
06 Nov, 2017
1 commit
-
Pull irq fix from Ingo Molnar:
"An irqchip driver init fix"* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/irq-mvebu-gicp: Add missing spin_lock init
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
01 Nov, 2017
1 commit
-
A spin lock is used in the irq-mvebu-gicp driver, but it is never
initialized. This patch adds the missing spin_lock_init() call in the
driver's probe function.Fixes: a68a63cb4dfc ("irqchip/irq-mvebu-gicp: Add new driver for Marvell GICP")
Signed-off-by: Antoine Tenart
Signed-off-by: Thomas Gleixner
Reviewed-by: gregory.clement@free-electrons.com
Acked-by: marc.zyngier@arm.com
Cc: thomas.petazzoni@free-electrons.com
Cc: andrew@lunn.ch
Cc: jason@lakedaemon.net
Cc: nadavh@marvell.com
Cc: miquel.raynal@free-electrons.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: sebastian.hesselbarth@gmail.com
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20171025072326.21030-1-antoine.tenart@free-electrons.com
13 Oct, 2017
4 commits
-
The only usage of the irq_gc_mask_disable_reg_and_ack() function
is by the Tango irqchip driver. This usage is replaced by the
irq_gc_mask_disable_and_ack_set() function since it provides the
intended functionality.Fixes: 4bba66899ac6 ("irqchip/tango: Add support for Sigma Designs SMP86xx/SMP87xx interrupt controller")
Acked-by: Mans Rullgard
Acked-by: Marc Gonzalez
Signed-off-by: Florian Fainelli
Signed-off-by: Doug Berger
Signed-off-by: Marc Zyngier -
The current ITS driver works fine as long as normal memory and GICR
regions are located within the lower 48bit (>=0 &&
Signed-off-by: Marc Zyngier -
The VCPU table consists of vPE entries, and its size provides the number
of VPEs supported by GICv4 hardware. Unfortunately the maximum size of
the VPE table is not discoverable like Device table. All VLPI commands
limits the number of bits to 16 to hold VPEID, which is index into VCPU
table. Don't apply DEVID bits for VCPU table instead assume maximum bits
to 16.ITS log messages on QDF2400 without fix:
allocated 524288 Devices (indirect, esz 8, psz 64K, shr 1)
allocated 8192 Interrupt Collections (flat, esz 8, psz 64K, shr 1)
Virtual CPUs Table too large, reduce ids 32->26
Virtual CPUs too large, reduce ITS pages 8192->256
allocated 2097152 Virtual CPUs (flat, esz 8, psz 64K, shr 1)ITS log messages on QDF2400 with fix:
allocated 524288 Devices (indirect, esz 8, psz 64K, shr 1)
allocated 8192 Interrupt Collections (flat, esz 8, psz 64K, shr 1)
allocated 65536 Virtual CPUs (flat, esz 8, psz 64K, shr 1)Signed-off-by: Shanker Donthineni
Signed-off-by: Marc Zyngier -
The driver probe path hits 'BUG_ON(entries != vpe_proxy.dev->nr_ites)'
on systems where it has VLPI capability, doesn't support direct LPI
feature and boot with a single CPU.Relax the BUG_ON() condition to fix the issue.
Signed-off-by: Shanker Donthineni
Signed-off-by: Marc Zyngier
26 Sep, 2017
2 commits
-
Commit 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading
GIC_SH_MASK*") adjusted the way we handle masking interrupts to set &
clear the interrupt's bit in each pcpu_mask. This allows us to avoid
needing to read the GIC mask registers and perform a bitwise and of
their values with the pending & pcpu_masks.Unfortunately this didn't quite work for IPIs, which were mapped to a
particular CPU/VP during initialisation but never set the affinity or
effective_affinity fields of their struct irq_desc. This led to them
losing their affinity when gic_unmask_irq() was called for them, and
they'd all become affine to cpu0.Fix this by:
1) Setting the effective affinity of interrupts in
gic_shared_irq_domain_map(), which is where we actually map an
interrupt to a CPU/VP. This ensures that the effective affinity mask
is always valid, not just after explicitly setting affinity.2) Using an interrupt's effective affinity when unmasking it, which
prevents gic_unmask_irq() from unintentionally changing which
pcpu_mask includes an interrupt.Fixes: 7778c4b27cbe ("irqchip: mips-gic: Use pcpu_masks to avoid reading GIC_SH_MASK*")
Signed-off-by: Paul Burton
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
Cc: Jason Cooper
Link: https://lkml.kernel.org/r/20170922062440.23701-3-paul.burton@imgtec.com -
The MIPS GIC driver is incorrectly using __fls to shift registers,
intending to shift to the least significant bit of a value based upon
its mask but instead shifting off all but the value's top bit. It should
actually be using __ffs to shift to the first, not last, bit of the
value.Apparently the system I used when testing commit 3680746abd87
("irqchip: mips-gic: Convert remaining shared reg access to new
accessors") and commit b2b2e584ceab ("irqchip: mips-gic: Clean up mti,
reserved-cpu-vectors handling") managed to work correctly despite this
issue, but not all systems do...Fixes: 3680746abd87 ("irqchip: mips-gic: Convert remaining shared reg access to new accessors")
Fixes: b2b2e584ceab ("irqchip: mips-gic: Clean up mti, reserved-cpu-vectors handling")
Signed-off-by: Paul Burton
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
Cc: Jason Cooper
Link: https://lkml.kernel.org/r/20170922062440.23701-2-paul.burton@imgtec.com
20 Sep, 2017
1 commit
-
The write_gic_smask() & write_gic_rmask() functions take a shared
interrupt number as a parameter, but we're incorrectly providing them a
bitmask with the shared interrupt's bit set. This effectively means that
we mask or unmask the shared interrupt 1<
Fixes: 68898c8765f4 ("irqchip: mips-gic: Drop gic_(re)set_mask() functions")
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Ralf Baechle
Cc: Thomas Gleixner
Cc: linux-mips@linux-mips.org
Signed-off-by: Marc Zyngier