- 06 Apr, 2018 5 commits
-
-
Ming Lei authored
Commit 84676c1f ("genirq/affinity: assign vectors to all possible CPUs") tried to spread the interrupts accross all possible CPUs to make sure that in case of phsyical hotplug (e.g. virtualization) the CPUs which get plugged in after the device was initialized are targeted by a hardware queue and the corresponding interrupt. This has a downside in cases where the ACPI tables claim that there are more possible CPUs than present CPUs and the number of interrupts to spread out is smaller than the number of possible CPUs. These bogus ACPI tables are unfortunately not uncommon. In such a case the vector spreading algorithm assigns interrupts to CPUs which can never be utilized and as a consequence these interrupts are unused instead of being mapped to present CPUs. As a result the performance of the device is suboptimal. To fix this spread the interrupt vectors in two stages: 1) Spread as many interrupts as possible among the present CPUs 2) Spread the remaining vectors among non present CPUs On a 8 core system, where CPU 0-3 are present and CPU 4-7 are not present, for a device with 4 queues the resulting interrupt affinity is: 1) Before 84676c1f ("genirq/affinity: assign vectors to all possible CPUs") irq 39, cpu list 0 irq 40, cpu list 1 irq 41, cpu list 2 irq 42, cpu list 3 2) With 84676c1f ("genirq/affinity: assign vectors to all possible CPUs") irq 39, cpu list 0-2 irq 40, cpu list 3-4,6 irq 41, cpu list 5 irq 42, cpu list 7 3) With the refined vector spread applied: irq 39, cpu list 0,4 irq 40, cpu list 1,6 irq 41, cpu list 2,5 irq 42, cpu list 3,7 On a 8 core system, where all CPUs are present the resulting interrupt affinity for the 4 queues is: irq 39, cpu list 0,1 irq 40, cpu list 2,3 irq 41, cpu list 4,5 irq 42, cpu list 6,7 This is independent of the number of CPUs which are online at the point of initialization because in such a system the offline CPUs can be easily onlined afterwards, while in non-present CPUs need to be plugged physically or virtually which requires external interaction. The downside of this approach is that in case of physical hotplug the interrupt vector spreading might be suboptimal when CPUs 4-7 are physically plugged. Suboptimal from a NUMA point of view and due to the single target nature of interrupt affinities the later plugged CPUs might not be targeted by interrupts at all. Though, physical hotplug systems are not the common case while the broken ACPI table disease is wide spread. So it's preferred to have as many interrupts as possible utilized at the point where the device is initialized. Block multi-queue devices like NVME create a hardware queue per possible CPU, so the goal of commit 84676c1f to assign one interrupt vector per possible CPU is still achieved even with physical/virtual hotplug. [ tglx: Changed from online to present CPUs for the first spreading stage, renamed variables for readability sake, added comments and massaged changelog ] Reported-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org Cc: Christoph Hellwig <hch@infradead.org> Link: https://lkml.kernel.org/r/20180308105358.1506-5-ming.lei@redhat.com
-
Ming Lei authored
To support two stage irq vector spreading, it's required to add a starting point to the spreading function. No functional change, just preparatory work for the actual two stage change. [ tglx: Renamed variables, tidied up the code and massaged changelog ] Signed-off-by:
-
Ming Lei authored
No functional change, just prepare for converting to 2-stage irq vector spreading. Signed-off-by:
-
Ming Lei authored
The following patches will introduce two stage irq spreading for improving irq spread on all possible CPUs. No functional change. Signed-off-by:
-
Thomas Gleixner authored
When the allocation of node_to_possible_cpumask fails, then irq_create_affinity_masks() returns with a pointer to the empty affinity masks array, which will cause malfunction. Reorder the allocations so the masks array allocation comes last and every failure path returns NULL. Fixes: 9a0ef98e ("genirq/affinity: Assign vectors to all present CPUs") Signed-off-by:
-
- 04 Apr, 2018 3 commits
-
-
Palmer Dabbelt authored
arm has an optional MULTI_IRQ_HANDLER, which openrisc copied but didn't make optional. The multi irq handler infrastructure has been copied to generic code selectable with a new config symbol. That symbol can be selected by randconfig builds and can cause build breakage. Introduce CONFIG_MULTI_IRQ_HANDLER as an intermediate step which prevents the core config symbol from being selected. The openrisc local config symbol will be removed once openrisc gets converted to the generic code. Signed-off-by:
Palmer Dabbelt <palmer@sifive.com> Signed-off-by:
-
Palmer Dabbelt authored
arm has an optional MULTI_IRQ_HANDLER, which arm64 copied but didn't make optional. The multi irq handler infrastructure has been copied to generic code selectable with a new config symbol. That symbol can be selected by randconfig builds and can cause build breakage. Introduce CONFIG_MULTI_IRQ_HANDLER as an intermediate step which prevents the core config symbol from being selected. The arm64 local config symbol will be removed once arm64 gets converted to the generic code. Signed-off-by:
-
Palmer Dabbelt authored
These config switches enable the same code in the core and the not yet converted architecture code. They can be selected both by randconfig builds and cause linker error because the same symbols are defined twice. Make the new GENERIC_IRQ_MULTI_HANDLER depend on !MULTI_IRQ_HANDLER to prevent that. The dependency will be removed once all architectures are converted over. Signed-off-by:
-
- 29 Mar, 2018 2 commits
-
-
Thomas Gleixner authored
Merge tag 'irqchip-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates for 4.17 from Marc Zyngier: - New Qualcomm PDC irqchip - New Microsemi Ocelot irqchip - Suspend/resume support for some oddball GICv3 irqchip - Better GIC/GICv3 support for kexec - Various cleanups and fixes
-
Aniruddha Banerjee authored
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 <aniruddhab@nvidia.com> [maz: updated changelog] Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
- 28 Mar, 2018 1 commit
-
-
Davidlohr Bueso authored
No changes in semantics -- key init is true; replace static_key_slow_dec with static_branch_disable static_key_true with static_branch_likely The first is because we never actually do any couterpart incs, thus there is really no reference counting semantics going on. Use the more proper static_branch_disable() construct. Also added a '_key' suffix to supports_deactivate, for better self documentation. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Signed-off-by:
Davidlohr Bueso <dbueso@suse.de> Signed-off-by:
-
- 23 Mar, 2018 1 commit
-
-
Shanker Donthineni authored
Booting with GICR_CTLR.EnableLPI=1 is usually a bad idea, and may result in subtle memory corruption. Detecting this is thus pretty important. On detecting that LPIs are still enabled, we taint the kernel (because we're not sure of anything anymore), and try to disable LPIs. This can fail, as implementations are allowed to implement GICR_CTLR.EnableLPI as a one-way enable, meaning the redistributors cannot be reprogrammed with new tables. Should this happen, we fail probing the redistributor and warn the user that things are pretty dire. Signed-off-by:
Shanker Donthineni <shankerd@codeaurora.org> [maz: reworded changelog, minor comment and message changes] Signed-off-by:
-
- 22 Mar, 2018 3 commits
-
-
Alexandre Belloni authored
The Microsemi Ocelot SoC has a pretty simple IRQ controller in its ICPU block. Add a driver for it. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Alexandre Belloni authored
Add the Device Tree binding documentation for the Microsemi Ocelot interrupt controller that is part of the ICPU. It is connected directly to the MIPS core interrupt controller. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Marc Zyngier authored
We would like to reset the Group-0 Active Priority Registers at boot time if they are available to us. They would be available if SCR_EL3.FIQ was not set, but we cannot directly probe this bit, and short of checking, we may end-up trapping to EL3, and the firmware may not be please to get such an exception. Yes, this is dumb. Instead, let's use PMR to find out if its value gets affected by SCR_EL3.FIQ being set. We use the fact that when SCR_EL3.FIQ is set, the LSB of the priority is lost due to the shifting back and forth of the actual priority. If we read back a 0, we know that Group0 is unavailable. In case we read a non-zero value, we can safely reset the AP0Rn register. Signed-off-by:
-
- 20 Mar, 2018 7 commits
-
-
Marc Zyngier authored
Clearing AP0Rn has created a number of regressions, due to systems that have SCR_EL3.FIQ set. Even when addressing some obvious bugs, GIC500 platforms seem to act bizarrely (we are supposed to have 5 bits of priority, but PMR seems to behave as if we had 6...). Drop the AP0Rn reset for the time being, it is unlikely to have any effect if kexec-ing. Fixes: d6062a6d irqchip/gic-v3: Reset APgRn registers at boot time Reported-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
-
Marc Zyngier authored
We cannot know the trigger of partitionned PPIs ahead of time (when we instanciate the partitions), so let's not check them early. Reported-by:
JeffyChen <jeffy.chen@rock-chips.com> Signed-off-by:
-
Thomas Gleixner authored
Now that SPDX identifiers are in place, remove the boilerplate or references. The change in timings.c has been acked by the author. Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Link: https://lkml.kernel.org/r/20180314212030.668321222@linutronix.de
-
Thomas Gleixner authored
Add SPDX identifiers to files - which contain an explicit license boiler plate or reference - which do not contain a license reference and were not updated in the initial SPDX conversion because the license was deduced by the scanners via EXPORT_SYMBOL_GPL as GPL2.0 only. [ tglx: Moved adding identifiers from the patch which removes the references/boilerplate ] Signed-off-by:
-
Thomas Gleixner authored
Use the proper SPDX-Identifier format. Signed-off-by:
-
Thomas Gleixner authored
Remove pointless references to the file name itself and condense the information so it wastes less space. Signed-off-by:
-
Uwe Kleine König authored
Given that irq_to_desc() is a radix_tree_lookup and the reverse operation is only a pointer dereference and that all callers of __free_irq already have the desc, pass the desc instead of the irq number. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
- 16 Mar, 2018 2 commits
-
-
Marc Zyngier authored
There is a huge number of broken device trees out there. Just grepping through the tree for the use of IRQ_TYPE_NONE in conjunction with the GIC is scary. People just don't realise that IRQ_TYPE_NONE just doesn't exist, and you just get whatever junk was there before. So let's make them aware of the issue. Signed-off-by: -
Marc Zyngier authored
There is a huge number of broken device trees out there. Just grepping through the tree for the use of IRQ_TYPE_NONE in conjunction with the GIC is scary. People just don't realise that IRQ_TYPE_NONE just doesn't exist, and you just get whatever junk was there before. So let's make them aware of the issue. Signed-off-by:
-
- 14 Mar, 2018 12 commits
-
-
Palmer Dabbelt authored
The existing mechanism for handling IRQs on RISC-V is pretty ugly: the irq entry code selects the handler via Kconfig dependencies. Use the new generic IRQ handling infastructure, which allows boot time registration of the low level entry handler. This does add an additional load to the interrupt latency, but there's a lot of tuning left to be done there on RISC-V so it's OK for now. Signed-off-by:
Stafford Horne <shorne@gmail.com> Cc: jonas@southpole.se Cc: catalin.marinas@arm.com Cc: Will Deacon <will.deacon@arm.com> Cc: linux@armlinux.org.uk Cc: stefan.kristiansson@saunalahti.fi Cc: openrisc@lists.librecores.org Cc: linux-riscv@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Link: https://lkml.kernel.org/r/20180307235731.22627-3-palmer@sifive.com
-
Palmer Dabbelt authored
The arm multi irq handler registration mechanism has been copied into a handful of architectures, including arm64 and openrisc. RISC-V needs the same mechanism. Instead of adding yet another copy for RISC-V copy the arm implementation into the core code depending on a new Kconfig symbol: CONFIG_GENERIC_MULTI_IRQ_HANDLER. Subsequent patches will convert the various architectures. Signed-off-by:
-
Thomas Gleixner authored
-
Derek Basehore authored
This adds functionality to resend the MAPC command to an ITS node on resume. If the ITS is powered down during suspend and the collections are not backed by memory, the ITS will lose that state. This just sets up the known state for the collections after the ITS is restored. Signed-off-by:
Derek Basehore <dbasehore@chromium.org> Reviewed-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Derek Basehore authored
Some platforms power off GIC logic in suspend, so we need to save/restore state. The distributor and redistributor registers need to be handled in firmware code due to access permissions on those registers, but the ITS registers can be restored in the kernel. We limit this to systems where the ITS collections are implemented in HW (as opposed to being backed by memory tables), as they are the only ones that cannot be dealt with by the firmware. Signed-off-by:
-
Marc Zyngier authored
For most GICv3 implementations, enabling LPIs is a one way switch. Once they're on, there is no turning back, which completely kills kexec (pending tables will always be live, and we can't tell the secondary kernel where they are). This is really annoying if you plan to use Linux as a bootloader, as it pretty much guarantees that the secondary kernel won't be able to use MSIs, and may even see some memory corruption. Bad. A workaround for this unfortunate situation is to allow the kernel not to enable LPIs, even if the feature is present in the HW. This would allow Linux-as-a-bootloader to leave LPIs alone, and let the secondary kernel to do whatever it wants with them. Let's introduce a boolean "irqchip.gicv3_nolpi" command line option that serves that purpose. Signed-off-by: -
Marc Zyngier authored
Booting a crash kernel while in an interrupt handler is likely to leave the Active Priority Registers with some state that is not relevant to the new kernel, and is likely to lead to erratic behaviours such as interrupts not firing as their priority is already active. As a sanity measure, wipe the APRs clean on startup. We make sure to wipe both group 0 and 1 registers in order to avoid any surprise. Signed-off-by: -
Marc Zyngier authored
Booting a crash kernel while in an interrupt handler is likely to leave the Active Priority Registers with some state that is not relevant to the new kernel, and is likely to lead to erratic behaviours such as interrupts not firing as their priority is already active. As a sanity measure, wipe the APRs clean on startup. Signed-off-by: -
Archana Sathyakumar authored
Add device binding documentation for the PDC Interrupt controller on QCOM SoC's like the SDM845. The interrupt-controller can be used to sense edge low interrupts and wakeup interrupts when the GIC is non-operational. Cc: devicetree@vger.kernel.org Signed-off-by:
Archana Sathyakumar <asathyak@codeaurora.org> Signed-off-by:
Lina Iyer <ilina@codeaurora.org> Reviewed-by:
-
Archana Sathyakumar authored
The Power Domain Controller (PDC) on QTI SoCs like SDM845 houses an interrupt controller along with other domain control functions to handle interrupt related functions like handle falling edge or active low which are not detected at the GIC and handle wakeup interrupts. The interrupt controller is on an always-on domain for the purpose of waking up the processor. Only a subset of the processor's interrupts are routed through the PDC to the GIC. The PDC powers on the processors' domain, when in low power mode and replays pending interrupts so the GIC may wake up the processor. Signed-off-by:
-
Geert Uytterhoeven authored
Since commit 6f46aedb ("irqchip: renesas-irqc: Add wake-up support"), when an IRQ is used for wakeup, the INTC block's module clock is manually kept running during system suspend, to make sure the device stays active. However, this explicit clock handling is merely a workaround for a failure to properly communicate wakeup information to the device core. Instead, set the device's power.wakeup_path field, to indicate this device is part of the wakeup path. Depending on the PM Domain's active_wakeup configuration, the genpd core code will keep the device enabled (and the clock running) during system suspend when needed. This allows for the removal of all explicit clock handling code from the driver. Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Geert Uytterhoeven authored
Since commit 705bc96c ("irqchip: renesas-intc-irqpin: Add minimal runtime PM support"), when an IRQ is used for wakeup, the INTC block's module clock (if exists) is manually kept running during system suspend, to make sure the device stays active. However, this explicit clock handling is merely a workaround for a failure to properly communicate wakeup information to the device core. Instead, set the device's power.wakeup_path field, to indicate this device is part of the wakeup path. Depending on the PM Domain's active_wakeup configuration, the genpd core code will keep the device enabled (and the clock running) during system suspend when needed. This allows for the removal of all explicit clock handling code from the driver. Reviewed-by:
-
- 12 Mar, 2018 2 commits
-
-
git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds authored
Pull NFS client bugfixes from Trond Myklebust: "Hightlights include the following stable fixes: - NFS: Fix an incorrect type in struct nfs_direct_req - pNFS: Prevent the layout header refcount going to zero in pnfs_roc() - NFS: Fix unstable write completion" * tag 'nfs-for-4.16-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFS: Fix unstable write completion pNFS: Prevent the layout header refcount going to zero in pnfs_roc() NFS: Fix an incorrect type in struct nfs_direct_req -
Linus Torvalds authored
-
- 11 Mar, 2018 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86/pti updates from Thomas Gleixner: "Yet another pile of melted spectrum related updates: - Drop native vsyscall support finally as it causes more trouble than benefit. - Make microcode loading more robust. There were a few issues especially related to late loading which are now surfacing because late loading of the IB* microcodes addressing spectre issues has become more widely used. - Simplify and robustify the syscall handling in the entry code - Prevent kprobes on the entry trampoline code which lead to kernel crashes when the probe hits before CR3 is updated - Don't check microcode versions when running on hypervisors as they are considered as lying anyway. - Fix the 32bit objtool build and a coment typo" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/kprobes: Fix kernel crash when probing .entry_trampoline code x86/pti: Fix a comment typo x86/microcode: Synchronize late microcode loading x86/microcode: Request microcode on the BSP x86/microcode/intel: Look into the patch cache first x86/microcode: Do not upload microcode if CPUs are offline x86/microcode/intel: Writeback and invalidate caches before updating microcode x86/microcode/intel: Check microcode revision before updating sibling threads x86/microcode: Get rid of struct apply_microcode_ctx x86/spectre_v2: Don't check microcode versions when running under hypervisors x86/vsyscall/64: Drop "native" vsyscalls x86/entry/64/compat: Save one instruction in entry_INT80_compat() x86/entry: Do not special-case clone(2) in compat entry x86/syscalls: Use COMPAT_SYSCALL_DEFINEx() macros for x86-only compat syscalls x86/syscalls: Use proper syscall definition for sys_ioperm() x86/entry: Remove stale syscall prototype x86/syscalls/32: Simplify $entry == $compat entries objtool: Fix 32-bit build -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Thomas Gleixner: "Just a single fix which adds a missing Kconfig dependency to avoid unmet dependency warnings" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clocksource/atmel-st: Add 'depends on HAS_IOMEM' to fix unmet dependency
-
