Age | Commit message (Collapse) | Author | Files | Lines |
|
In the function htpic_of_init(), when kzalloc htpic fails, it should
return -ENOMEM directly, no need to execute "goto" to kfree.
Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
We need to have a definition for cpu_logical_map[] which on ARM
platforms is provided by asm/smp_plat.h. This header is not
automatically included from linux/smp.h and untangling it is a bit
difficult.
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The UPG_AUX_AON_INTR2 Level 2 interrupt controller node is defined with
the "brcm,upg-aux-aon-l2-intc" compatible string in Device Tree and
behaves as an edge triggered standard Broadcom STB L2 interrupt
controller.
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The HIF_SPI_INTR2 Level 2 interrupt controller node is defined with the
"brcm,hif-spi-l2-intc" compatible string in Device Tree and behaves as
an edge triggered standard Broadcom STB L2 interrupt controller.
Signed-off-by: Kamal Dasu <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Utilize the Broadcom interrupt controller standard property
"brcm,irq-can-wake" to flag whether this particular interrupt controller
instance is wake-up capable.
Since we do not know what type of parent interrupt controller we are
interfaced with, ensure that enable_irq_wake() is called early on.
Signed-off-by: Justin Chen <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Utilize the Broadcom interrupt controller standard property
"brcm,irq-can-wake" to flag whether this particular interrupt controller
instance is wake-up capable.
Since we do not know what type of parent interrupt controller we are
interfaced with, ensure that enable_irq_wake() is called early on.
Signed-off-by: Justin Chen <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Pull kvm fixes from Paolo Bonzini:
"Bugfixes and a one-liner patch to silence a sparse warning"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: arm64: Stop clobbering x0 for HVC_SOFT_RESTART
KVM: arm64: PMU: Fix per-CPU access in preemptible context
KVM: VMX: Use KVM_POSSIBLE_CR*_GUEST_BITS to initialize guest/host masks
KVM: x86: Mark CR4.TSD as being possibly owned by the guest
KVM: x86: Inject #GP if guest attempts to toggle CR4.LA57 in 64-bit mode
kvm: use more precise cast and do not drop __user
KVM: x86: bit 8 of non-leaf PDPEs is not reserved
KVM: X86: Fix async pf caused null-ptr-deref
KVM: arm64: vgic-v4: Plug race between non-residency and v4.1 doorbell
KVM: arm64: pvtime: Ensure task delay accounting is enabled
KVM: arm64: Fix kvm_reset_vcpu() return code being incorrect with SVE
KVM: arm64: Annotate hyp NMI-related functions as __always_inline
KVM: s390: reduce number of IO pins to 1
|
|
In an effort to enable -Wcast-function-type in the top-level Makefile to
support Control Flow Integrity builds, there are the need to remove all
the function callback casts.
To do this, modify the IRQCHIP_ACPI_DECLARE macro to use the new defined
macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY instead of the macro
ACPI_DECLARE_PROBE_ENTRY. This is necessary to be able to initialize the
the acpi_probe_entry struct using the probe_subtbl field instead of the
probe_table field and avoid function cast mismatches.
Also, modify the prototype of the functions used by the invocation of the
IRQCHIP_ACPI_DECLARE macro to match all the parameters.
Co-developed-by: Marc Zyngier <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Oscar Carter <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Add support for SAM9X60 RTT fixup.
Signed-off-by: Claudiu Beznea <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/20200616230923.GA24937@embeddedor
|
|
This driver may take a regular spinlock when a raw spinlock
(irq_desc->lock) is already taken which results in the following
lockdep splat:
=============================
[ BUG: Invalid wait context ]
5.7.0-rc7 #1 Not tainted
-----------------------------
swapper/0/0 is trying to lock:
ffffff800303b798 (&chip_data->lock){....}-{3:3}, at: mtk_sysirq_set_type+0x48/0xc0
other info that might help us debug this:
context-{5:5}
2 locks held by swapper/0/0:
#0: ffffff800302ee68 (&desc->request_mutex){....}-{4:4}, at: __setup_irq+0xc4/0x8a0
#1: ffffff800302ecf0 (&irq_desc_lock_class){....}-{2:2}, at: __setup_irq+0xe4/0x8a0
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc7 #1
Hardware name: Pumpkin MT8516 (DT)
Call trace:
dump_backtrace+0x0/0x180
show_stack+0x14/0x20
dump_stack+0xd0/0x118
__lock_acquire+0x8c8/0x2270
lock_acquire+0xf8/0x470
_raw_spin_lock_irqsave+0x50/0x78
mtk_sysirq_set_type+0x48/0xc0
__irq_set_trigger+0x58/0x170
__setup_irq+0x420/0x8a0
request_threaded_irq+0xd8/0x190
timer_of_init+0x1e8/0x2c4
mtk_gpt_init+0x5c/0x1dc
timer_probe+0x74/0xf4
time_init+0x14/0x44
start_kernel+0x394/0x4f0
Replace the spinlock_t with raw_spinlock_t to avoid this warning.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
There are registers and functions in the header file
that are only used inside the driver. Move these into
the driver.
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
We got rid of the last user of the cascaded intialization
from board files so drop this API.
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
It should be "ti.com" instead of "ticom".
Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver")
Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Grygorii Strashko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When call function devm_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.
Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver")
Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Grygorii Strashko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
In the function ti_sci_inta_set_type(), the statement "return -EINVAL;"
out of switch case is dead code, remove it.
Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver")
Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Grygorii Strashko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When making a vPE non-resident because it has hit a blocking WFI,
the doorbell can fire at any time after the write to the RD.
Crucially, it can fire right between the write to GICR_VPENDBASER
and the write to the pending_last field in the its_vpe structure.
This means that we would overwrite pending_last with stale data,
and potentially not wakeup until some unrelated event (such as
a timer interrupt) puts the vPE back on the CPU.
GICv4 isn't affected by this as we actively mask the doorbell on
entering the guest, while GICv4.1 automatically manages doorbell
delivery without any hypervisor-driven masking.
Use the vpe_lock to synchronize such update, which solves the
problem altogether.
Fixes: ae699ad348cdc ("irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction layer")
Reported-by: Zenghui Yu <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
|
|
The GIC driver uses a RMW sequence to update the affinity, and
relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences
to update it atomically.
But these sequences only expand into anything meaningful if
the BL_SWITCHER option is selected, which almost never happens.
It also turns out that using a RMW and locks is just as silly,
as the GIC distributor supports byte accesses for the GICD_TARGETRn
registers, which when used make the update atomic by definition.
Drop the terminally broken code and replace it by a byte write.
Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature")
Cc: [email protected]
Signed-off-by: Marc Zyngier <[email protected]>
|
|
Anup originally re-spun his patch set to include this fix, but it was a bit too
late for my PR so I've split it out.
Signed-off-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
readx_poll_timeout() can sleep if @sleep_us is specified by the caller,
and is therefore unsafe to be used inside the atomic context, which is
this case when we use it to poll the GICR_VPENDBASER.Dirty bit in
irq_set_vcpu_affinity() callback.
Let's convert to its atomic version instead which helps to get the v4.1
board back to life!
Fixes: 96806229ca03 ("irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling")
Signed-off-by: Zenghui Yu <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
PCH MSI driver's menuconfig entry was wrong. Fix it.
Fixes: 632dcc2c75ef ("irqchip: Add Loongson PCH MSI controller")
Signed-off-by: Jiaxun Yang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Instead of directly calling RISC-V timer interrupt handler from
RISC-V local interrupt conntroller driver, this patch implements
RISC-V timer interrupt as a per-CPU interrupt using per-CPU APIs
of Linux IRQ subsystem.
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Atish Patra <[email protected]>
Reviewed-by: Marc Zyngier <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
The RISC-V per-HART local interrupt controller manages software
interrupts, timer interrupts, external interrupts (which are routed
via the platform level interrupt controller) and other per-HART
local interrupts.
We add a driver for the RISC-V local interrupt controller, which
eventually replaces the RISC-V architecture code, allowing for a
better split between arch code and drivers.
The driver is compliant with RISC-V Hart-Level Interrupt Controller
DT bindings located at:
Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
Co-developed-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Anup Patel <[email protected]>
[Palmer: Cleaned up warnings]
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
The plic_find_hart_id() can be useful to other interrupt controller
drivers (such as RISC-V local interrupt driver) so we rename this
function to riscv_of_parent_hartid() and place it in arch directory
along with riscv_of_processor_hartid().
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Atish Patra <[email protected]>
Reviewed-by: Palmer Dabbelt <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
Reviewed-by: Marc Zyngier <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
non-MIPS platforms
This commit:
818e915fbac5: ("irqchip: Add Loongson HyperTransport Vector support")
Added a MIPS-only driver, but turned on compilation on all other architectures as well:
config LOONGSON_HTVEC
bool "Loongson3 HyperTransport Interrupt Vector Controller"
depends on MACH_LOONGSON64 || COMPILE_TEST
But this driver was never build tested on any other architecture than MIPS:
drivers/irqchip/irq-loongson-htvec.c: In function ‘htvec_irq_dispatch’:
drivers/irqchip/irq-loongson-htvec.c:59:3: error: implicit declaration of function ‘spurious_interrupt’; did you mean ‘smp_reboot_interrupt’? [-Werror=implicit-function-declaration]
Because spurious_interrupt() only exists on MIPS.
So make it MIPS-only.
Signed-off-by: Ingo Molnar <[email protected]>
Cc: Jiaxun Yang <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
This controller appears on Loongson LS7A family of PCH to transform
interrupts from PCI MSI into HyperTransport vectorized interrrupts
and send them to procrssor's HT vector controller.
Signed-off-by: Jiaxun Yang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This controller appears on Loongson LS7A family of PCH to transform
interrupts from devices into HyperTransport vectorized interrrupts
and send them to procrssor's HT vector controller.
Signed-off-by: Jiaxun Yang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This controller appears on Loongson-3 chips for receiving interrupt
vectors from PCH's PIC and PCH's PCIe MSI interrupts.
Signed-off-by: Jiaxun Yang <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
We improve PLIC banner to help distinguish multiple PLIC instances
in boot time prints.
Signed-off-by: Anup Patel <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Palmer Dabbelt <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
For multiple PLIC instances, the plic_init() is called once for each
PLIC instance. Due to this we have two issues:
1. cpuhp_setup_state() is called multiple times
2. plic_starting_cpu() can crash for boot CPU if cpuhp_setup_state()
is called before boot CPU PLIC handler is available.
Address both issues by only initializing the HP notifiers when
the boot CPU setup is complete.
Fixes: f1ad1133b18f ("irqchip/sifive-plic: Add support for multiple PLICs")
Signed-off-by: Anup Patel <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Palmer Dabbelt <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
For multiple PLIC instances, each PLIC can only target a subset of
CPUs which is represented by "lmask" in the "struct plic_priv".
Currently, the default irq affinity for each PLIC interrupt is all
online CPUs which is illegal value for default irq affinity when we
have multiple PLIC instances. To fix this, we now set "lmask" as the
default irq affinity in for each interrupt in plic_irqdomain_map().
Fixes: f1ad1133b18f ("irqchip/sifive-plic: Add support for multiple PLICs")
Signed-off-by: Anup Patel <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Palmer Dabbelt <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
(E)PPIs are per-CPU interrupts, so we want each CPU to go and enable them
via enable_percpu_irq(); this also means we want IRQ_NOAUTOEN for them as
the autoenable would lead to calling irq_enable() instead of the more
appropriate irq_percpu_enable().
Calling irq_set_percpu_devid() is enough to get just that since it trickles
down to irq_set_percpu_devid_flags(), which gives us IRQ_NOAUTOEN (and a
few others). Setting IRQ_NOAUTOEN *again* right after this call is just
redundant, so don't do it.
Signed-off-by: Valentin Schneider <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When mapping a LPI, the ITS driver picks the first possible
affinity, which is in most cases CPU0, assuming that if
that's not suitable, someone will come and set the affinity
to something more interesting.
It apparently isn't the case, and people complain of poor
performance when many interrupts are glued to the same CPU.
So let's place the interrupts by finding the "least loaded"
CPU (that is, the one that has the fewer LPIs mapped to it).
So called 'managed' interrupts are an interesting case where
the affinity is actually dictated by the kernel itself, and
we should honor this.
Reported-by: John Garry <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Tested-by: John Garry <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
In order to improve the distribution of LPIs among CPUs, let start by
tracking the number of LPIs assigned to CPUs, both for managed and
non-managed interrupts (as separate counters).
Signed-off-by: Marc Zyngier <[email protected]>
Tested-by: John Garry <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
A PLIC may not be connected to all the cores. In that case, nr_contexts
may be less than num_possible_cpus. This requirement is only valid a single
PLIC is the only interrupt controller for the whole system.
Signed-off-by: Atish Patra <[email protected]>
Signed-off-by: "Wesley W. Terpstra" <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Palmer Dabbelt <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[Atish: Modified the commit text]
|
|
With an SMP configuration, gic_smp_init() calls set_smp_cross_call().
set_smp_cross_call() is marked with "__init".
So gic_smp_init() should also be marked with "__init".
gic_smp_init() is only called from gic_init_bases().
gic_init_bases() is also marked with "__init";
So marking gic_smp_init() with "__init" is fine.
Signed-off-by: Ingo Rohloff <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
|
|
Fix the following sparse warning:
drivers/irqchip/irq-bcm7038-l1.c:419:12: warning: symbol
'bcm7038_l1_of_init' was not declared. Should it be static?
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Fix the following sparse warning:
drivers/irqchip/irq-mvebu-icu.c:69:1: warning: symbol 'legacy_bindings'
was not declared. Should it be static?
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Running a lockedp-enabled kernel on a vim3l board (Amlogic SM1)
leads to the following splat:
[ 13.557138] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
[ 13.587485] ip/456 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 13.625922] ffff000059908cf0 (&irq_desc_lock_class){-.-.}-{2:2}, at: __setup_irq+0xf8/0x8d8
[ 13.632273] which would create a new lock dependency:
[ 13.637272] (&irq_desc_lock_class){-.-.}-{2:2} -> (&ctl->lock){+.+.}-{2:2}
[ 13.644209]
[ 13.644209] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 13.654122] (&irq_desc_lock_class){-.-.}-{2:2}
[ 13.654125]
[ 13.654125] ... which became HARDIRQ-irq-safe at:
[ 13.664759] lock_acquire+0xec/0x368
[ 13.666926] _raw_spin_lock+0x60/0x88
[ 13.669979] handle_fasteoi_irq+0x30/0x178
[ 13.674082] generic_handle_irq+0x38/0x50
[ 13.678098] __handle_domain_irq+0x6c/0xc8
[ 13.682209] gic_handle_irq+0x5c/0xb0
[ 13.685872] el1_irq+0xd0/0x180
[ 13.689010] arch_cpu_idle+0x40/0x220
[ 13.692732] default_idle_call+0x54/0x60
[ 13.696677] do_idle+0x23c/0x2e8
[ 13.699903] cpu_startup_entry+0x30/0x50
[ 13.703852] rest_init+0x1e0/0x2b4
[ 13.707301] arch_call_rest_init+0x18/0x24
[ 13.711449] start_kernel+0x4ec/0x51c
[ 13.715167]
[ 13.715167] to a HARDIRQ-irq-unsafe lock:
[ 13.722426] (&ctl->lock){+.+.}-{2:2}
[ 13.722430]
[ 13.722430] ... which became HARDIRQ-irq-unsafe at:
[ 13.732319] ...
[ 13.732324] lock_acquire+0xec/0x368
[ 13.735985] _raw_spin_lock+0x60/0x88
[ 13.739452] meson_gpio_irq_domain_alloc+0xcc/0x290
[ 13.744392] irq_domain_alloc_irqs_hierarchy+0x24/0x60
[ 13.749586] __irq_domain_alloc_irqs+0x160/0x2f0
[ 13.754254] irq_create_fwspec_mapping+0x118/0x320
[ 13.759073] irq_create_of_mapping+0x78/0xa0
[ 13.763360] of_irq_get+0x6c/0x80
[ 13.766701] of_mdiobus_register_phy+0x10c/0x238 [of_mdio]
[ 13.772227] of_mdiobus_register+0x158/0x380 [of_mdio]
[ 13.777388] mdio_mux_init+0x180/0x2e8 [mdio_mux]
[ 13.782128] g12a_mdio_mux_probe+0x290/0x398 [mdio_mux_meson_g12a]
[ 13.788349] platform_drv_probe+0x5c/0xb0
[ 13.792379] really_probe+0xe4/0x448
[ 13.795979] driver_probe_device+0xe8/0x140
[ 13.800189] __device_attach_driver+0x94/0x120
[ 13.804639] bus_for_each_drv+0x84/0xd8
[ 13.808474] __device_attach+0xe4/0x168
[ 13.812361] device_initial_probe+0x1c/0x28
[ 13.816592] bus_probe_device+0xa4/0xb0
[ 13.820430] deferred_probe_work_func+0xa8/0x100
[ 13.825064] process_one_work+0x264/0x688
[ 13.829088] worker_thread+0x4c/0x458
[ 13.832768] kthread+0x154/0x158
[ 13.836018] ret_from_fork+0x10/0x18
[ 13.839612]
[ 13.839612] other info that might help us debug this:
[ 13.839612]
[ 13.850354] Possible interrupt unsafe locking scenario:
[ 13.850354]
[ 13.855720] CPU0 CPU1
[ 13.858774] ---- ----
[ 13.863242] lock(&ctl->lock);
[ 13.866330] local_irq_disable();
[ 13.872233] lock(&irq_desc_lock_class);
[ 13.878705] lock(&ctl->lock);
[ 13.884297] <Interrupt>
[ 13.886857] lock(&irq_desc_lock_class);
[ 13.891014]
[ 13.891014] *** DEADLOCK ***
The issue can occur when CPU1 is doing something like irq_set_type()
and CPU0 performing an interrupt allocation, for example. Taking
an interrupt (like the one being reconfigured) would lead to a deadlock.
A solution to this is:
- Reorder the locking so that meson_gpio_irq_update_bits takes the lock
itself at all times, instead of relying on the caller to lock or not,
hence making the RMW sequence atomic,
- Rework the critical section in meson_gpio_irq_request_channel to only
cover the allocation itself, and let the gpio_irq_sel_pin callback
deal with its own locking if required,
- Take the private spin-lock with interrupts disabled at all times
Reviewed-by: Jerome Brunet <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
|
|
As per the PLIC specification, maximum priority threshold value is 0x7
not 0xF. Even though it doesn't cause any error in qemu/hifive unleashed,
there may be some implementation which checks the upper bound resulting in
an illegal access.
Fixes: ccbe80bad571 ("irqchip/sifive-plic: Enable/Disable external interrupts upon cpu online/offline")
Signed-off-by: Atish Patra <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The ti_sci_inta_irq_handler() does not take into account INTA IRQs state
(masked/unmasked) as it uses INTA_STATUS_CLEAR_j register to get INTA IRQs
status, which provides raw status value.
This causes hard IRQ handlers to be called or threaded handlers to be
scheduled many times even if corresponding INTA IRQ is masked.
Above, first of all, affects the LEVEL interrupts processing and causes
unexpected behavior up the system stack or crash.
Fix it by using the Interrupt Masked Status INTA_STATUSM_j register which
provides masked INTA IRQs status.
Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver")
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
|
|
Using irq_domain_free_irqs_common() on the irqdomain free path will
leave the MSI descriptor unfreed when platform devices get removed.
Properly free it by MSI domain free function.
Fixes: 9650c60ebfec0 ("irqchip/mbigen: Create irq domain for each mbigen device")
Signed-off-by: Zenghui Yu <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Although the vSGIs are not directly visible to the host, they still
get moved around by the CPU hotplug, for example. This results in
the kernel moaning on the console, such as:
genirq: irq_chip GICv4.1-sgi did not update eff. affinity mask of irq 38
Updating the effective affinity on set_affinity() fixes it.
Reviewed-by: Zenghui Yu <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
|
|
When a vPE is made resident, the GIC starts parsing the virtual pending
table to deliver pending interrupts. This takes place asynchronously,
and can at times take a long while. Long enough that the vcpu enters
the guest and hits WFI before any interrupt has been signaled yet.
The vcpu then exits, blocks, and now gets a doorbell. Rince, repeat.
In order to avoid the above, a (optional on GICv4, mandatory on v4.1)
feature allows the GIC to feedback to the hypervisor whether it is
done parsing the VPT by clearing the GICR_VPENDBASER.Dirty bit.
The hypervisor can then wait until the GIC is ready before actually
running the vPE.
Plug the detection code as well as polling on vPE schedule. While
at it, tidy-up the kernel message that displays the GICv4 optional
features.
Reviewed-by: Zenghui Yu <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Thomas Gleixner:
"Two reverts addressing regressions of the Xilinx interrupt controller
driver which affected the PPC users"
* tag 'irq-urgent-2020-04-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
Revert "irqchip/xilinx: Enable generic irq multi handler"
Revert "irqchip/xilinx: Do not call irq_set_default_host()"
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core
Pull irqchip fixes from Marc Zygnier:
- Partially revert Xilinx changes that break PPC systems
|
|
This reverts commit a0789993bf8266e62fea6b4613945ba081c71e7d, which
breaks a number of PPC platforms.
Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This reverts commit 9c2d4f525c002591f4e0c14a37663663aaba1656, which
breaks a number of PPC platforms.
Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Pull MIPS updates from Thomas Bogendoerfer:
- loongson64 irq rework
- dmi support loongson
- replace setup_irq() by request_irq()
- jazz cleanups
- minor cleanups and fixes
* tag 'mips_5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (44 commits)
MIPS: ralink: mt7621: Fix soc_device introduction
MIPS: Exclude more dsemul code when CONFIG_MIPS_FP_SUPPORT=n
MIPS/tlbex: Fix LDDIR usage in setup_pw() for Loongson-3
MIPS: do not compile generic functions for CONFIG_CAVIUM_OCTEON_SOC
MAINTAINERS: Update Loongson64 entry
MIPS: Loongson64: Load built-in dtbs
MIPS: Loongson64: Add generic dts
dt-bindings: mips: Add loongson boards
MIPS: Loongson64: Drop legacy IRQ code
dt-bindings: interrupt-controller: Add Loongson-3 HTPIC
irqchip: Add driver for Loongson-3 HyperTransport PIC controller
dt-bindings: interrupt-controller: Add Loongson LIOINTC
irqchip: loongson-liointc: Workaround LPC IRQ Errata
irqchip: Add driver for Loongson I/O Local Interrupt Controller
docs: mips: remove no longer needed au1xxx_ide.rst documentation
MIPS: Alchemy: remove no longer used au1xxx_ide.h header
ide: remove no longer used au1xxx-ide driver
MIPS: Add support for Desktop Management Interface (DMI)
firmware: dmi: Add macro SMBIOS_ENTRY_POINT_SCAN_START
MIPS: ralink: mt7621: introduce 'soc_device' initialization
...
|