summaryrefslogtreecommitdiffstats
path: root/drivers/irqchip
AgeCommit message (Collapse)AuthorFilesLines
2020-07-06Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds1-0/+8
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
2020-06-23KVM: arm64: vgic-v4: Plug race between non-residency and v4.1 doorbellMarc Zyngier1-0/+8
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 <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-06-21irqchip/gic: Atomically update affinityMarc Zyngier1-11/+3
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: stable@vger.kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-06-21irqchip/riscv-intc: Fix a typo in a pr_warn()Palmer Dabbelt1-1/+1
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 <palmerdabbelt@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200611175302.253540-1-palmer@dabbelt.com
2020-06-21irqchip/gic-v4.1: Use readx_poll_timeout_atomic() to fix sleep in atomicZenghui Yu1-4/+4
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 <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200605052345.1494-1-yuzenghui@huawei.com
2020-06-21irqchip/loongson-pci-msi: Fix a typo in KconfigJiaxun Yang1-1/+1
PCH MSI driver's menuconfig entry was wrong. Fix it. Fixes: 632dcc2c75ef ("irqchip: Add Loongson PCH MSI controller") Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200530121113.1797678-2-jiaxun.yang@flygoat.com
2020-06-09clocksource/drivers/timer-riscv: Use per-CPU timer interruptAnup Patel1-8/+0
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 <anup.patel@wdc.com> Reviewed-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-06-09irqchip: RISC-V per-HART local interrupt controller driverAnup Patel4-9/+183
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 <palmer@dabbelt.com> Signed-off-by: Anup Patel <anup.patel@wdc.com> [Palmer: Cleaned up warnings] Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2020-06-09RISC-V: Rename and move plic_find_hart_id() to arch directoryAnup Patel1-15/+1
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 <anup.patel@wdc.com> Reviewed-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-06-01irqchip: Fix "Loongson HyperTransport Vector support" driver build on all ↵Ingo Molnar1-1/+1
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 <mingo@kernel.org> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-05-29irqchip: Add Loongson PCH MSI controllerJiaxun Yang3-0/+266
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 <jiaxun.yang@flygoat.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200528152757.1028711-6-jiaxun.yang@flygoat.com
2020-05-29irqchip: Add Loongson PCH PIC controllerJiaxun Yang3-0/+253
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 <jiaxun.yang@flygoat.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200528152757.1028711-4-jiaxun.yang@flygoat.com
2020-05-29irqchip: Add Loongson HyperTransport Vector supportJiaxun Yang3-0/+223
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 <jiaxun.yang@flygoat.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200528152757.1028711-2-jiaxun.yang@flygoat.com
2020-05-25irqchip/sifive-plic: Improve boot prints for multiple PLIC instancesAnup Patel1-2/+2
We improve PLIC banner to help distinguish multiple PLIC instances in boot time prints. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Link: https://lore.kernel.org/r/20200518091441.94843-4-anup.patel@wdc.com
2020-05-25irqchip/sifive-plic: Setup cpuhp once after boot CPU handler is presentAnup Patel1-2/+12
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 <anup.patel@wdc.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200518091441.94843-3-anup.patel@wdc.com
2020-05-25irqchip/sifive-plic: Set default irq affinity in plic_irqdomain_map()Anup Patel1-0/+3
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 <anup.patel@wdc.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200518091441.94843-2-anup.patel@wdc.com
2020-05-25irqchip/gic-v2, v3: Drop extra IRQ_NOAUTOEN setting for (E)PPIsValentin Schneider2-2/+0
(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 <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200521223500.834-1-valentin.schneider@arm.com
2020-05-20irqchip/gic-v3-its: Balance initial LPI affinity across CPUsMarc Zyngier1-27/+100
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 <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1575642904-58295-1-git-send-email-john.garry@huawei.com Link: https://lore.kernel.org/r/20200515165752.121296-3-maz@kernel.org
2020-05-18irqchip/gic-v3-its: Track LPI distribution on a per CPU basisMarc Zyngier1-3/+46
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 <maz@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20200515165752.121296-2-maz@kernel.org
2020-05-18irqchip/sifive-plic: Remove incorrect requirement about number of irq contextsWesley W. Terpstra1-2/+0
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 <atish.patra@wdc.com> Signed-off-by: "Wesley W. Terpstra" <wesley@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Link: https://lore.kernel.org/r/20200512172636.96299-1-atish.patra@wdc.com [Atish: Modified the commit text]
2020-05-18irqchip/gic-v3: Fix missing "__init" for gic_smp_init()Ingo Rohloff1-1/+1
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 <ingo.rohloff@lauterbach.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200422112857.4300-1-ingo.rohloff@lauterbach.com
2020-04-17Merge branch 'irq/gic-v4.1-fixes-5.7' into irq/irqchip-5.7Marc Zyngier2-4/+27
2020-04-17irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() staticJason Yan1-1/+1
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 <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200417074036.46594-1-yanaijie@huawei.com
2020-04-17irqchip/irq-mvebu-icu: Make legacy_bindings staticJason Yan1-1/+1
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 <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200417074046.46771-1-yanaijie@huawei.com
2020-04-17irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock orderMarc Zyngier1-8/+10
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 <jbrunet@baylibre.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-04-17irqchip/sifive-plic: Fix maximum priority threshold valueAtish Patra1-1/+1
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 <atish.patra@wdc.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200403014609.71831-1-atish.patra@wdc.com
2020-04-17irqchip/ti-sci-inta: Fix processing of masked irqsGrygorii Strashko1-1/+2
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 <grygorii.strashko@ti.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20200408191532.31252-1-grygorii.strashko@ti.com Cc: stable@vger.kernel.org
2020-04-17irqchip/mbigen: Free msi_desc on device teardownZenghui Yu1-1/+7
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 <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200408114352.1604-1-yuzenghui@huawei.com
2020-04-16irqchip/gic-v4.1: Update effective affinity of virtual SGIsMarc Zyngier1-0/+1
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 <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-04-16irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signalingMarc Zyngier2-4/+26
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 <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-04-05Merge tag 'irq-urgent-2020-04-05' of ↵Linus Torvalds1-20/+15
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()"
2020-04-01Merge tag 'irqchip-fixes-5.7-1' of ↵Thomas Gleixner1-20/+15
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
2020-04-01Revert "irqchip/xilinx: Enable generic irq multi handler"Marc Zyngier1-20/+14
This reverts commit a0789993bf8266e62fea6b4613945ba081c71e7d, which breaks a number of PPC platforms. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/44b64be7-9240-fd52-af90-e0245220f38b@xilinx.com
2020-04-01Revert "irqchip/xilinx: Do not call irq_set_default_host()"Marc Zyngier1-0/+1
This reverts commit 9c2d4f525c002591f4e0c14a37663663aaba1656, which breaks a number of PPC platforms. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/44b64be7-9240-fd52-af90-e0245220f38b@xilinx.com
2020-03-31Merge tag 'mips_5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds4-0/+441
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 ...
2020-03-30Merge tag 'irq-core-2020-03-30' of ↵Linus Torvalds18-183/+835
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq updates from Thomas Gleixner: "Updates for the interrupt subsystem: Treewide: - Cleanup of setup_irq() which is not longer required because the memory allocator is available early. Most cleanup changes come through the various maintainer trees, so the final removal of setup_irq() is postponed towards the end of the merge window. Core: - Protection against unsafe invocation of interrupt handlers and unsafe interrupt injection including a fixup of the offending PCI/AER error injection mechanism. Invoking interrupt handlers from arbitrary contexts, i.e. outside of an actual interrupt, can cause inconsistent state on the fragile x86 interrupt affinity changing hardware trainwreck. Drivers: - Second wave of support for the new ARM GICv4.1 - Multi-instance support for Xilinx and PLIC interrupt controllers - CPU-Hotplug support for PLIC - The obligatory new driver for X1000 TCU - Enhancements, cleanups and fixes all over the place" * tag 'irq-core-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (58 commits) unicore32: Replace setup_irq() by request_irq() sh: Replace setup_irq() by request_irq() hexagon: Replace setup_irq() by request_irq() c6x: Replace setup_irq() by request_irq() alpha: Replace setup_irq() by request_irq() irqchip/gic-v4.1: Eagerly vmap vPEs irqchip/gic-v4.1: Add VSGI property setup irqchip/gic-v4.1: Add VSGI allocation/teardown irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction layer irqchip/gic-v4.1: Plumb set_vcpu_affinity SGI callbacks irqchip/gic-v4.1: Plumb get/set_irqchip_state SGI callbacks irqchip/gic-v4.1: Plumb mask/unmask SGI callbacks irqchip/gic-v4.1: Add initial SGI configuration irqchip/gic-v4.1: Plumb skeletal VSGI irqchip irqchip/stm32: Retrigger both in eoi and unmask callbacks irqchip/gic-v3: Move irq_domain_update_bus_token to after checking for NULL domain irqchip/xilinx: Do not call irq_set_default_host() irqchip/xilinx: Enable generic irq multi handler irqchip/xilinx: Fill error code when irq domain registration fails irqchip/xilinx: Add support for multiple instances ...
2020-03-30Merge tag 'v5.6' into mips-nextThomas Bogendoerfer1-1/+29
Linux 5.6
2020-03-25irqchip: Add driver for Loongson-3 HyperTransport PIC controllerJiaxun Yang3-0/+160
This controller appeared on Loongson-3 family of chips to receive interrupts from PCH PIC. It is a I8259 with optimized interrupt polling flow. We can poll interrupt number from HT vector directly but still have to follow standard I8259 routines to mask, unmask and EOI. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Co-developed-by: Huacai Chen <chenhc@lemote.com> Signed-off-by: Huacai Chen <chenhc@lemote.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-03-25irqchip: loongson-liointc: Workaround LPC IRQ ErrataJiaxun Yang1-2/+12
The 1.0 version of that controller has a bug that status bit of LPC IRQ sometimes doesn't get set correctly. So we can always blame LPC IRQ when spurious interrupt happens at the parent interrupt line which LPC IRQ supposed to route to. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Co-developed-by: Huacai Chen <chenhc@lemote.com> Signed-off-by: Huacai Chen <chenhc@lemote.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-03-25irqchip: Add driver for Loongson I/O Local Interrupt ControllerJiaxun Yang3-0/+271
This controller appeared on Loongson family of chips as the primary package interrupt source. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Co-developed-by: Huacai Chen <chenhc@lemote.com> Signed-off-by: Huacai Chen <chenhc@lemote.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-03-24Merge branch 'irq/gic-v4.1' into irq/irqchip-nextMarc Zyngier3-31/+538
Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-03-24irqchip/gic-v4.1: Eagerly vmap vPEsMarc Zyngier1-10/+42
Now that we have HW-accelerated SGIs being delivered to VPEs, it becomes required to map the VPEs on all ITSs instead of relying on the lazy approach that we would use when using the ITS-list mechanism. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20200304203330.4967-17-maz@kernel.org
2020-03-24irqchip/gic-v4.1: Add VSGI property setupMarc Zyngier1-0/+13
Add the SGI configuration entry point for KVM to use. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20200304203330.4967-16-maz@kernel.org
2020-03-24irqchip/gic-v4.1: Add VSGI allocation/teardownMarc Zyngier1-1/+67
Allocate per-VPE SGIs when initializing the GIC-specific part of the VPE data structure. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20200304203330.4967-15-maz@kernel.org
2020-03-24irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction layerMarc Zyngier1-4/+41
In order to hide some of the differences between v4.0 and v4.1, move the doorbell management out of the KVM code, and into the GICv4-specific layer. This allows the calling code to ask for the doorbell when blocking, and otherwise to leave the doorbell permanently disabled. This matches the v4.1 code perfectly, and only results in a minor refactoring of the v4.0 code. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20200304203330.4967-14-maz@kernel.org
2020-03-24irqchip/gic-v4.1: Plumb set_vcpu_affinity SGI callbacksMarc Zyngier1-0/+18
Just like for vLPIs, there is some configuration information that cannot be directly communicated through the normal irqchip API, and we have to use our good old friend set_vcpu_affinity as a side-band communication mechanism. This is used to configure group and priority for a given vSGI. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20200304203330.4967-13-maz@kernel.org
2020-03-24irqchip/gic-v4.1: Plumb get/set_irqchip_state SGI callbacksMarc Zyngier1-0/+77
To implement the get/set_irqchip_state callbacks (limited to the PENDING state), we have to use a particular set of hacks: - Reading the pending state is done by using a pair of new redistributor registers (GICR_VSGIR, GICR_VSGIPENDR), which allow the 16 interrupts state to be retrieved. - Setting the pending state is done by generating it as we'd otherwise do for a guest (writing to GITS_SGIR). - Clearing the pending state is done by emitting a VSGI command with the "clear" bit set. This requires some interesting locking though: - When talking to the redistributor, we must make sure that the VPE affinity doesn't change, hence taking the VPE lock. - At the same time, we must ensure that nobody accesses the same redistributor's GICR_VSGIR registers for a different VPE, which would corrupt the reading of the pending bits. We thus take the per-RD spinlock. Much fun. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20200304203330.4967-12-maz@kernel.org
2020-03-24irqchip/gic-v4.1: Plumb mask/unmask SGI callbacksMarc Zyngier1-0/+18
Implement mask/unmask for virtual SGIs by calling into the configuration helper. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20200304203330.4967-11-maz@kernel.org
2020-03-24irqchip/gic-v4.1: Add initial SGI configurationMarc Zyngier1-1/+91
The GICv4.1 ITS has yet another new command (VSGI) which allows a VPE-targeted SGI to be configured (or have its pending state cleared). Add support for this command and plumb it into the activate irqdomain callback so that it is ready to be used. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20200304203330.4967-10-maz@kernel.org
2020-03-24irqchip/gic-v4.1: Plumb skeletal VSGI irqchipMarc Zyngier2-3/+80
Since GICv4.1 has the capability to inject 16 SGIs into each VPE, and that I'm keen not to invent too many specific interfaces to manipulate these interrupts, let's pretend that each of these SGIs is an actual Linux interrupt. For that matter, let's introduce a minimal irqchip and irqdomain setup that will get fleshed up in the following patches. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20200304203330.4967-9-maz@kernel.org
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-02 01:50:42 +0000