#
15137825 |
|
27-Jan-2024 |
Thomas Gleixner <tglx@linutronix.de> |
irqchip/gic-v3: Make gic_irq_domain_select() robust for zero parameter count Currently the irqdomain select callback is only invoked when the parameter count of the fwspec arguments is not zero. That makes sense because then the match is on the firmware node and eventually on the bus_token, which is already handled in the core code. The upcoming support for per device MSI domains requires to do real bus token specific checks in the MSI parent domains with a zero parameter count. Make the gic-v3 select() callback handle that case. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240127161753.114685-2-apatel@ventanamicro.com
|
#
d22083a5 |
|
22-Jan-2024 |
Dawei Li <dawei.li@shingroup.cn> |
irqchip/gic(v3): Replace gic_irq() with irqd_to_hwirq() GIC & GIC-v3 share same gic_irq() implementations, both of which serve exact same purpose as irqd_to_hwirq(). irqd_to_hwirq() is a generic and top level API of the interrupt subsystem, it's independent of any chip implementation. Replace gic_irq() with irqd_to_hwirq() and convert struct irq_data::hwirq to irq_hw_number_t explicitly. Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Dawei Li <dawei.li@shingroup.cn> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240122085716.2999875-3-dawei.li@shingroup.cn
|
#
a0c446dc |
|
22-Jan-2024 |
Dawei Li <dawei.li@shingroup.cn> |
irqchip/gic-v3: Use readl_relaxed_poll_timeout_atomic() Replace the open coded register polling loop with readl_relaxed_poll_timeout_atomic() which provides the same functionality. Signed-off-by: Dawei Li <dawei.li@shingroup.cn> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240122085716.2999875-2-dawei.li@shingroup.cn
|
#
4bb49009 |
|
07-Nov-2023 |
Douglas Anderson <dianders@chromium.org> |
Revert "arm64: smp: avoid NMI IPIs with broken MediaTek FW" This reverts commit a07a594152173a3dd3bdd12fc7d73dbba54cdbca. This is no longer needed after the patch ("arm64: Move MediaTek GIC quirk handling from irqchip to core). Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231107072651.v2.2.I2c5fa192e767eb3ee233bc28eb60e2f8656c29a6@changeid Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
1d816ba1 |
|
07-Nov-2023 |
Douglas Anderson <dianders@chromium.org> |
arm64: Move MediaTek GIC quirk handling from irqchip to core In commit 44bd78dd2b88 ("irqchip/gic-v3: Disable pseudo NMIs on MediaTek devices w/ firmware issues") we added a method for detecting MediaTek devices with broken firmware and disabled pseudo-NMI. While that worked, it didn't address the problem at a deep enough level. The fundamental issue with this broken firmware is that it's not saving and restoring several important GICR registers. The current list is believed to be: * GICR_NUM_IPRIORITYR * GICR_CTLR * GICR_ISPENDR0 * GICR_ISACTIVER0 * GICR_NSACR Pseudo-NMI didn't work because it was the only thing (currently) in the kernel that relied on the broken registers, so forcing pseudo-NMI off was an effective fix. However, it could be observed that calling system_uses_irq_prio_masking() on these systems still returned "true". That caused confusion and led to the need for commit a07a59415217 ("arm64: smp: avoid NMI IPIs with broken MediaTek FW"). It's worried that the incorrect value returned by system_uses_irq_prio_masking() on these systems will continue to confuse future developers. Let's fix the issue a little more completely by disabling IRQ priorities at a deeper level in the kernel. Once we do this we can revert some of the other bits of code dealing with this quirk. This includes a partial revert of commit 44bd78dd2b88 ("irqchip/gic-v3: Disable pseudo NMIs on MediaTek devices w/ firmware issues"). This isn't a full revert because it leaves some of the changes to the "quirks" structure around in case future code needs it. Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20231107072651.v2.1.Ide945748593cffd8ff0feb9ae22b795935b944d6@changeid Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
c54e52f8 |
|
23-Oct-2023 |
James Morse <james.morse@arm.com> |
arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helper ACPI, irqchip and the architecture code all inspect the MADT enabled bit for a GICC entry in the MADT. The addition of an 'online capable' bit means all these sites need updating. Move the current checks behind a helper to make future updates easier. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Acked-by: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/E1quv5D-00AeNJ-U8@rmk-PC.armlinux.org.uk Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
a98a5eac |
|
16-Oct-2023 |
Mark Rutland <mark.rutland@arm.com> |
arm64: Avoid cpus_have_const_cap() for ARM64_WORKAROUND_CAVIUM_23154 In gic_read_iar() we use cpus_have_const_cap() to check for ARM64_WORKAROUND_CAVIUM_23154 but this is not necessary and alternative_has_cap_*() would be preferable. For historical reasons, cpus_have_const_cap() is more complicated than it needs to be. Before cpucaps are finalized, it will perform a bitmap test of the system_cpucaps bitmap, and once cpucaps are finalized it will use an alternative branch. This used to be necessary to handle some race conditions in the window between cpucap detection and the subsequent patching of alternatives and static branches, where different branches could be out-of-sync with one another (or w.r.t. alternative sequences). Now that we use alternative branches instead of static branches, these are all patched atomically w.r.t. one another, and there are only a handful of cases that need special care in the window between cpucap detection and alternative patching. Due to the above, it would be nice to remove cpus_have_const_cap(), and migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(), or cpus_have_cap() depending on when their requirements. This will remove redundant instructions and improve code generation, and will make it easier to determine how each callsite will behave before, during, and after alternative patching. The ARM64_WORKAROUND_CAVIUM_23154 cpucap is detected and patched early on the boot CPU before the GICv3 driver is initialized and hence before gic_read_iar() is ever called. Thus it is not necessary to use cpus_have_const_cap(), and alternative_has_cap() is equivalent. In addition, arm64's gic_read_iar() lives in irq-gic-v3.c purely for historical reasons. It was originally added prior to 32-bit arm support in commit: 6d4e11c5e2e8cd54 ("irqchip/gicv3: Workaround for Cavium ThunderX erratum 23154") When support for 32-bit arm was added, 32-bit arm's gic_read_iar() implementation was placed in <asm/arch_gicv3.h>, but the arm64 version was kept within irq-gic-v3.c as it depended on a static key local to irq-gic-v3.c and it was easier to add ifdeffery, which is what we did in commit: 7936e914f7b0827c ("irqchip/gic-v3: Refactor the arm64 specific parts") Subsequently the static key was replaced with a cpucap in commit: a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant capabilities") Since that commit there has been no need to keep arm64's gic_read_iar() in irq-gic-v3.c. This patch replaces the use of cpus_have_const_cap() with alternative_has_cap_unlikely(), which will avoid generating code to test the system_cpucaps bitmap and should be better for all subsequent calls at runtime. For consistency, move the arm64-specific gic_read_iar() implementation over to arm64's <asm/arch_gicv3.h>. The ARM64_WORKAROUND_CAVIUM_23154 cpucap is added to cpucap_is_possible() so that code can be elided entirely when this is not possible. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
a07a5941 |
|
02-Oct-2023 |
Mark Rutland <mark.rutland@arm.com> |
arm64: smp: avoid NMI IPIs with broken MediaTek FW Some MediaTek devices have broken firmware which corrupts some GICR registers behind the back of the OS, and pseudo-NMIs cannot be used on these devices. For more details see commit: 44bd78dd2b8897f5 ("irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues") We did not take this problem into account in commit: 331a1b3a836c0f38 ("arm64: smp: Add arch support for backtrace using pseudo-NMI") Since that commit arm64's SMP code will try to setup some IPIs as pseudo-NMIs, even on systems with broken FW. The GICv3 code will (rightly) reject attempts to request interrupts as pseudo-NMIs, resulting in boot-time failures. Avoid the problem by taking the broken FW into account when deciding to request IPIs as pseudo-NMIs. The GICv3 driver maintains a static_key named "supports_pseudo_nmis" which is false on systems with broken FW, and we can consult this within ipi_should_be_nmi(). Fixes: 331a1b3a836c ("arm64: smp: Add arch support for backtrace using pseudo-NMI") Reported-by: Chen-Yu Tsai <wenst@chromium.org> Closes: https://issuetracker.google.com/issues/197061987#comment68 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
a02026bf |
|
06-Sep-2023 |
Douglas Anderson <dianders@chromium.org> |
irqchip/gic-v3: Enable support for SGIs to act as NMIs As of commit 6abbd6988971 ("irqchip/gic, gic-v3: Make SGIs use handle_percpu_devid_irq()") SGIs are treated the same as PPIs/EPPIs and use handle_percpu_devid_irq() by default. Unfortunately, handle_percpu_devid_irq() isn't NMI safe, and so to run in an NMI context those should use handle_percpu_devid_fasteoi_nmi(). In order to accomplish this, we just have to make room for SGIs in the array of refcounts that keeps track of which interrupts are set as NMI. We also rename the array and create a new indexing scheme that accounts for SGIs. Also, enable NMI support prior to gic_smp_init() as allocation of SGIs as IRQs/NMIs happen as part of this routine. Co-developed-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230906090246.v13.1.I1223c11c88937bd0cbd9b086d4ef216985797302@changeid Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
3a0fff0f |
|
06-Oct-2023 |
Lorenzo Pieralisi <lpieralisi@kernel.org> |
irqchip/gic-v3: Enable non-coherent redistributors/ITSes DT probing The GIC architecture specification defines a set of registers for redistributors and ITSes that control the sharebility and cacheability attributes of redistributors/ITSes initiator ports on the interconnect (GICR_[V]PROPBASER, GICR_[V]PENDBASER, GITS_BASER<n>). Architecturally the GIC provides a means to drive shareability and cacheability attributes signals and related IWB/OWB/ISH barriers but it is not mandatory for designs to wire up the corresponding interconnect signals that control the cacheability/shareability of transactions. Redistributors and ITSes interconnect ports can be connected to non-coherent interconnects that are not able to manage the shareability/cacheability attributes; this implicitly makes the redistributors and ITSes non-coherent observers. So far, the GIC driver on probe executes a write to "probe" for the redistributors and ITSes registers shareability bitfields by writing a value (ie InnerShareable - the shareability domain the CPUs are in) and check it back to detect whether the value sticks or not; this hinges on a GIC programming model behaviour that predates the current specifications, that just define shareability bits as writeable but do not guarantee that writing certain shareability values enable the expected behaviour for the redistributors/ITSes memory interconnect ports. To enable non-coherent GIC designs, introduce the "dma-noncoherent" device tree property to allow firmware to describe redistributors and ITSes as non-coherent observers on the memory interconnect and use the property to force the shareability attributes to be programmed into the redistributors and ITSes registers through the GIC quirks mechanism. Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20231006125929.48591-3-lpieralisi@kernel.org
|
#
6fe5c68e |
|
04-Jul-2023 |
Lorenzo Pieralisi <lpieralisi@kernel.org> |
irqchip/gic-v3: Workaround for GIC-700 erratum 2941627 GIC700 erratum 2941627 may cause GIC-700 missing SPIs wake requests when SPIs are deactivated while targeting a sleeping CPU - ie a CPU for which the redistributor: GICR_WAKER.ProcessorSleep == 1 This runtime situation can happen if an SPI that has been activated on a core is retargeted to a different core, it becomes pending and the target core subsequently enters a power state quiescing the respective redistributor. When this situation is hit, the de-activation carried out on the core that activated the SPI (through either ICC_EOIR1_EL1 or ICC_DIR_EL1 register writes) does not trigger a wake requests for the sleeping GIC redistributor even if the SPI is pending. Work around the erratum by de-activating the SPI using the redistributor GICD_ICACTIVER register if the runtime conditions require it (ie the IRQ was retargeted between activation and de-activation). Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230704155034.148262-1-lpieralisi@kernel.org
|
#
b4d81fab |
|
22-May-2023 |
zhengyan <zhengyan@asrmicro.com> |
irqchip/gic-v3: Work around affinity issues on ASR8601 The ASR8601 SoC combines ARMv8.2 CPUs from ARM with a GIC-500, also from ARM. However, the two are incompatible as the former expose an affinity in the form of (cluster, core, thread), while the latter can only deal with (cluster, core). If nothing is done, the GIC simply cannot route interrupts to the CPUs. Implement a workaround that shifts the affinity down by a level, ensuring the delivery of interrupts despite the implementation mismatch. Signed-off-by: zhengyan <zhengyan@asrmicro.com> [maz: rewrote commit message, reimplemented the workaround in a manageable way] Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
3c65cbb7 |
|
29-May-2023 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Improve affinity helper The GICv3 driver uses multiple formats for the affinity, all derived from a reading of MPDR_EL1 on one CPU or another. Simplify the handling of these affinity by moving the access to the CPU affinity via cpu_logical_map() inside the helper, and rename it accordingly. This will be helpful to support some more broken hardware. Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
44bd78dd |
|
15-May-2023 |
Douglas Anderson <dianders@chromium.org> |
irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues Some Chromebooks with Mediatek SoCs have a problem where the firmware doesn't properly save/restore certain GICR registers. Newer Chromebooks should fix this issue and we may be able to do firmware updates for old Chromebooks. At the moment, the only known issue with these Chromebooks is that we can't enable "pseudo NMIs" since the priority register can be lost. Enabling "pseudo NMIs" on Chromebooks with the problematic firmware causes crashes and freezes. Let's detect devices with this problem and then disable "pseudo NMIs" on them. We'll detect the problem by looking for the presence of the "mediatek,broken-save-restore-fw" property in the GIC device tree node. Any devices with fixed firmware will not have this property. Our detection plan works because we never bake a Chromebook's device tree into firmware. Instead, device trees are always bundled with the kernel. We'll update the device trees of all affected Chromebooks and then we'll never enable "pseudo NMI" on a kernel that is bundled with old device trees. When a firmware update is shipped that fixes this issue it will know to patch the device tree to remove the property. In order to make this work, the quick detection mechanism of the GICv3 code is extended to be able to look for properties in addition to looking at "compatible". Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230515131353.v2.2.I88dc0a0eb1d9d537de61604cd8994ecc55c0cac1@changeid
|
#
35727af2 |
|
18-Mar-2023 |
Shanker Donthineni <sdonthineni@nvidia.com> |
irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4 The T241 platform suffers from the T241-FABRIC-4 erratum which causes unexpected behavior in the GIC when multiple transactions are received simultaneously from different sources. This hardware issue impacts NVIDIA server platforms that use more than two T241 chips interconnected. Each chip has support for 320 {E}SPIs. This issue occurs when multiple packets from different GICs are incorrectly interleaved at the target chip. The erratum text below specifies exactly what can cause multiple transfer packets susceptible to interleaving and GIC state corruption. GIC state corruption can lead to a range of problems, including kernel panics, and unexpected behavior. >From the erratum text: "In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving. The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: - Register reads from GICD_I* and GICD_N* - Register writes to 64-bit GICD registers other than GICD_IROUTERn* - ITS command MOVALL Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses." This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4." Link: https://developer.nvidia.com/docs/t241-fabric-4/nvidia-t241-fabric-4-errata.pdf Writing to the chip alias region of the GICD_In{E} registers except GICD_ICENABLERn has an equivalent effect as writing to the global distributor. The SPI interrupt deactivate path is not impacted by the erratum. To fix this problem, implement a workaround that ensures read accesses to the GICD_In{E} registers are directed to the chip that owns the SPI, and disable GICv4.x features. To simplify code changes, the gic_configure_irq() function uses the same alias region for both read and write operations to GICD_ICFGR. Co-developed-by: Vikram Sethi <vsethi@nvidia.com> Signed-off-by: Vikram Sethi <vsethi@nvidia.com> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> (for SMCCC/SOC ID bits) Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230319024314.3540573-2-sdonthineni@nvidia.com
|
#
8bf0a804 |
|
30-Jan-2023 |
Mark Rutland <mark.rutland@arm.com> |
arm64: add ARM64_HAS_GIC_PRIO_RELAXED_SYNC cpucap When Priority Mask Hint Enable (PMHE) == 0b1, the GIC may use the PMR value to determine whether to signal an IRQ to a PE, and consequently after a change to the PMR value, a DSB SY may be required to ensure that interrupts are signalled to a CPU in finite time. When PMHE == 0b0, interrupts are always signalled to the relevant PE, and all masking occurs locally, without requiring a DSB SY. Since commit: f226650494c6aa87 ("arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear") ... we handle this dynamically: in most cases a static key is used to determine whether to issue a DSB SY, but the entry code must read from ICC_CTLR_EL1 as static keys aren't accessible from plain assembly. It would be much nicer to use an alternative instruction sequence for the DSB, as this would avoid the need to read from ICC_CTLR_EL1 in the entry code, and for most other code this will result in simpler code generation with fewer instructions and fewer branches. This patch adds a new ARM64_HAS_GIC_PRIO_RELAXED_SYNC cpucap which is only set when ICC_CTLR_EL1.PMHE == 0b0 (and GIC priority masking is in use). This allows us to replace the existing users of the `gic_pmr_sync` static key with alternative sequences which default to a DSB SY and are relaxed to a NOP when PMHE is not in use. The entry assembly management of the PMR is slightly restructured to use a branch (rather than multiple NOPs) when priority masking is not in use. This is more in keeping with other alternatives in the entry assembly, and permits the use of a separate alternatives for the PMHE-dependent DSB SY (and removal of the conditional branch this currently requires). For consistency I've adjusted both the save and restore paths. According to bloat-o-meter, when building defconfig + CONFIG_ARM64_PSEUDO_NMI=y this shrinks the kernel text by ~4KiB: | add/remove: 4/2 grow/shrink: 42/310 up/down: 332/-5032 (-4700) The resulting vmlinux is ~66KiB smaller, though the resulting Image size is unchanged due to padding and alignment: | [mark@lakrids:~/src/linux]% ls -al vmlinux-* | -rwxr-xr-x 1 mark mark 137508344 Jan 17 14:11 vmlinux-after | -rwxr-xr-x 1 mark mark 137575440 Jan 17 13:49 vmlinux-before | [mark@lakrids:~/src/linux]% ls -al Image-* | -rw-r--r-- 1 mark mark 38777344 Jan 17 14:11 Image-after | -rw-r--r-- 1 mark mark 38777344 Jan 17 13:49 Image-before Prior to this patch we did not verify the state of ICC_CTLR_EL1.PMHE on secondary CPUs. As of this patch this is verified by the cpufeature code when using GIC priority masking (i.e. when using pseudo-NMIs). Note that since commit: 7e3a57fa6ca831fa ("arm64: Document ICC_CTLR_EL3.PMHE setting requirements") ... Documentation/arm64/booting.rst specifies: | - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across | all CPUs the kernel is executing on, and must stay constant | for the lifetime of the kernel. ... so that should not adversely affect any compliant systems, and as we'll only check for the absense of PMHE when using pseudo-NMIs, this will only fire when such mismatch will adversely affect the system. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20230130145429.903791-5-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
0e2213fe |
|
13-Dec-2022 |
Johan Hovold <johan+linaro@kernel.org> |
irqchip: Use irq_domain_alloc_irqs() Use the irq_domain_alloc_irqs() wrapper instead of the full __irq_domain_alloc_irqs() interface, which was only intended for some legacy (x86) use cases. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20221213140844.15470-2-johan+linaro@kernel.org
|
#
5e279739 |
|
01-Nov-2022 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
irqchip/gic: Use kstrtobool() instead of strtobool() strtobool() is the same as kstrtobool(). However, the latter is more used within the kernel. In order to remove strtobool() and slightly simplify kstrtox.h, switch to the other function name. While at it, include the corresponding header file (<linux/kstrtox.h>) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/755c4083122071bb27aa8ed5d98156a07bb63a39.1667336095.git.christophe.jaillet@wanadoo.fr
|
#
4d968297 |
|
27-Sep-2022 |
Zhiyuan Dai <daizhiyuan@phytium.com.cn> |
irqchip/gic-v3: Fix typo in comment Fix typo in comment (cleanip/cleanup). Signed-off-by: Zhiyuan Dai <daizhiyuan@phytium.com.cn> [maz: commit message] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1664332767-6909-1-git-send-email-daizhiyuan@phytium.com.cn
|
#
7327b16f |
|
20-Jul-2022 |
Marc Zyngier <maz@kernel.org> |
APCI: irq: Add support for multiple GSI domains In an unfortunate departure from the ACPI spec, the LoongArch architecture split its GSI space across multiple interrupt controllers. In order to be able to reuse the core code and prevent architectures from reinventing an already square wheel, offer the arch code the ability to register a dispatcher function that will return the domain fwnode for a given GSI. The ARM GIC drivers are updated to support this (with a single domain, as intended). Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Tested-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/1658314292-35346-3-git-send-email-lvjianmin@loongson.cn
|
#
29517170 |
|
14-Jul-2022 |
Jason Wang <wangborong@cdjrlc.com> |
irqchip/gic-v3: Fix comment typo The double `the' is duplicated in line 1786, remove one. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220715051258.28889-1-wangborong@cdjrlc.com
|
#
4deb96e3 |
|
16-Jun-2022 |
Robin Murphy <robin.murphy@arm.com> |
irqchip/gicv3: Handle resource request failure consistently Due to a silly oversight on my part, making the simple switch to of_io_request_and_map() in the DT path inadvertently introduced divergent behaviour, whereby failng to request an iomem region now becomes fatal for DT, vs. being silently ignored for ACPI. Refactor a bit harder, so that request errors are non-fatal in both paths as intended, but also consistently reported as well. Reported-by: Matt Ranostay <mranostay@ti.com> Fixes: 2b2cd74a06c3 ("irqchip/gic-v3: Claim iomem resources") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/5f2b57a0131f3082fae9d3002d360bf784ccb092.1655387206.git.robin.murphy@arm.com
|
#
fa1ad9d4 |
|
31-May-2022 |
Miaoqian Lin <linmq006@gmail.com> |
irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: e3825ba1af3a ("irqchip/gic-v3: Add support for partitioned PPIs") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220601080930.31005-6-linmq006@gmail.com
|
#
ec8401a4 |
|
31-May-2022 |
Miaoqian Lin <linmq006@gmail.com> |
irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. When kcalloc fails, it missing of_node_put() and results in refcount leak. Fix this by goto out_put_node label. Fixes: 52085d3f2028 ("irqchip/gic-v3: Dynamically allocate PPI partition descriptors") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220601080930.31005-5-linmq006@gmail.com
|
#
614ab80c |
|
13-May-2022 |
Mark Rutland <mark.rutland@arm.com> |
irqchip/gic-v3: Fix priority mask handling When a kernel is built with CONFIG_ARM64_PSEUDO_NMI=y and pseudo-NMIs are enabled at runtime, GICv3's gic_handle_irq() can leave DAIF and ICC_PMR_EL1 in an unexpected state in some cases, breaking subsequent usage of local_irq_enable() and resulting in softirqs being run with IRQs erroneously masked (possibly resulting in deadlocks). This can happen when an IRQ exception is taken from a context where regular IRQs were unmasked, and either: (1) ICC_IAR1_EL1 indicates a special INTID (e.g. as a result of an IRQ being withdrawn since the IRQ exception was taken). (2) ICC_IAR1_EL1 and ICC_RPR_EL1 indicate an NMI was acknowledged. When an NMI is taken from a context where regular IRQs were masked, there is no problem. When CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y, this can be detected with perf, e.g. | # ./perf record -a -g -e cycles:k ls -alR / > /dev/null 2>&1 | ------------[ cut here ]------------ | WARNING: CPU: 0 PID: 14 at arch/arm64/include/asm/irqflags.h:32 arch_local_irq_enable+0x4c/0x6c | Modules linked in: | CPU: 0 PID: 14 Comm: ksoftirqd/0 Not tainted 5.18.0-rc5-00004-g876c38e3d20b #12 | Hardware name: linux,dummy-virt (DT) | pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arch_local_irq_enable+0x4c/0x6c | lr : __do_softirq+0x110/0x5d8 | sp : ffff8000080bbbc0 | pmr_save: 000000f0 | x29: ffff8000080bbbc0 x28: ffff316ac3a6ca40 x27: 0000000000000000 | x26: 0000000000000000 x25: ffffa04611c06008 x24: ffffa04611c06008 | x23: 0000000040400005 x22: 0000000000000200 x21: ffff8000080bbe20 | x20: ffffa0460fe10320 x19: 0000000000000009 x18: 0000000000000000 | x17: ffff91252dfa9000 x16: ffff800008004000 x15: 0000000000004000 | x14: 0000000000000028 x13: ffffa0460fe17578 x12: ffffa0460fed4294 | x11: ffffa0460fedc168 x10: ffffffffffffff80 x9 : ffffa0460fe10a70 | x8 : ffffa0460fedc168 x7 : 000000000000b762 x6 : 00000000057c3bdf | x5 : ffff8000080bbb18 x4 : 0000000000000000 x3 : 0000000000000001 | x2 : ffff91252dfa9000 x1 : 0000000000000060 x0 : 00000000000000f0 | Call trace: | arch_local_irq_enable+0x4c/0x6c | __irq_exit_rcu+0x180/0x1ac | irq_exit_rcu+0x1c/0x44 | el1_interrupt+0x4c/0xe4 | el1h_64_irq_handler+0x18/0x24 | el1h_64_irq+0x74/0x78 | smpboot_thread_fn+0x68/0x2c0 | kthread+0x124/0x130 | ret_from_fork+0x10/0x20 | irq event stamp: 193241 | hardirqs last enabled at (193240): [<ffffa0460fe10a9c>] __do_softirq+0x10c/0x5d8 | hardirqs last disabled at (193241): [<ffffa0461102ffe4>] el1_dbg+0x24/0x90 | softirqs last enabled at (193234): [<ffffa0460fe10e00>] __do_softirq+0x470/0x5d8 | softirqs last disabled at (193239): [<ffffa0460fea9944>] __irq_exit_rcu+0x180/0x1ac | ---[ end trace 0000000000000000 ]--- The necessary manipulation of DAIF and ICC_PMR_EL1 depends on the interrupted context, but the structure of gic_handle_irq() makes this also depend on whether the GIC reports an IRQ, NMI, or special INTID: * When the interrupted context had regular IRQs masked (and hence the interrupt must be an NMI), the entry code performs the NMI entry/exit and gic_handle_irq() should return with DAIF and ICC_PMR_EL1 unchanged. This is handled correctly today. * When the interrupted context had regular IRQs unmasked, the entry code performs IRQ entry/exit, but expects gic_handle_irq() to always update ICC_PMR_EL1 and DAIF.IF to unmask NMIs (but not regular IRQs) prior to returning (which it must do prior to invoking any regular IRQ handler). This unbalanced calling convention is necessary because we don't know whether an NMI has been taken until acknowledged by a read from ICC_IAR1_EL1, and so we need to perform the read with NMI masked in case an NMI has been taken (and needs to be handled with NMIs masked). Unfortunately, this is not handled consistently: - When ICC_IAR1_EL1 reports a special INTID, gic_handle_irq() returns immediately without manipulating ICC_PMR_EL1 and DAIF. - When RPR_EL1 indicates an NMI, gic_handle_irq() calls gic_handle_nmi() to invoke the NMI handler, then returns without manipulating ICC_PMR_EL1 and DAIF. - For regular IRQs, gic_handle_irq() manipulates ICC_PMR_EL1 and DAIF prior to invoking the IRQ handler. There were related problems with special INTID handling in the past, where if an exception was taken from a context with regular IRQs masked and ICC_IAR_EL1 reported a special INTID, gic_handle_irq() would erroneously unmask NMIs in NMI context permitted an unexpected nested NMI. That case specifically was fixed by commit: a97709f563a078e2 ("irqchip/gic-v3: Do not enable irqs when handling spurious interrups") ... but unfortunately that commit added an inverse problem, where if an exception was taken from a context with regular IRQs *unmasked* and ICC_IAR_EL1 reported a special INTID, gic_handle_irq() would erroneously fail to unmask NMIs (and consequently regular IRQs could not be unmasked during softirq processing). Before and after that commit, if an NMI was taken from a context with regular IRQs unmasked gic_handle_irq() would not unmask NMIs prior to returning, leading to the same problem with softirq handling. This patch fixes this by restructuring gic_handle_irq(), splitting it into separate irqson/irqsoff helper functions which consistently perform the DAIF + ICC_PMR1_EL1 manipulation based upon the interrupted context, regardless of the event indicated by ICC_IAR1_EL1. The special INTID handling is moved into the low-level IRQ/NMI handler invocation helper functions, so that early returns don't prevent the required manipulation of DAIF + ICC_PMR_EL1. Fixes: f32c926651dcd168 ("irqchip/gic-v3: Handle pseudo-NMIs") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220513133038.226182-4-mark.rutland@arm.com
|
#
6efb5092 |
|
13-May-2022 |
Mark Rutland <mark.rutland@arm.com> |
irqchip/gic-v3: Refactor ISB + EOIR at ack time There are cases where a context synchronization event is necessary between an IRQ being raised and being handled, and there are races such that we cannot rely upon the exception entry being subsequent to the interrupt being raised. To fix this, we place an ISB between a read of IAR and the subsequent invocation of an IRQ handler. When EOI mode 1 is in use, we need to EOI an interrupt prior to invoking its handler, and we have a write to EOIR for this. As this write to EOIR requires an ISB, and this is provided by the gic_write_eoir() helper, we omit the usual ISB in this case, with the logic being: | if (static_branch_likely(&supports_deactivate_key)) | gic_write_eoir(irqnr); | else | isb(); This is somewhat opaque, and it would be a little clearer if there were an unconditional ISB, with only the write to EOIR being conditional, e.g. | if (static_branch_likely(&supports_deactivate_key)) | write_gicreg(irqnr, ICC_EOIR1_EL1); | | isb(); This patch rewrites the code that way, with this logic factored into a new helper function with comments explaining what the ISB is for, as were originally laid out in commit: 39a06b67c2c1256b ("irqchip/gic: Ensure we have an ISB between ack and ->handle_irq") Note that since then, we removed the IAR polling in commit: 342677d70ab92142 ("irqchip/gic-v3: Remove acknowledge loop") ... which removed one of the two race conditions. For consistency, other portions of the driver are made to manipulate EOIR using write_gicreg() and explcit ISBs, and the gic_write_eoir() helper function is removed. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220513133038.226182-3-mark.rutland@arm.com
|
#
adf14453 |
|
13-May-2022 |
Mark Rutland <mark.rutland@arm.com> |
irqchip/gic-v3: Ensure pseudo-NMIs have an ISB between ack and handling There are cases where a context synchronization event is necessary between an IRQ being raised and being handled, and there are races such that we cannot rely upon the exception entry being subsequent to the interrupt being raised. We identified and fixes this for regular IRQs in commit: 39a06b67c2c1256b ("irqchip/gic: Ensure we have an ISB between ack and ->handle_irq") Unfortunately, we forgot to do the same for psuedo-NMIs when support for those was added in commit: f32c926651dcd168 ("irqchip/gic-v3: Handle pseudo-NMIs") Which means that when pseudo-NMIs are used for PMU support, we'll hit the same problem. Apply the same fix as for regular IRQs. Note that when EOI mode 1 is in use, the call to gic_write_eoir() will provide an ISB. Fixes: f32c926651dcd168 ("irqchip/gic-v3: Handle pseudo-NMIs") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220513133038.226182-2-mark.rutland@arm.com
|
#
2b2cd74a |
|
12-Apr-2022 |
Robin Murphy <robin.murphy@arm.com> |
irqchip/gic-v3: Claim iomem resources As a simple quality-of-life tweak, claim our MMIO regions when mapping them, such that the GIC shows up in /proc/iomem. No effort is spent on trying to release them, since frankly if the GIC fails to probe then it's never getting a second try anyway. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/c534c2a458a3bf94ccdae8abc6edc3d45a689c30.1649777295.git.robin.murphy@arm.com
|
#
63f13483 |
|
05-Apr-2022 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Relax polling of GIC{R,D}_CTLR.RWP Recent work on the KVM GIC emulation has revealed that the GICv3 driver is a bit RWP-happy, as it polls this bit for each and every write MMIO access involving a single interrupt. As it turns out, polling RWP is only required when: - Disabling an SGI, PPI or SPI - Disabling LPIs at the redistributor level - Disabling groups - Enabling ARE - Dealing with DPG* Simplify the driver by removing all the other instances of RWP polling, and add the one that was missing when enabling the distributor (as that's where we set ARE). Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220405183857.205960-4-maz@kernel.org
|
#
a837ed36 |
|
05-Apr-2022 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Detect LPI invalidation MMIO registers Since GICv4.1, an implementation can offer the same MMIO-based implementation as DirectLPI, only with an ITS. Given that this can be hugely beneficial for workloads that are very LPI masking heavy (although these workloads are admitedly a bit odd). Interestingly, this is independent of RVPEI, which only *implies* the functionnality. So let's detect whether the implementation has GICR_CTLR.IR set, and propagate this as DirectLPI to the ITS driver. While we're at it, repaint the GICv3 banner so that we advertise the various capabilities at boot time to be slightly less invasive. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220405183857.205960-3-maz@kernel.org
|
#
544808f7 |
|
03-Apr-2022 |
Andre Przywara <andre.przywara@arm.com> |
irqchip/gic, gic-v3: Prevent GSI to SGI translations At the moment the GIC IRQ domain translation routine happily converts ACPI table GSI numbers below 16 to GIC SGIs (Software Generated Interrupts aka IPIs). On the Devicetree side we explicitly forbid this translation, actually the function will never return HWIRQs below 16 when using a DT based domain translation. We expect SGIs to be handled in the first part of the function, and any further occurrence should be treated as a firmware bug, so add a check and print to report this explicitly and avoid lengthy debug sessions. Fixes: 64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard interrupts") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220404110842.2882446-1-andre.przywara@arm.com
|
#
0df66645 |
|
15-Mar-2022 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing. Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3") Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Link: https://lore.kernel.org/r/20220315165034.794482-2-maz@kernel.org
|
#
80e4e1f4 |
|
19-Feb-2022 |
Barry Song <song.bao.hua@hisilicon.com> |
irqchip/gic-v3: Use dsb(ishst) to order writes with ICC_SGI1R_EL1 accesses A dsb(ishst) barrier should be enough to order previous writes with the system register generating the SGI, as we only need to guarantee the visibility of data to other CPUs in the inner shareable domain before we send the SGI. A micro-benchmark is written to verify the performance impact on kunpeng920 machine with 2 sockets, each socket has 2 dies, and each die has 24 CPUs, so totally the system has 2 * 2 * 24 = 96 CPUs. ~2% performance improvement can be seen by this benchmark. The code of benchmark module: #include <linux/module.h> #include <linux/timekeeping.h> volatile int data0 ____cacheline_aligned; volatile int data1 ____cacheline_aligned; volatile int data2 ____cacheline_aligned; volatile int data3 ____cacheline_aligned; volatile int data4 ____cacheline_aligned; volatile int data5 ____cacheline_aligned; volatile int data6 ____cacheline_aligned; static void ipi_latency_func(void *val) { } static int __init ipi_latency_init(void) { ktime_t stime, etime, delta; int cpu, i; int start = smp_processor_id(); stime = ktime_get(); for ( i = 0; i < 1000; i++) for (cpu = 0; cpu < 96; cpu++) { data0 = data1 = data2 = data3 = data4 = data5 = data6 = cpu; smp_call_function_single(cpu, ipi_latency_func, NULL, 1); } etime = ktime_get(); delta = ktime_sub(etime, stime); printk("%s ipi from cpu%d to cpu0-95 delta of 1000times:%lld\n", __func__, start, delta); return 0; } module_init(ipi_latency_init); static void ipi_latency_exit(void) { } module_exit(ipi_latency_exit); MODULE_DESCRIPTION("IPI benchmark"); MODULE_LICENSE("GPL"); run the below commands 10 times on both Vanilla and the kernel with this patch: # taskset -c 0 insmod test.ko # rmmod test The result on vanilla: ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:126757449 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:126784249 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:126177703 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:127022281 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:126184883 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:127374585 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:125778089 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:126974441 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:127357625 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:126228184 The result on the kernel with this patch: ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:124467401 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:123474209 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:123558497 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:122993951 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:122984223 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:123323609 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:124507583 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:123386963 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:123340664 ipi_latency_init ipi from cpu0 to cpu0-95 delta of 1000times:123285324 Signed-off-by: Barry Song <song.bao.hua@hisilicon.com> [maz: tidied up commit message] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220220061910.6155-1-21cnbao@gmail.com
|
#
79a7f77b |
|
16-Dec-2021 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v4: Disable redistributors' view of the VPE table at boot time Jay Chen reported that using a kdump kernel on a GICv4.1 system results in a RAS error being delivered when the secondary kernel configures the ITS's view of the new VPE table. As it turns out, that's because each RD still has a pointer to the previous instance of the VPE table, and that particular implementation is very upset by seeing two bits of the HW that should point to the same table with different values. To solve this, let's invalidate any reference that any RD has to the VPE table when discovering the RDs. The ITS can then be programmed as expected. Reported-by: Jay Chen <jkchen@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Link: https://lore.kernel.org/r/20211214064716.21407-1-jkchen@linux.alibaba.com Link: https://lore.kernel.org/r/20211216144804.1578566-1-maz@kernel.org
|
#
d23bc2bc |
|
27-Oct-2021 |
Valentin Schneider <valentin.schneider@arm.com> |
irqchip/gic-v3-its: Postpone LPI pending table freeing and memreserve Memory used by the LPI tables have to be made persistent for kexec to have a chance to work, as explained in [1]. If they have been made persistent and we are booting into a kexec'd kernel, we also need to free the pages that were preemptively allocated by the new kernel for those tables. Both of those operations currently happen during its_cpu_init(), which happens in a _STARTING (IOW atomic) cpuhp callback for secondary CPUs. efi_mem_reserve_iomem() issues a GFP_ATOMIC allocation, which unfortunately doesn't work under PREEMPT_RT (this ends up grabbing a non-raw spinlock, which can sleep under PREEMPT_RT). Similarly, freeing the pages ends up grabbing a sleepable spinlock. Since the memreserve is only required by kexec, it doesn't have to be done so early in the secondary boot process. Issue the reservation in a new CPUHP_AP_ONLINE_DYN cpuhp callback, and piggy-back the page freeing on top of it. A CPU gets to run the body of this new callback exactly once. As kexec issues a machine_shutdown() prior to machine_kexec(), it will be serialized vs a CPU being plugged to life by the hotplug machinery - either the CPU will have been brought up and have had its redistributor's pending table memreserved, or it never went online and will have its table allocated by the new kernel. [1]: https://lore.kernel.org/lkml/20180921195954.21574-1-marc.zyngier@arm.com/ Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211027151506.2085066-3-valentin.schneider@arm.com
|
#
0953fb26 |
|
20-Oct-2021 |
Mark Rutland <mark.rutland@arm.com> |
irq: remove handle_domain_{irq,nmi}() Now that entry code handles IRQ entry (including setting the IRQ regs) before calling irqchip code, irqchip code can safely call generic_handle_domain_irq(), and there's no functional reason for it to call handle_domain_irq(). Let's cement this split of responsibility and remove handle_domain_irq() entirely, updating irqchip drivers to call generic_handle_domain_irq(). For consistency, handle_domain_nmi() is similarly removed and replaced with a generic_handle_domain_nmi() function which also does not perform any entry logic. Previously handle_domain_{irq,nmi}() had a WARN_ON() which would fire when they were called in an inappropriate context. So that we can identify similar issues going forward, similar WARN_ON_ONCE() logic is added to the generic_handle_*() functions, and comments are updated for clarity and consistency. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de>
|
#
8d474dea |
|
11-Aug-2021 |
Chen-Yu Tsai <wenst@chromium.org> |
irqchip/gic-v3: Fix priority comparison when non-secure priorities are used When non-secure priorities are used, compared to the raw priority set, the value read back from RPR is also right-shifted by one and the highest bit set. Add a macro to do the modifications to the raw priority when doing the comparison against the RPR value. This corrects the pseudo-NMI behavior when non-secure priorities in the GIC are used. Tested on 5.10 with the "IPI as pseudo-NMI" series [1] applied on MT8195. [1] https://lore.kernel.org/linux-arm-kernel/1604317487-14543-1-git-send-email-sumit.garg@linaro.org/ Fixes: 336780590990 ("irqchip/gic-v3: Support pseudo-NMIs when SCR_EL3.FIQ == 0") Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> [maz: Added comment contributed by Alex] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210811171505.1502090-1-wenst@chromium.org
|
#
d753f849 |
|
29-Jul-2021 |
James Morse <james.morse@arm.com> |
irqchip/gic-v3: Fix selection of partition domain for EPPIs commit 5f51f803826e ("irqchip/gic-v3: Add EPPI range support") added GIC_IRQ_TYPE_PARTITION support for EPPI to gic_irq_domain_translate(), and commit 52085d3f2028 ("irqchip/gic-v3: Dynamically allocate PPI partition descriptors") made the gic_data.ppi_descs array big enough for EPPI, but neither gic_irq_domain_select() nor partition_domain_translate() were updated. This means partitions are created by partition_create_desc() for the EPPI range, but can't be registered as they will always match the root domain and map to the summary interrupt. Update gic_irq_domain_select() to match PPI and EPPI. The fwspec for PPI and EPPI both start from 0. Use gic_irq_domain_translate() to find the hwirq from the fwspec, then convert this to a ppi index. Reported-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210729172748.28841-3-james.morse@arm.com
|
#
bfa80ee9 |
|
29-Jul-2021 |
James Morse <james.morse@arm.com> |
irqchip/gic-v3: Add __gic_get_ppi_index() to find the PPI number from hwirq gic_get_ppi_index() is a useful concept for ppi partitions, as the GIC has two PPI ranges but needs mapping to a single range when used as an index in the gic_data.ppi_descs[] array. Add a double-underscore version which takes just the intid. This will be used in the partition domain select and translate helpers to enable partition support for the EPPI range. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210729172748.28841-2-james.morse@arm.com
|
#
0e5cb777 |
|
27-Feb-2021 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic: Split vGIC probing information from the GIC code The vGIC advertising code is unsurprisingly very much tied to the GIC implementations. However, we are about to extend the support to lesser implementations. Let's dissociate the vgic registration from the GIC code and move it into KVM, where it makes a bit more sense. This also allows us to mark the gic_kvm_info structures as __initdata. Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
382e6e17 |
|
10-Jun-2021 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Workaround inconsistent PMR setting on NMI entry The arm64 entry code suffers from an annoying issue on taking a NMI, as it sets PMR to a value that actually allows IRQs to be acknowledged. This is done for consistency with other parts of the code, and is in the process of being fixed. This shouldn't be a problem, as we are not enabling interrupts whilst in NMI context. However, in the infortunate scenario that we took a spurious NMI (retired before the read of IAR) *and* that there is an IRQ pending at the same time, we'll ack the IRQ in NMI context. Too bad. In order to avoid deadlocks while running something like perf, teach the GICv3 driver about this situation: if we were in a context where no interrupt should have fired, transiently set PMR to a value that only allows NMIs before acking the pending interrupt, and restore the original value after that. This papers over the core issue for the time being, and makes NMIs great again. Sort of. Fixes: 4d6a38da8e79e94c ("arm64: entry: always set GIC_PRIO_PSR_I_SET during entry") Co-developed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/lkml/20210610145731.1350460-1-maz@kernel.org
|
#
a97709f5 |
|
23-Apr-2021 |
He Ying <heying24@huawei.com> |
irqchip/gic-v3: Do not enable irqs when handling spurious interrups We triggered the following error while running our 4.19 kernel with the pseudo-NMI patches backported to it: [ 14.816231] ------------[ cut here ]------------ [ 14.816231] kernel BUG at irq.c:99! [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____)) [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] Hardware name: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [ 14.816258] Modules linked in: start_dp(O) smeth(O) [ 15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt [ 15.103099] SMP: stopping secondary CPUs [ 15.103100] Kernel Offset: disabled [ 15.103100] CPU features: 0x36,a2400218 [ 15.103100] Memory Limit: none which is cause by a 'BUG_ON(in_nmi())' in nmi_enter(). From the call trace, we can find three interrupts (noted A, B, C above): interrupt (A) is preempted by (B), which is further interrupted by (C). Subsequent investigations show that (B) results in nmi_enter() being called, but that it actually is a spurious interrupt. Furthermore, interrupts are reenabled in the context of (B), and (C) fires with NMI priority. We end-up with a nested NMI situation, something we definitely do not want to (and cannot) handle. The bug here is that spurious interrupts should never result in any state change, and we should just return to the interrupted context. Moving the handling of spurious interrupts as early as possible in the GICv3 handler fixes this issue. Fixes: 3f1f3234bc2d ("irqchip/gic-v3: Switch to PMR masking before calling IRQ handler") Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: He Ying <heying24@huawei.com> [maz: rewrote commit message, corrected Fixes: tag] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210423083516.170111-1-heying24@huawei.com Cc: stable@vger.kernel.org
|
#
a359f757 |
|
21-Mar-2021 |
Ingo Molnar <mingo@kernel.org> |
irq: Fix typos in comments Fix ~36 single-word typos in the IRQ, irqchip and irqdomain code comments. Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
d4034114 |
|
21-Jan-2021 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
irqchip/gic-v3: Fix typos in PMR/RPR SCR_EL3.FIQ handling explanation The GICv3 driver explanation related to PMR/RPR and SCR_EL3.FIQ secure/non-secure priority handling contains a couple of typos. Fix them. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210121182252.29320-1-lorenzo.pieralisi@arm.com
|
#
6abbd698 |
|
09-Nov-2020 |
Valentin Schneider <valentin.schneider@arm.com> |
irqchip/gic, gic-v3: Make SGIs use handle_percpu_devid_irq() handle_percpu_devid_fasteoi_ipi() states: * The biggest difference with the IRQ version is that the interrupt is * EOIed early, as the IPI could result in a context switch, and we need to * make sure the IPI can fire again All that can actually happen scheduler-wise within the handling of an IPI is the raising of TIF_NEED_RESCHED (and / or folding thereof into preempt_count); see scheduler_ipi() or sched_ttwu_pending() for instance. Said flag / preempt_count is evaluated some time later before returning to whatever context was interrupted, and this gates a call to preempt_schedule_irq() (arm64_preempt_schedule_irq() in arm64). Per the above, SGI's do not need a different handler than PPI's, so make them use the same (handle_percpu_devid_irq). Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-2-valentin.schneider@arm.com
|
#
64b499d8 |
|
25-Apr-2020 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Configure SGIs as standard interrupts Change the way we deal with GICv3 SGIs by turning them into proper IRQs, and calling into the arch code to register the interrupt range instead of a callback. Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
33678059 |
|
12-Sep-2020 |
Alexandru Elisei <alexandru.elisei@arm.com> |
irqchip/gic-v3: Support pseudo-NMIs when SCR_EL3.FIQ == 0 The GIC's internal view of the priority mask register and the assigned interrupt priorities are based on whether GIC security is enabled and whether firmware routes Group 0 interrupts to EL3. At the moment, we support priority masking when ICC_PMR_EL1 and interrupt priorities are either both modified by the GIC, or both left unchanged. Trusted Firmware-A's default interrupt routing model allows Group 0 interrupts to be delivered to the non-secure world (SCR_EL3.FIQ == 0). Unfortunately, this is precisely the case that the GIC driver doesn't support: ICC_PMR_EL1 remains unchanged, but the GIC's view of interrupt priorities is different from the software programmed values. Support pseudo-NMIs when SCR_EL3.FIQ == 0 by using a different value to mask regular interrupts. All the other values remain the same. Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200912153707.667731-3-alexandru.elisei@arm.com
|
#
4e594ad1 |
|
12-Sep-2020 |
Alexandru Elisei <alexandru.elisei@arm.com> |
irqchip/gic-v3: Spell out when pseudo-NMIs are enabled When NMIs cannot be enabled, the driver prints a message stating that unambiguously. When they are enabled, the only feedback we get is a message regarding the use of synchronization for ICC_PMR_EL1 writes, which is not as useful for a user who is not intimately familiar with how NMIs are implemented. Let's make it obvious that pseudo-NMIs are enabled. Keep the message about using a barrier for ICC_PMR_EL1 writes, because it has a non-negligible impact on performance. Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200912153707.667731-2-alexandru.elisei@arm.com
|
#
70a29c32 |
|
25-Apr-2020 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Describe the SGI range As we are about to start making use of SGIs in a more conventional way, let's describe it is the GICv3 list of interrupt types. Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
1b57d91b |
|
30-Jul-2020 |
Valentin Schneider <valentin.schneider@arm.com> |
irqchip/gic-v2, v3: Prevent SW resends entirely The GIC irqchips can now use a HW resend when a retrigger is invoked by check_irq_resend(). However, should the HW resend fail, check_irq_resend() will still attempt to trigger a SW resend, which is still a bad idea for the GICs. Prevent this from happening by setting IRQD_HANDLE_ENFORCE_IRQCTX on all GIC IRQs. Technically per-cpu IRQs do not need this, as their flow handlers never set IRQS_PENDING, but this aligns all IRQs wrt context enforcement: this also forces all GIC IRQ handling to happen in IRQ context (as defined by in_irq()). Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200730170321.31228-3-valentin.schneider@arm.com
|
#
17f644e9 |
|
30-Jul-2020 |
Valentin Schneider <valentin.schneider@arm.com> |
irqchip/gic-v2, v3: Implement irq_chip->irq_retrigger() While digging around IRQCHIP_EOI_IF_HANDLED and irq/resend.c, it has come to my attention that the IRQ resend situation seems a bit precarious for the GIC(s). When marking an IRQ with IRQS_PENDING, handle_fasteoi_irq() will bail out and issue an irq_eoi(). Should the IRQ in question be re-enabled, check_irq_resend() will trigger a SW resend, which will go through the flow handler again and issue *another* irq_eoi() on the *same* IRQ activation. This is something the GIC spec clearly describes as a bad idea: any EOI must match a previous ACK. Implement irq_chip.irq_retrigger() for the GIC chips by setting the GIC pending bit of the relevant IRQ. After being called by check_irq_resend(), this will eventually trigger a *new* interrupt which we will handle as usual. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200730170321.31228-2-valentin.schneider@arm.com
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
aba3c7ed |
|
30-May-2020 |
Oscar Carter <oscar.carter@gmx.com> |
drivers/irqchip: Use new macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY 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 <maz@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Oscar Carter <oscar.carter@gmx.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20200530143430.5203-3-oscar.carter@gmx.com
|
#
cc86432a |
|
21-May-2020 |
Valentin Schneider <valentin.schneider@arm.com> |
irqchip/gic-v2, v3: Drop extra IRQ_NOAUTOEN setting for (E)PPIs (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
|
#
8a94c1ab |
|
22-Apr-2020 |
Ingo Rohloff <ingo.rohloff@lauterbach.com> |
irqchip/gic-v3: Fix missing "__init" for gic_smp_init() 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
|
#
96806229 |
|
10-Apr-2020 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling 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>
|
#
eeaa4b24 |
|
11-Mar-2020 |
luanshi <zhangliguang@linux.alibaba.com> |
irqchip/gic-v3: Move irq_domain_update_bus_token to after checking for NULL domain irq_domain_update_bus_token should be called after checking for NULL domain. Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1583983255-44115-1-git-send-email-zhangliguang@linux.alibaba.com
|
#
3c40706d |
|
04-Mar-2020 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v4.1: Advertise support v4.1 to KVM Tell KVM that we support v4.1. Nothing uses this information so far. 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-7-maz@kernel.org
|
#
9058a4e9 |
|
04-Mar-2020 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v4.1: Ensure mutual exclusion betwen invalidations on the same RD The GICv4.1 spec says that it is CONTRAINED UNPREDICTABLE to write to any of the GICR_INV{LPI,ALL}R registers if GICR_SYNCR.Busy == 1. To deal with it, we must ensure that only a single invalidation can happen at a time for a given redistributor. Add a per-RD lock to that effect and take it around the invalidation/syncr-read to deal with this. 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-6-maz@kernel.org
|
#
0b04758b |
|
04-Mar-2020 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Use SGIs without active state if offered To allow the direct injection of SGIs into a guest, the GICv4.1 architecture has to sacrifice the Active state so that SGIs look a lot like LPIs (they are injected by the same mechanism). In order not to break existing software, the architecture gives offers guests OSs the choice: SGIs with or without an active state. It is the hypervisors duty to honor the guest's choice. For this, the architecture offers a discovery bit indicating whether the GIC supports GICv4.1 SGIs (GICD_TYPER2.nASSGIcap), and another bit indicating whether the guest wants Active-less SGIs or not (controlled by GICD_CTLR.nASSGIreq). A hypervisor not supporting GICv4.1 SGIs would leave nASSGIcap clear, and a guest not knowing about GICv4.1 SGIs (or definitely wanting an Active state) would leave nASSGIreq clear (both being thankfully backward compatible with older revisions of the GIC). Since Linux is perfectly happy without an active state on SGIs, inform the hypervisor that we'll use that if offered. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20200304203330.4967-2-maz@kernel.org
|
#
d01fd161 |
|
11-Mar-2020 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Workaround Cavium erratum 38539 when reading GICD_TYPER2 Despite the architecture spec requiring that reserved registers in the GIC distributor memory map are RES0 (and thus are not allowed to generate an exception), the Cavium ThunderX (aka TX1) SoC explodes as such: [ 0.000000] GICv3: GIC: Using split EOI/Deactivate mode [ 0.000000] GICv3: 128 SPIs implemented [ 0.000000] GICv3: 0 Extended SPIs implemented [ 0.000000] Internal error: synchronous external abort: 96000210 [#1] SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc4-00035-g3cf6a3d5725f #7956 [ 0.000000] Hardware name: cavium,thunder-88xx (DT) [ 0.000000] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 0.000000] pc : __raw_readl+0x0/0x8 [ 0.000000] lr : gic_init_bases+0x110/0x560 [ 0.000000] sp : ffff800011243d90 [ 0.000000] x29: ffff800011243d90 x28: 0000000000000000 [ 0.000000] x27: 0000000000000018 x26: 0000000000000002 [ 0.000000] x25: ffff8000116f0000 x24: ffff000fbe6a2c80 [ 0.000000] x23: 0000000000000000 x22: ffff010fdc322b68 [ 0.000000] x21: ffff800010a7a208 x20: 00000000009b0404 [ 0.000000] x19: ffff80001124dad0 x18: 0000000000000010 [ 0.000000] x17: 000000004d8d492b x16: 00000000f67eb9af [ 0.000000] x15: ffffffffffffffff x14: ffff800011249908 [ 0.000000] x13: ffff800091243ae7 x12: ffff800011243af4 [ 0.000000] x11: ffff80001126e000 x10: ffff800011243a70 [ 0.000000] x9 : 00000000ffffffd0 x8 : ffff80001069c828 [ 0.000000] x7 : 0000000000000059 x6 : ffff8000113fb4d1 [ 0.000000] x5 : 0000000000000001 x4 : 0000000000000000 [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000 [ 0.000000] x1 : 0000000000000000 x0 : ffff8000116f000c [ 0.000000] Call trace: [ 0.000000] __raw_readl+0x0/0x8 [ 0.000000] gic_of_init+0x188/0x224 [ 0.000000] of_irq_init+0x200/0x3cc [ 0.000000] irqchip_init+0x1c/0x40 [ 0.000000] init_IRQ+0x160/0x1d0 [ 0.000000] start_kernel+0x2ec/0x4b8 [ 0.000000] Code: a8c47bfd d65f03c0 d538d080 d65f03c0 (b9400000) when reading the GICv4.1 GICD_TYPER2 register, which is unexpected... Work around it by adding a new quirk for the following variants: ThunderX: CN88xx OCTEON TX: CN83xx, CN81xx OCTEON TX2: CN93xx, CN96xx, CN98xx, CNF95xx* and use this flag to avoid accessing GICD_TYPER2. Note that all reserved registers (including redistributors and ITS) are impacted by this erratum, but that only GICD_TYPER2 has to be worked around so far. Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Robert Richter <rrichter@marvell.com> Tested-by: Mark Salter <msalter@redhat.com> Tested-by: Tim Harvey <tharvey@gateworks.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Robert Richter <rrichter@marvell.com> Link: https://lore.kernel.org/r/20191027144234.8395-11-maz@kernel.org Link: https://lore.kernel.org/r/20200311115649.26060-1-maz@kernel.org
|
#
926b5dfa |
|
16-Dec-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Only provision redistributors that are enabled in ACPI We currently allocate redistributor region structures for individual redistributors when ACPI doesn't present us with compact MMIO regions covering multiple redistributors. It turns out that we allocate these structures even when the redistributor is flagged as disabled by ACPI. It works fine until someone actually tries to tarse one of these structures, and access the corresponding MMIO region. Instead, track the number of enabled redistributors, and only allocate what is required. This makes sure that there is no invalid data to misuse. Signed-off-by: Marc Zyngier <maz@kernel.org> Reported-by: Heyi Guo <guoheyi@huawei.com> Tested-by: Heyi Guo <guoheyi@huawei.com> Link: https://lore.kernel.org/r/20191216062745.63397-1-guoheyi@huawei.com
|
#
f2d83409 |
|
24-Dec-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add GICv4.1 VPEID size discovery While GICv4.0 mandates 16 bit worth of VPEIDs, GICv4.1 allows smaller implementations to be built. Add the required glue to dynamically compute the limit. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191224111055.11836-3-maz@kernel.org
|
#
b25319d2 |
|
24-Dec-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Detect GICv4.1 supporting RVPEID GICv4.1 supports the RVPEID ("Residency per vPE ID"), which allows for a much efficient way of making virtual CPUs resident (to allow direct injection of interrupts). The functionnality needs to be discovered on each and every redistributor in the system, and disabled if the settings are inconsistent. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191224111055.11836-2-maz@kernel.org
|
#
2c542426 |
|
17-Oct-2019 |
Daode Huang <huangdaode@hisilicon.com> |
irqchip: Remove redundant semicolon after while check drivers/irqchip with "make coccicheck M=drivers/irqchip/", it will report unneeded semicolon like below, just remove them. drivers/irqchip/irq-zevio.c:54:2-3: Unneeded semicolon drivers/irqchip/irq-gic-v3.c:177:2-3: Unneeded semicolon drivers/irqchip/irq-gic-v3.c:234:2-3: Unneeded semicolon Signed-off-by: Daode Huang <huangdaode@hisilicon.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1571300729-38822-1-git-send-email-huangdaode@hisilicon.com
|
#
f2266504 |
|
02-Oct-2019 |
Marc Zyngier <maz@kernel.org> |
arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear The GICv3 architecture specification is incredibly misleading when it comes to PMR and the requirement for a DSB. It turns out that this DSB is only required if the CPU interface sends an Upstream Control message to the redistributor in order to update the RD's view of PMR. This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't the case in Linux. It can still be set from EL3, so some special care is required. But the upshot is that in the (hopefuly large) majority of the cases, we can drop the DSB altogether. This relies on a new static key being set if the boot CPU has PMHE set. The drawback is that this static key has to be exported to modules. Cc: Will Deacon <will@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Julien Thierry <julien.thierry.kdev@gmail.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
c107d613 |
|
18-Sep-2019 |
Zenghui Yu <yuzenghui@huawei.com> |
irqchip/gic-v3: Fix GIC_LINE_NR accessor As per GIC spec, ITLinesNumber indicates the maximum SPI INTID that the GIC implementation supports. And the maximum SPI INTID an implementation might support is 1019 (field value 11111). max(GICD_TYPER_SPIS(...), 1020) is not what we actually want for GIC_LINE_NR. Fix it to min(GICD_TYPER_SPIS(...), 1020). Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1568789850-14080-1-git-send-email-yuzenghui@huawei.com
|
#
7f2481b3 |
|
31-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add quirks for HIP06/07 invalid GICD_TYPER erratum 161010803 It looks like the HIP06/07 SoCs have extra bits in their GICD_TYPER registers, which confuse the GICv3.1 code (these systems appear to expose ESPIs while they actually don't). Detect these systems as early as possible and wipe the fields that should be RES0 in the register. Tested-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
ad5a78d3 |
|
25-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Warn about inconsistent implementations of extended ranges As is it usual for the GIC, it isn't disallowed to put together a system that is majorly inconsistent, with a distributor supporting the extended ranges while some of the CPUs don't. Kindly tell the user that things are sailing isn't going to be smooth. Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
5f51f803 |
|
18-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add EPPI range support Expand the pre-existing PPI support to be able to deal with the Extended PPI range (EPPI). This includes obtaining the number of PPIs from each individual redistributor, and compute the minimum set (just in case someone builds something really clever...). Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
52085d3f |
|
18-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Dynamically allocate PPI partition descriptors Again, PPIs are becoming a variable set. Let's hack the PPI partition code to make the top-level array dynamically allocated. Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
81a43273 |
|
17-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Dynamically allocate PPI NMI refcounts As we're about to have a variable number of PPIs, let's make the allocation of the NMI refcounts dynamic. Also apply some minor cleanups (moving things around). Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
1a60e1e6 |
|
18-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic: Prepare for more than 16 PPIs GICv3.1 allows up to 80 PPIs (16 legaci PPIs and 64 Extended PPIs), meaning we can't just leave the old 16 hardcoded everywhere. We also need to add the infrastructure to discover the number of PPIs on a per redistributor basis, although we still pretend there is only 16 of them for now. No functional change. Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
211bddd2 |
|
16-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add ESPI range support Add the required support for the ESPI range, which behave exactly like the SPIs of old, only with new funky INTIDs. Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
e91b036e |
|
16-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add INTID range and convertion primitives In the beginning, life was simple. The GIC driver mostly cared about PPIs, SPIs and LPIs, all with nicely layed out ranges. We're about to change all that, with new ranges such as EPPI and ESPI interleaved in the middle of the no-irq-land between the "special IDs" and the LPI range. Boo. In order to make our life less hellish, let's introduce a set of primitives that will allow ranges to be identified easily and offsets to be remapped. So far, there is no functionnal change. Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
13d22e2e |
|
16-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic: Rework gic_configure_irq to take the full ICFGR base gic_configure_irq is currently passed the (re)distributor address, to which it applies an a fixed offset to get to the configuration registers. This offset is constant across all GICs, or rather it was until to v3.1... An easy way out is for the individual drivers to pass the base address of the configuration register for the considered interrupt. At the same time, move part of the error handling back to the individual drivers, as things are about to change on that front. Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
eeee0d09 |
|
31-Jul-2019 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Register the distributor's PA instead of its VA in fwnode Do not expose the distributor's VA (it appears in debugfs). Instead, record the PA, which at least can be used to precisely identify the associated irqchip and domain. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
52f8c8b3 |
|
26-Jul-2019 |
Anders Roxell <anders.roxell@linaro.org> |
irqchip/gic-v3: Mark expected switch fall-through When fall-through warnings was enabled by default the following warning was starting to show up: In file included from ../arch/arm64/include/asm/cputype.h:132, from ../arch/arm64/include/asm/cache.h:8, from ../include/linux/cache.h:6, from ../include/linux/printk.h:9, from ../include/linux/kernel.h:15, from ../include/linux/list.h:9, from ../include/linux/kobject.h:19, from ../include/linux/of.h:17, from ../include/linux/irqdomain.h:35, from ../include/linux/acpi.h:13, from ../drivers/irqchip/irq-gic-v3.c:9: ../drivers/irqchip/irq-gic-v3.c: In function ‘gic_cpu_sys_reg_init’: ../arch/arm64/include/asm/sysreg.h:853:2: warning: this statement may fall through [-Wimplicit-fallthrough=] asm volatile(__msr_s(r, "%x0") : : "rZ" (__val)); \ ^~~ ../arch/arm64/include/asm/arch_gicv3.h:20:29: note: in expansion of macro ‘write_sysreg_s’ #define write_gicreg(v, r) write_sysreg_s(v, SYS_ ## r) ^~~~~~~~~~~~~~ ../drivers/irqchip/irq-gic-v3.c:773:4: note: in expansion of macro ‘write_gicreg’ write_gicreg(0, ICC_AP0R2_EL1); ^~~~~~~~~~~~ ../drivers/irqchip/irq-gic-v3.c:774:3: note: here case 6: ^~~~ Rework so that the compiler doesn't warn about fall-through. Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning") Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
17ce302f |
|
11-Jun-2019 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
arm64: Fix interrupt tracing in the presence of NMIs In the presence of any form of instrumentation, nmi_enter() should be done before calling any traceable code and any instrumentation code. Currently, nmi_enter() is done in handle_domain_nmi(), which is much too late as instrumentation code might get called before. Move the nmi_enter/exit() calls to the arch IRQ vector handler. On arm64, it is not possible to know if the IRQ vector handler was called because of an NMI before acknowledging the interrupt. However, It is possible to know whether normal interrupts could be taken in the interrupted context (i.e. if taking an NMI in that context could introduce a potential race condition). When interrupting a context with IRQs disabled, call nmi_enter() as soon as possible. In contexts with IRQs enabled, defer this to the interrupt controller, which is in a better position to know if an interrupt taken is an NMI. Fixes: bc3c03ccb464 ("arm64: Enable the support of pseudo-NMIs") Cc: <stable@vger.kernel.org> # 5.1.x- Cc: Will Deacon <will.deacon@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Julien Thierry <julien.thierry@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
caab277b |
|
02-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 234 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not see http www gnu org licenses extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 503 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Enrico Weigelt <info@metux.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190602204653.811534538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
90b4c555 |
|
10-Jun-2019 |
Zeev Zilberman <zeev@amazon.com> |
irqchip/gic-v2m: Add support for Amazon Graviton variant of GICv3+GICv2m Add support for Amazon Graviton custom variant of GICv2m, where the message is encoded using the MSI message address, as opposed to standard GICv2m, where the SPI number is encoded in the MSI message data. In addition, the Graviton flavor of GICv2m is used along GICv3 (and not GICv2). Co-developed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Zeev Zilberman <zeev@amazon.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
60574d1e |
|
11-Mar-2019 |
Keith Busch <kbusch@kernel.org> |
acpi: Create subtable parsing infrastructure Parsing entries in an ACPI table had assumed a generic header structure. There is no standard ACPI header, though, so less common layouts with different field sizes required custom parsers to go through their subtable entry list. Create the infrastructure for adding different table types so parsing the entries array may be more reused for all ACPI system tables and the common code doesn't need to be duplicated. Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Tested-by: Brice Goglin <Brice.Goglin@inria.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
101b35f7 |
|
31-Jan-2019 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
irqchip/gic-v3: Allow interrupts to be set as pseudo-NMI Implement NMI callbacks for GICv3 irqchip. Install NMI safe handlers when setting up interrupt line as NMI. Only SPIs and PPIs are allowed to be set up as NMI. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
f32c9266 |
|
31-Jan-2019 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
irqchip/gic-v3: Handle pseudo-NMIs Provide a higher priority to be used for pseudo-NMIs. When such an interrupt is received, keep interrupts fully disabled at CPU level to prevent receiving other pseudo-NMIs while handling the current one. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
d98d0a99 |
|
31-Jan-2019 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
irqchip/gic-v3: Detect if GIC can support pseudo-NMIs The values non secure EL1 needs to use for PMR and RPR registers depends on the value of SCR_EL3.FIQ. The values non secure EL1 sees from the distributor and redistributor depend on whether security is enabled for the GIC or not. To avoid having to deal with two sets of values for PMR masking/unmasking, only enable pseudo-NMIs when GIC has non-secure view of priorities. Also, add firmware requirements related to SCR_EL3. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
e7932188 |
|
31-Jan-2019 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
arm64: Switch to PMR masking when starting CPUs Once the boot CPU has been prepared or a new secondary CPU has been brought up, use ICC_PMR_EL1 to mask interrupts on that CPU and clear PSR.I bit. Since ICC_PMR_EL1 is initialized at CPU bringup, avoid overwriting it in the GICv3 driver. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Suggested-by: Daniel Thompson <daniel.thompson@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
b5cf6073 |
|
31-Jan-2019 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
irqchip/gic-v3: Factor group0 detection into functions The code to detect whether Linux has access to group0 interrupts can prove useful in other parts of the driver. Provide a separate function to do this. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
3f1f3234 |
|
31-Jan-2019 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
irqchip/gic-v3: Switch to PMR masking before calling IRQ handler Mask the IRQ priority through PMR and re-enable IRQs at CPU level, allowing only higher priority interrupts to be received during interrupt handling. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
9c8114c2 |
|
10-Dec-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
irqchip/gic-v3: Add quirk for msm8996 broken registers Access to GICR_WAKER is restricted on msm8996 SoC in Hypervisor. Its been more than 2+ years of wait for this to be fixed, which has no hopes to be fixed. This change was introduced for the "lead device" on msm8996 platform. It looks like all publicly available msm8996 and other Qualcomm SoCs have this implementation. So add a quirk to not access this register on msm8996. With this quirk MSM8996 can at least boot out of mainline, which can help community to work with boards based on MSM8996 and other SoCs with have this restrictions. This Quirk is based on device tree compatible string. Without this patch Qualcomm DB820c board reboots when GICR_WAKER is accessed. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
f70fdb42 |
|
10-Dec-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
irqchip/gic: Add support to device tree based quirks This patch adds support to device tree based quirks based on device tree compatible string. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
2ef790dc |
|
27-Aug-2018 |
Rob Herring <robh@kernel.org> |
irqchip: Convert to using %pOFn instead of device_node.name In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier. Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
342677d7 |
|
28-Aug-2018 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
irqchip/gic-v3: Remove acknowledge loop Multiple interrupts pending for a CPU is actually rare. Doing an acknowledge loop does not give much better performance or even can deteriorate them. Do not loop when an interrupt has been acknowledged, just return from interrupt and wait for another one to be raised. Tested-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Julien Thierry <julien.thierry@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
d38a71c5 |
|
27-Jul-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3-its: Change initialization ordering for LPIs We currently initialize the LPIs (and the ITS) fairly early, even before the SMP support and the CPU interface. This is a bit odd (as LPIs are not exactly crutial for the early boot process), and is going to cause issues when reorganizing the probing code. Let's move this initialization later. Reviewed-by: Julien Thierry <julien.thierry@arm.com> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Tested-by: Lei Zhang <zhang.lei@jp.fujitsu.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
4110b5cb |
|
17-Aug-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Allow interrupt to be configured as wake-up sources 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 <ilina@codeaurora.org> Tested-by: Lina Iyer <ilina@codeaurora.org> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
a4f9edb2 |
|
30-May-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Expose GICD_TYPER in the rdist structure Instead of exposing the GIC distributor IntID field in the rdist structure that is passed to the ITS, let's replace it with a copy of the whole GICD_TYPER register. We are going to need some of this information at a later time. No functionnal change. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
6396bb22 |
|
12-Jun-2018 |
Kees Cook <keescook@chromium.org> |
treewide: kzalloc() -> kcalloc() The kzalloc() function has a 2-factor argument form, kcalloc(). This patch replaces cases of: kzalloc(a * b, gfp) with: kcalloc(a * b, gfp) as well as handling cases of: kzalloc(a * b * c, gfp) with: kzalloc(array3_size(a, b, c), gfp) as it's slightly less ugly than: kzalloc_array(array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: kzalloc(4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ type TYPE; expression THING, E; @@ ( kzalloc( - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | kzalloc( - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression COUNT; typedef u8; typedef __u8; @@ ( kzalloc( - sizeof(u8) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(__u8) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(char) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(unsigned char) * (COUNT) + COUNT , ...) | kzalloc( - sizeof(u8) * COUNT + COUNT , ...) | kzalloc( - sizeof(__u8) * COUNT + COUNT , ...) | kzalloc( - sizeof(char) * COUNT + COUNT , ...) | kzalloc( - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - kzalloc + kcalloc ( - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ identifier SIZE, COUNT; @@ - kzalloc + kcalloc ( - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( kzalloc( - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kzalloc( - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kzalloc( - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( kzalloc( - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kzalloc( - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kzalloc( - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | kzalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ identifier STRIDE, SIZE, COUNT; @@ ( kzalloc( - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kzalloc( - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression E1, E2, E3; constant C1, C2, C3; @@ ( kzalloc(C1 * C2 * C3, ...) | kzalloc( - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | kzalloc( - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | kzalloc( - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | kzalloc( - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( kzalloc(sizeof(THING) * C2, ...) | kzalloc(sizeof(TYPE) * C2, ...) | kzalloc(C1 * C2 * C3, ...) | kzalloc(C1 * C2, ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - kzalloc + kcalloc ( - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - kzalloc + kcalloc ( - (E1) * E2 + E1, E2 , ...) | - kzalloc + kcalloc ( - (E1) * (E2) + E1, E2 , ...) | - kzalloc + kcalloc ( - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
50528752 |
|
08-May-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add support for Message Based Interrupts as an MSI controller GICv3 offers the possibility to signal SPIs using a pair of doorbells (SETPI, CLRSPI) under the name of Message Based Interrupts (MBI). They can be used as either traditional (edge) MSIs, or the more exotic level-triggered flavour. Let's implement support for platform MSI, which is the original intent for this feature. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Rob Herring <robh@kernel.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lkml.kernel.org/r/20180508121438.11301-8-marc.zyngier@arm.com
|
#
b2425b51 |
|
08-May-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Mark the base irq domain as DOMAIN_BUS_WIRED As we're about to introduce MSI domains based on top of the GICv3 domain, we must make sure nothing the new domains do not alias with the core domain. So let's tag that core domain with the DOMAIN_BUS_WIRED attribute, ensuring it gets picked up by other drivers that use irq_find_host(). Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Rob Herring <robh@kernel.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lkml.kernel.org/r/20180508121438.11301-7-marc.zyngier@arm.com
|
#
d01d3274 |
|
26-Mar-2018 |
Davidlohr Bueso <dave@stgolabs.net> |
irqchip/gic: Update supports_deactivate static key to modern api 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: Marc Zyngier <marc.zyngier@arm.com>
|
#
33625282 |
|
20-Mar-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Probe for SCR_EL3 being clear before resetting AP0Rn 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: Marc Zyngier <marc.zyngier@arm.com>
|
#
66569052 |
|
20-Mar-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Don't try to reset AP0Rn 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: d6062a6d62c6 irqchip/gic-v3: Reset APgRn registers at boot time Reported-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
65da7d19 |
|
20-Mar-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Do not check trigger configuration of partitionned LPIs 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: Marc Zyngier <marc.zyngier@arm.com>
|
#
6ef6386e |
|
16-Mar-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Loudly complain about the use of IRQ_TYPE_NONE 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 <marc.zyngier@arm.com>
|
#
f736d65d |
|
25-Feb-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Allow LPIs to be disabled from the command line 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 <marc.zyngier@arm.com>
|
#
d6062a6d |
|
09-Mar-2018 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Reset APgRn registers at boot time 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 <marc.zyngier@arm.com>
|
#
21ec30c0 |
|
31-Jan-2018 |
Shanker Donthineni <shankerd@codeaurora.org> |
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq() 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 <will.deacon@arm.com>, Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
b6dd4d83 |
|
02-Feb-2018 |
Mark Salter <msalter@redhat.com> |
irqchip/gic-v3: Change pr_debug message to pr_devel 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: [<0000000099c891ec>] down_trylock+0x20/0x4c but task is already holding lock: (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc which 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/0x4 other info that might help us debug this: Chain exists of: (console_sem).lock --> &p->pi_lock --> &rq->lock Possible 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: [<000000001366df53>] wake_up_new_task+0x40/0x470 #1: (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc stack 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 12000 This 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 <msalter@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
ebe2f871 |
|
05-Dec-2017 |
Shanker Donthineni <shankerd@codeaurora.org> |
irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry 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 [<ffff000008087770>] dump_backtrace+0x0/0x218 [<ffff0000080879dc>] show_stack+0x14/0x20 [<ffff00000883b078>] dump_stack+0x98/0xb8 [<ffff0000080c5c14>] panic+0x118/0x26c [<ffff000008b62348>] init_IRQ+0x24/0x2c [<ffff000008b609fc>] start_kernel+0x230/0x394 [<ffff000008b601e4>] __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 <shankerd@codeaurora.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
c08ec7da |
|
02-Jan-2018 |
Suzuki K Poulose <suzuki.poulose@arm.com> |
irqchip: gic-v3: Use of_cpu_node_to_id helper Use the new generic helper of_cpu_node_to_id() instead of using our own version to map a device node to logical CPU number. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
71192a68 |
|
13-Nov-2017 |
Arvind Yadav <arvind.yadav.cs@gmail.com> |
irqchip/gic-v3: pr_err() strings should end with newlines pr_err() messages should end with a new-line to avoid other messages being concatenated. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
00ee9a1c |
|
11-Nov-2017 |
Johan Hovold <johan@kernel.org> |
irqchip/gic-v3: Fix ppi-partitions lookup 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") Cc: stable <stable@vger.kernel.org> # 4.7 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
d33a3c8c |
|
06-Dec-2016 |
Christoffer Dall <cdall@linaro.org> |
KVM: arm/arm64: Check that system supports split eoi/deactivate Some systems without proper firmware and/or hardware description data don't support the split EOI and deactivate operation. On such systems, we cannot leave the physical interrupt active after the timer handler on the host has run, so we cannot support KVM with an in-kernel GIC with the timer changes we are about to introduce. This patch makes sure that trying to initialize the KVM GIC code will fail on such systems. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
|
#
eda0d04a |
|
06-Oct-2017 |
Shanker Donthineni <shankerd@codeaurora.org> |
irqchip/gic-v3: Add support for Range Selector (RS) feature A new feature Range Selector (RS) has been added to GIC specification in order to support more than 16 CPUs at affinity level 0. New fields are introduced in SGI system registers (ICC_SGI0R_EL1, ICC_SGI1R_EL1 and ICC_ASGI1R_EL1) to relax an artificial limit of 16 at level 0. - A new RSS field in ICC_CTLR_EL3, ICC_CTLR_EL1 and ICV_CTLR_EL1: [18] - Range Selector Support (RSS) 0b0 = Targeted SGIs with affinity level 0 values of 0-15 are supported. 0b1 = Targeted SGIs with affinity level 0 values of 0-255 are supported. - A new RS field in ICC_SGI0R_EL1, ICC_SGI1R_EL1 and ICC_ASGI1R_EL1: [47:44] - RangeSelector (RS) which group of 16 TargetList[n] field TargetList[n] represents aff0 value ((RS*16)+n) When ICC_CTLR_EL3.RSS==0 or ICC_CTLR_EL1.RSS==0, RS is RES0. - A new RSS field in GICD_TYPER: [26] - Range Selector Support (RSS) 0b0 = Targeted SGIs with affinity level 0 values of 0-15 are supported. 0b1 = Targeted SGIs with affinity level 0 values of 0-255 are supported. Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
3fad4cda |
|
15-Sep-2017 |
zijun_hu <zijun_hu@htc.com> |
irqchip/gic-v3: Iterate over possible CPUs by for_each_possible_cpu() get_cpu_number() doesn't use existing helper to iterate over possible CPUs, It will cause an error in case of discontinuous @cpu_possible_mask such as 0b11110001, which can result from a core having failed to come up on a SMP machine. Fixed by using existing helper for_each_possible_cpu(). Signed-off-by: zijun_hu <zijun_hu@htc.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
4bdf5025 |
|
25-Jun-2017 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Advertise GICv4 support to KVM As KVM needs to know about the availability of GICv4 to enable direct injection of interrupts, let's advertise the feature in the gic_kvm_info structure. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
0edc23ea |
|
19-Dec-2016 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add VLPI/DirectLPI discovery Add helper functions that probe for VLPI and DirectLPI properties. Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
0d94ded2 |
|
19-Dec-2016 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add redistributor iterator In order to discover the VLPI properties, we need to iterate over the redistributor regions. As we already have code that does this, let's factor it out and make it slightly more generic. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
e81f54c6 |
|
18-Jul-2017 |
Rob Herring <robh@kernel.org> |
irqchip: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Lee Jones <lee@kernel.org> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: Sylvain Lemieux <slemieux.tyco@gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com> Cc: linux-rpi-kernel@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Cc: linux-tegra@vger.kernel.org Acked-by: Eric Anholt <eric@anholt.net> Acked-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Acked-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Alexandre Torgue <alexandre.torgue@st.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
956ae91a |
|
18-Aug-2017 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Report that effective affinity is a single target The GICv3 driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-5-marc.zyngier@arm.com
|
#
39a06b67 |
|
18-Jul-2017 |
Will Deacon <will@kernel.org> |
irqchip/gic: Ensure we have an ISB between ack and ->handle_irq Devices that expose their interrupt status registers via system registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer, vgic (although unused by Linux), ...) rely on a context synchronising operation on the CPU to ensure that the updated status register is visible to the CPU when handling the interrupt. This usually happens as a result of taking the IRQ exception in the first place, but there are two race scenarios where this isn't the case. For example, let's say we have two peripherals (X and Y), where Y uses a system register for its interrupt status. Case 1: 1. CPU takes an IRQ exception as a result of X raising an interrupt 2. Y then raises its interrupt line, but the update to its system register is not yet visible to the CPU 3. The GIC decides to expose Y's interrupt number first in the Ack register 4. The CPU runs the IRQ handler for Y, but the status register is stale Case 2: 1. CPU takes an IRQ exception as a result of X raising an interrupt 2. CPU reads the interrupt number for X from the Ack register and runs its IRQ handler 3. Y raises its interrupt line and the Ack register is updated, but again, the update to its system register is not yet visible to the CPU. 4. Since the GIC drivers poll the Ack register, we read Y's interrupt number and run its handler without a context synchronisation operation, therefore seeing the stale register value. In either case, we run the risk of missing an IRQ. This patch solves the problem by ensuring that we execute an ISB in the GIC drivers prior to invoking the interrupt handler. This is already the case for GICv3 and EOIMode 1 (the usual case for the host). Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
65a30f8b |
|
04-Jul-2017 |
Suzuki K Poulose <suzuki.poulose@arm.com> |
irqchip/gic-v3: Honor forced affinity setting Honor the 'force' flag for set_affinity, by selecting a CPU from the given mask (which may not be reported "online" by the cpu_online_mask). Some drivers, like ARM PMU, rely on it. Cc: Marc Zyngier <marc.zyngier@arm.com> Reported-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
63c16c6e |
|
04-Jul-2017 |
Suzuki K Poulose <suzuki.poulose@arm.com> |
irqchip/gic-v3: Report failures in gic_irq_domain_alloc If the GIC cannot map an IRQ via irq_domain_ops->alloc(), it doesn't return an error code. This can cause a problem with drivers, where it thinks it has successfully got an IRQ for the device, but requesting the same ends up failure with -ENOSYS (as the IRQ's chip is not set). Fixes: commit 443acc4f37f6 ("irqchip: GICv3: Convert to domain hierarchy") Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
866d7c1b |
|
30-Jun-2017 |
Suzuki K Poulose <suzuki.poulose@arm.com> |
irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity The GICv3 driver doesn't check if the target CPU for gic_set_affinity is valid before going ahead and making the changes. This triggers the following splat with KASAN: [ 141.189434] BUG: KASAN: global-out-of-bounds in gic_set_affinity+0x8c/0x140 [ 141.189704] Read of size 8 at addr ffff200009741d20 by task swapper/1/0 [ 141.189958] [ 141.190158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.12.0-rc7 [ 141.190458] Hardware name: Foundation-v8A (DT) [ 141.190658] Call trace: [ 141.190908] [<ffff200008089d70>] dump_backtrace+0x0/0x328 [ 141.191224] [<ffff20000808a1b4>] show_stack+0x14/0x20 [ 141.191507] [<ffff200008504c3c>] dump_stack+0xa4/0xc8 [ 141.191858] [<ffff20000826c19c>] print_address_description+0x13c/0x250 [ 141.192219] [<ffff20000826c5c8>] kasan_report+0x210/0x300 [ 141.192547] [<ffff20000826ad54>] __asan_load8+0x84/0x98 [ 141.192874] [<ffff20000854eeec>] gic_set_affinity+0x8c/0x140 [ 141.193158] [<ffff200008148b14>] irq_do_set_affinity+0x54/0xb8 [ 141.193473] [<ffff200008148d2c>] irq_set_affinity_locked+0x64/0xf0 [ 141.193828] [<ffff200008148e00>] __irq_set_affinity+0x48/0x78 [ 141.194158] [<ffff200008bc48a4>] arm_perf_starting_cpu+0x104/0x150 [ 141.194513] [<ffff2000080d73bc>] cpuhp_invoke_callback+0x17c/0x1f8 [ 141.194783] [<ffff2000080d94ec>] notify_cpu_starting+0x8c/0xb8 [ 141.195130] [<ffff2000080911ec>] secondary_start_kernel+0x15c/0x200 [ 141.195390] [<0000000080db81b4>] 0x80db81b4 [ 141.195603] [ 141.195685] The buggy address belongs to the variable: [ 141.196012] __cpu_logical_map+0x200/0x220 [ 141.196176] [ 141.196315] Memory state around the buggy address: [ 141.196586] ffff200009741c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 141.196913] ffff200009741c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 141.197158] >ffff200009741d00: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00 [ 141.197487] ^ [ 141.197758] ffff200009741d80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00 [ 141.198060] ffff200009741e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 141.198358] ================================================================== [ 141.198609] Disabling lock debugging due to kernel taint [ 141.198961] CPU1: Booted secondary processor [410fd051] This patch adds the check to make sure the cpu is valid. Fixes: commit 021f653791ad17e03f98 ("irqchip: gic-v3: Initial support for GICv3") Cc: stable@vger.kernel.org Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
6896bcd1 |
|
21-Dec-2016 |
Thomas Gleixner <tglx@linutronix.de> |
irqchip/gic: Consolidate hotplug state space Even if both drivers are compiled in only one instance can run on a given system depending on the available GIC version. So having seperate hotplug states for them is pointless. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Sebastian Siewior <bigeasy@linutronix.de> Link: http://lkml.kernel.org/r/20161221192112.252416267@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
73c1b41e |
|
21-Dec-2016 |
Thomas Gleixner <tglx@linutronix.de> |
cpu/hotplug: Cleanup state names When the state names got added a script was used to add the extra argument to the calls. The script basically converted the state constant to a string, but the cleanup to convert these strings into meaningful ones did not happen. Replace all the useless strings with 'subsys/xxx/yyy:state' strings which are used in all the other places already. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sebastian Siewior <bigeasy@linutronix.de> Link: http://lkml.kernel.org/r/20161221192112.085444152@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
a4023f68 |
|
08-Nov-2016 |
Suzuki K Poulose <suzuki.poulose@arm.com> |
arm64: Add hypervisor safe helper for checking constant capabilities The hypervisor may not have full access to the kernel data structures and hence cannot safely use cpus_have_cap() helper for checking the system capability. Add a safe helper for hypervisors to check a constant system capability, which *doesn't* fall back to checking the bitmap maintained by the kernel. With this, make the cpus_have_cap() only check the bitmask and force constant cap checks to use the new API for quicker checks. Cc: Robert Ritcher <rritcher@cavium.com> Cc: Tirumalesh Chalamarla <tchalamarla@cavium.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
d102eb5c |
|
14-Oct-2016 |
Dan Carpenter <dan.carpenter@oracle.com> |
irqchip/gicv3: Handle loop timeout proper The timeout loop terminates when the loop count is zero, but the decrement of the count variable is post check. So count is -1 when we check for the timeout and therefor the error message is supressed. Change it to predecrement, so the error message is emitted. [ tglx: Massaged changelog ] Fixes: a2c225101234 ("irqchip: gic-v3: Refactor gic_enable_redist to support both enabling and disabling") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: kernel-janitors@vger.kernel.org Cc: Jason Cooper <jason@lakedaemon.net> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
727653d6 |
|
19-Sep-2016 |
James Morse <james.morse@arm.com> |
irqchip/gicv3: Silence noisy DEBUG_PER_CPU_MAPS warning gic_raise_softirq() walks the list of cpus using for_each_cpu(), it calls gic_compute_target_list() which advances the iterator by the number of CPUs in the cluster. If gic_compute_target_list() reaches the last CPU it leaves the iterator pointing at the last CPU. This means the next time round the for_each_cpu() loop cpumask_next() will be called with an invalid CPU. This triggers a warning when built with CONFIG_DEBUG_PER_CPU_MAPS: [ 3.077738] GICv3: CPU1: found redistributor 1 region 0:0x000000002f120000 [ 3.077943] CPU1: Booted secondary processor [410fd0f0] [ 3.078542] ------------[ cut here ]------------ [ 3.078746] WARNING: CPU: 1 PID: 0 at ../include/linux/cpumask.h:121 gic_raise_softirq+0x12c/0x170 [ 3.078812] Modules linked in: [ 3.078869] [ 3.078930] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-rc5+ #5188 [ 3.078994] Hardware name: Foundation-v8A (DT) [ 3.079059] task: ffff80087a1a0080 task.stack: ffff80087a19c000 [ 3.079145] PC is at gic_raise_softirq+0x12c/0x170 [ 3.079226] LR is at gic_raise_softirq+0xa4/0x170 [ 3.079296] pc : [<ffff0000083ead24>] lr : [<ffff0000083eac9c>] pstate: 200001c9 [ 3.081139] Call trace: [ 3.081202] Exception stack(0xffff80087a19fbe0 to 0xffff80087a19fd10) [ 3.082269] [<ffff0000083ead24>] gic_raise_softirq+0x12c/0x170 [ 3.082354] [<ffff00000808e614>] smp_send_reschedule+0x34/0x40 [ 3.082433] [<ffff0000080e80a0>] resched_curr+0x50/0x88 [ 3.082512] [<ffff0000080e89d0>] check_preempt_curr+0x60/0xd0 [ 3.082593] [<ffff0000080e8a60>] ttwu_do_wakeup+0x20/0xe8 [ 3.082672] [<ffff0000080e8bb8>] ttwu_do_activate+0x90/0xc0 [ 3.082753] [<ffff0000080ea9a4>] try_to_wake_up+0x224/0x370 [ 3.082836] [<ffff0000080eabc8>] default_wake_function+0x10/0x18 [ 3.082920] [<ffff000008103134>] __wake_up_common+0x5c/0xa0 [ 3.083003] [<ffff0000081031f4>] __wake_up_locked+0x14/0x20 [ 3.083086] [<ffff000008103f80>] complete+0x40/0x60 [ 3.083168] [<ffff00000808df7c>] secondary_start_kernel+0x15c/0x1d0 [ 3.083240] [<00000000808911a4>] 0x808911a4 [ 3.113401] Detected PIPT I-cache on CPU2 Avoid updating the iterator if the next call to cpumask_next() would cause the for_each_cpu() loop to exit. There is no change to gic_raise_softirq()'s behaviour, (cpumask_next()s eventual call to _find_next_bit() will return early as start >= nbits), this patch just silences the warning. Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3") Signed-off-by: James Morse <james.morse@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1474306155-3303-1-git-send-email-james.morse@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
db40f0a7 |
|
12-Sep-2016 |
Tomasz Nowicki <tn@semihalf.com> |
irqchip/gicv3-its: Refactor ITS DT init code to prepare for ACPI In order to add ACPI support we need to isolate ACPI&DT common code and move DT logic to corresponding functions. To achieve this we are using firmware agnostic handle which can be unpacked to either DT or ACPI node. No functional changes other than a very minor one: 1. Terminate its_init call with -ENODEV for non-DT case which allows to remove hack from its-gic-v3.c. 2. Fix ITS base register address type (from 'unsigned long' to 'phys_addr_t'), as a bonus we get nice string formatting. 3. Since there is only one of ITS parent domain convert it to static global variable and drop the parameter from its_probe_one. Users can refer to it in more convenient way then. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
91ef8442 |
|
19-Aug-2016 |
Daniel Thompson <daniel.thompson@linaro.org> |
irqchip/gic-v3: Reset BPR during initialization Currently, when running on FVP, CPU 0 boots up with its BPR changed from the reset value. This renders it impossible to (preemptively) prioritize interrupts on CPU 0. This is harmless on normal systems since Linux typically does not support preemptive interrupts. It does however cause problems in systems with additional changes (such as patches for NMI simulation). Many thanks to Andrew Thoelke for suggesting the BPR as having the potential to harm preemption. Suggested-by: Andrew Thoelke <andrew.thoelke@arm.com> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
ccd9432a |
|
17-Aug-2016 |
Sudeep Holla <sudeep.holla@arm.com> |
irqchip/gicv3: Remove disabling redistributor and group1 non-secure interrupts As per the GICv3 specification, to power down a processor using GICv3 and allow automatic power-on if an interrupt must be sent to a processor, software must set Enable to zero for all interrupt groups(by writing to GICC_CTLR or ICC_IGRPEN{0,1}_EL1/3 as appropriate. When commit 3708d52fc6bb ("irqchip: gic-v3: Implement CPU PM notifier") was introduced there were no firmware implementations(in particular PSCI) handling this. Linux kernel may not be aware of the CPU power state details and might fail to identify the power states that require quiescing the CPU interface. Even if it can be aware of those details, it can't determine which CPU power state have been triggered at the platform level and how the power control is implemented. This patch make disabling redistributor and group1 non-secure interrupts in the power down path and re-enabling of redistributor in the power-up path conditional. It will be handled in the kernel if and only if the non-secure accesses are permitted to access and modify control registers. It is left to the platform implementation otherwise. Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Tested-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
6670a6d8 |
|
13-Jul-2016 |
Richard Cochran <rcochran@linutronix.de> |
irqchip/gicv3: Convert to hotplug state machine Install the callbacks via the state machine. Signed-off-by: Richard Cochran <rcochran@linutronix.de> Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Jason Cooper <jason@lakedaemon.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: rt@linutronix.de Link: http://lkml.kernel.org/r/20160713153333.163186301@linutronix.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
cf1d9d11 |
|
11-May-2016 |
Andrew Jones <drjones@redhat.com> |
irqchip/gic-v3: Fix quiescence check in gic_enable_redist Make sure the two sides of the bitwise operation are bool. Signed-off-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
7c9b9730 |
|
06-May-2016 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Configure all interrupts as non-secure Group-1 The GICv3 driver wrongly assumes that it runs on the non-secure side of a secure-enabled system, while it could be on a system with a single security state, or a GICv3 with GICD_CTLR.DS set. Either way, it is important to configure this properly, or interrupts will simply not be delivered on this HW. Cc: stable@vger.kernel.org Reported-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
f86c4fbd |
|
25-Apr-2016 |
Will Deacon <will@kernel.org> |
irqchip/gic: Ensure ordering between read of INTACK and shared data When an IPI is generated by a CPU, the pattern looks roughly like: <write shared data> smp_wmb(); <write to GIC to signal SGI> On the receiving CPU we rely on the fact that, once we've taken the interrupt, then the freshly written shared data must be visible to us. Put another way, the CPU isn't going to speculate taking an interrupt. Unfortunately, this assumption turns out to be broken. Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy to read some shared_data. Before CPUx has done anything, a random peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised. CPUy then takes the IRQ and starts executing the entry code, heading towards gic_handle_irq. Furthermore, let's assume that a bunch of the previous interrupts handled by CPUy were SGIs, so the branch predictor kicks in and speculates that irqnr will be <16 and we're likely to head into handle_IPI. The prefetcher then grabs a speculative copy of shared_data which contains a stale value. Meanwhile, CPUx gets round to updating shared_data and asking the GIC to send an SGI to CPUy. Internally, the GIC decides that the SGI is more important than the peripheral interrupt (which hasn't yet been ACKed) but doesn't need to do anything to CPUy, because the IRQ line is already raised. CPUy then reads the ACK register on the GIC, sees the SGI value which confirms the branch prediction and we end up with a stale shared_data value. This patch fixes the problem by adding an smp_rmb() to the IPI entry code in gic_handle_irq. As it turns out, the combination of a control dependency and an ISB instruction from the EOI in the GICv3 driver is enough to provide the ordering we need, so we add a comment there justifying the absence of an explicit smp_rmb(). Cc: stable@vger.kernel.org Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
1839e576 |
|
11-Apr-2016 |
Julien Grall <julien.grall@arm.com> |
irqchip/gic-v3: Parse and export virtual GIC information Fill up the recently introduced gic_kvm_info with the hardware information used for virtualization. Signed-off-by: Julien Grall <julien.grall@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
#
611f039f |
|
11-Apr-2016 |
Julien Grall <julien.grall@arm.com> |
irqchip/gic-v3: Gather all ACPI specific data in a single structure The ACPI code requires to use global variables in order to collect information from the tables. To make clear those variables are ACPI specific, gather all of them in a single structure. Furthermore, even if some of the variables are not marked with __initdata, they are all only used during the initialization. Therefore, the new variable, which hold the structure, can be marked with __initdata. Signed-off-by: Julien Grall <julien.grall@arm.com> Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
#
68628bb8 |
|
11-Apr-2016 |
Julien Grall <julien.grall@arm.com> |
irqchip/gic-v3: Prefix all pr_* messages by "GICv3: " Currently, most of the pr_* messages in the GICv3 driver don't have a prefix. Add one to make clear where the messages come from. Signed-off-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
#
e3825ba1 |
|
11-Apr-2016 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Add support for partitioned PPIs Plug the partitioning layer into the GICv3 PPI code, parsing the DT and building the partition affinities and providing the generic code with partition data and callbacks. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: devicetree@vger.kernel.org Cc: Jason Cooper <jason@lakedaemon.net> Cc: Will Deacon <will.deacon@arm.com> Cc: Rob Herring <robh+dt@kernel.org> Link: http://lkml.kernel.org/r/1460365075-7316-5-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
0fc6fa29 |
|
19-Feb-2016 |
Antoine Tenart <atenart@kernel.org> |
irqchip/gic-v3: Always return IRQ_SET_MASK_OK_DONE in gic_set_affinity Always return IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK when the affinity has been updated. When using stacked irqchips, returning IRQ_SET_MASK_OK_DONE means skipping all descendant irqchips. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
b70fb7af |
|
19-Jan-2016 |
Tomasz Nowicki <tn@semihalf.com> |
irqchip/gic-v3: ACPI: Add redistributor support via GICC structures Following ACPI spec: On systems supporting GICv3 and above, GICR Base Address in MADT GICC structure holds the 64-bit physical address of the associated Redistributor. If all of the GIC Redistributors are in the always-on power domain, GICR structures should be used to describe the Redistributors instead, and this field must be set to 0. It means that we have two ways to initialize registirbutors map. 1. via GICD structure which can accommodate many redistributors as a region 2. via GICC which is able to describe single redistributor This patch is going to add support for second option. Considering redistributors, GICD and GICC subtables have be mutually exclusive. While discovering and mapping redistributor, we need to know its size in advance. For the GICC case, redistributor can be in a power-domain that is off, thus we cannot relay on GICR TYPER register. Therefore, we get GIC version from distributor register and map 2xSZ_64K for GICv3 and 4xSZ_64K for GICv4. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
ffa7d616 |
|
19-Jan-2016 |
Tomasz Nowicki <tn@semihalf.com> |
irqchip/gic-v3: Add ACPI support for GICv3/4 initialization With the refator of gic_of_init(), GICv3/4 can be initialized by gic_init_bases() with gic distributor base address and gic redistributor region(s). So get the redistributor region base addresses from MADT GIC redistributor subtable, and the distributor base address from GICD subtable to init GICv3 irqchip in ACPI way. Note: GIC redistributor base address may also be provided in GICC structures on systems supporting GICv3 and above if the GIC Redistributors are not in the always-on power domain, this patch didn't implement such feature yet. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
db57d746 |
|
19-Jan-2016 |
Tomasz Nowicki <tn@semihalf.com> |
irqchip/gic-v3: Refactor gic_of_init() for GICv3 driver Isolate hardware abstraction (FDT) code to gic_of_init(). Rest of the logic goes to gic_init_bases() and expects well defined data to initialize GIC properly. The same solution is used for GICv2 driver. This is needed for ACPI initialization later. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
db8c70ec |
|
13-Oct-2015 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Fix translation of LPIs after conversion to irq_fwspec Commit f833f57ff254 ("irqchip: Convert all alloc/xlate users from of_node to fwnode") converted the GICv3 driver to using irq_fwspec as part of its 'translate' method. Too bad it ended up with a copy of the GICv2 'translate' method, which screws up LPI translation (by not translating them at all). Restore the code in its original shape, and just change what is really required... Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Cc: Duc Dang <dhdang@apm.com> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1444822037-16983-2-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
f833f57f |
|
12-Oct-2015 |
Marc Zyngier <maz@kernel.org> |
irqchip: Convert all alloc/xlate users from of_node to fwnode Since we now have a generic data structure to express an interrupt specifier, convert all hierarchical irqchips that are OF based to use a fwnode_handle as part of their alloc and xlate (which becomes translate) callbacks. As most of these drivers have dependencies (they exchange IRQ specifiers), change them all in a single, massive patch... Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-and-tested-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Tomasz Nowicki <tomasz.nowicki@linaro.org> Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Cc: Graeme Gregory <graeme@xora.org.uk> Cc: Jake Oshins <jakeo@microsoft.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Link: http://lkml.kernel.org/r/1444737105-31573-6-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
5d4c9bc7 |
|
12-Oct-2015 |
Marc Zyngier <maz@kernel.org> |
irqdomain: Use irq_domain_get_of_node() instead of direct field access The struct irq_domain contains a "struct device_node *" field (of_node) that is almost the only link between the irqdomain and the device tree infrastructure. In order to prepare for the removal of that field, convert all users to use irq_domain_get_of_node() instead. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-and-tested-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Tomasz Nowicki <tomasz.nowicki@linaro.org> Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Cc: Graeme Gregory <graeme@xora.org.uk> Cc: Jake Oshins <jakeo@microsoft.com> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Link: http://lkml.kernel.org/r/1444737105-31573-2-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
72c97126 |
|
01-Oct-2015 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
irqchip/gic-v3: Specialize readq and writeq accesses On 32bit platforms, we cannot assure that an I/O ldrd or strd will be done atomically. Besides, an hypervisor would be unable to emulate such accesses. In order to allow the AArch32 version of the driver to split them into two 32bit accesses while keeping the requirement for atomic writes, this patch specializes the IROUTER and TYPER accesses. Since the latter is an ID register, it won't need to be read atomically, but we still avoid future confusion by using gic_read_typer instead of a generic gic_readq. Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
f6c86a41 |
|
01-Oct-2015 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
irqchip/gic-v3: Change unsigned types for AArch32 compatibility This patch does a few simple compatibility-related changes: - change the system register access prototypes to their actual size, - homogenise mpidr accesses with unsigned long, - force the 64bit register values to unsigned long long. Note: the list registers are 64bit on GICv3, but the AArch32 vGIC driver will need to split their values into two 32bit registers: LRn and LRCn. Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
7936e914 |
|
01-Oct-2015 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
irqchip/gic-v3: Refactor the arm64 specific parts This patch moves the GICv3 system register access helpers to arch/arm64/. Their 32bit counterparts will need to use mrc/mcr accesses instead of mrs_s/msr_s. [maz: fixed conflict with Cavium erratum handling] Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
7cabd008 |
|
30-Sep-2015 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Make gic_enable_sre an inline function In order for gic_enable_sre to be used by the arm64 core code, move it to arm-gic-v3.h. As a bonus, we now also check if system registers have been already enabled, and return early if they have. In all cases, the function now returns a boolean indicating if the enabling has been successful. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
8ac2a170 |
|
21-Sep-2015 |
Robert Richter <rrichter@cavium.com> |
irqchip/gicv3-its: Use new jump label API Use newly introduced jump label API. Make this a separate patch for easier backporting to older kernels of the errata patch set. Signed-off-by: Robert Richter <rrichter@cavium.com> Reviewed-by: Marc Zygnier <marc.zyngier@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Tirumalesh Chalamarla <tchalamarla@cavium.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1442869119-1814-7-git-send-email-rric@kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
6d4e11c5 |
|
21-Sep-2015 |
Robert Richter <rrichter@cavium.com> |
irqchip/gicv3: Workaround for Cavium ThunderX erratum 23154 This patch implements Cavium ThunderX erratum 23154. The gicv3 of ThunderX requires a modified version for reading the IAR status to ensure data synchronization. Since this is in the fast-path and called with each interrupt, runtime patching is used using jump label patching for smallest overhead (no-op). This is the same technique as used for tracepoints. Signed-off-by: Robert Richter <rrichter@cavium.com> Reviewed-by: Marc Zygnier <marc.zyngier@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Tirumalesh Chalamarla <tchalamarla@cavium.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Jason Cooper <jason@lakedaemon.net> Cc: Will Deacon <will.deacon@arm.com> Link: http://lkml.kernel.org/r/1442869119-1814-3-git-send-email-rric@kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
d17cab44 |
|
29-Aug-2015 |
Rob Herring <robh@kernel.org> |
irqchip: Kill off set_irq_flags usage set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID -> !IRQ_NOREQUEST IRQF_PROBE -> !IRQ_NOPROBE IRQF_NOAUTOEN -> IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also modify IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. Signed-off-by: Rob Herring <robh@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: Russell King <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Lee Jones <lee@kernel.org> Cc: Alexander Shiyan <shc_work@mail.ru> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: linux-rpi-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Link: http://lkml.kernel.org/r/1440889285-5637-3-git-send-email-robh@kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
4df7f54d |
|
15-Sep-2015 |
Thomas Gleixner <tglx@linutronix.de> |
irqchip/gic-v3: Use IRQD_FORWARDED_TO_VCPU flag Get rid of the handler_data abuse. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
530bf353 |
|
26-Aug-2015 |
Marc Zyngier <maz@kernel.org> |
irqchip/GICv3: Don't deactivate interrupts forwarded to a guest Commit 0a4377de3056 ("genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a VCPU") added just what we needed at the lowest level to allow an interrupt to be deactivated by a guest. When such a request reaches the GIC, it knows it doesn't need to perform the deactivation anymore, and can safely leave the guest do its magic. This of course requires additional support in both VFIO and KVM. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-and-tested-by: Eric Auger <eric.auger@linaro.org> Cc: Christoffer Dall <christoffer.dall@linaro.org> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: kvmarm@lists.cs.columbia.edu Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1440604845-28229-3-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
0b6a3da9 |
|
26-Aug-2015 |
Marc Zyngier <maz@kernel.org> |
irqchip/GICv3: Convert to EOImode == 1 So far, GICv3 has been used in with EOImode == 0. The effect of this mode is to perform the priority drop and the deactivation of the interrupt at the same time. While this works perfectly for Linux (we only have a single priority), it causes issues when an interrupt is forwarded to a guest, and when we want the guest to perform the EOI itself. For this case, the GIC architecture provides EOImode == 1, where: - A write to ICC_EOIR1_EL1 drops the priority of the interrupt and leaves it active. Other interrupts at the same priority level can now be taken, but the active interrupt cannot be taken again - A write to ICC_DIR_EL1 marks the interrupt as inactive, meaning it can now be taken again. This patch converts the driver to be able to use this new mode, depending on whether or not the kernel can behave as a hypervisor. No feature change. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-and-tested-by: Eric Auger <eric.auger@linaro.org> Cc: Christoffer Dall <christoffer.dall@linaro.org> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: kvmarm@lists.cs.columbia.edu Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1440604845-28229-2-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
41a83e06 |
|
07-Jul-2015 |
Joel Porquet <joel@porquet.org> |
irqchip: Prepare for local stub header removal The IRQCHIP_DECLARE macro moved to to 'include/linux/irqchip.h', so the local irqchip.h became an empty shell, which solely includes include/linux/irqchip.h Include the global header in all irqchip drivers instead of the local header, so we can remove it. Signed-off-by: Joel Porquet <joel@porquet.org> Cc: vgupta@synopsys.com Cc: monstr@monstr.eu Cc: ralf@linux-mips.org Cc: jason@lakedaemon.net Link: http://lkml.kernel.org/r/1882096.X39jVG8e0D@joel-zenbook Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
55963c9f |
|
05-Jun-2015 |
Sudeep Holla <sudeep.holla@arm.com> |
irqchip: gic: Simplify gic_configure_irq by using IRQCHIP_SET_TYPE_MASKED GIC requires to disable the interrupt before changing the trigger type. irqchip core provides IRQCHIP_SET_TYPE_MASKED flag and ensures that the interrupt is masked before calling chip.irq_set_type() if the irqchip sets the flag. This patch adds IRQCHIP_SET_TYPE_MASKED to GIC irqchip so that the core can manage disabling the interrupt while changing the trigger type. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1433501997-19205-1-git-send-email-sudeep.holla@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
b594c6e2 |
|
18-Mar-2015 |
Marc Zyngier <maz@kernel.org> |
irqchip: GICv3: Add support for irq_[get, set]_irqchip_state() Add the required hooks for the internal state of an interrupt to be exposed to other subsystems. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Phong Vo <pvo@apm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Tin Huynh <tnhuynh@apm.com> Cc: Y Vo <yvo@apm.com> Cc: Toan Le <toanle@apm.com> Cc: Bjorn Andersson <bjorn@kryo.se> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Arnd Bergmann <arnd@arndb.de> Link: http://lkml.kernel.org/r/1426676484-21812-4-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
614be385 |
|
06-Mar-2015 |
Vladimir Murzin <vladimir.murzin@arm.com> |
irqchip: gic-v3: Fix out of bounds access to cpu_logical_map While playing with KASan support for arm64/arm the following appeared on boot: ================================================================== BUG: AddressSanitizer: out of bounds access in __asan_load8+0x14/0x1c at addr ffffffc000ad0dc0 Read of size 8 by task swapper/0/1 page:ffffffbdc202b400 count:1 mapcount:0 mapping: (null) index:0x0 flags: 0x400(reserved) page dumped because: kasan: bad access detected Address belongs to variable __cpu_logical_map+0x200/0x220 CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc6-next-20150129+ #481 Hardware name: FVP Base (DT) Call trace: [<ffffffc00008a794>] dump_backtrace+0x0/0x184 [<ffffffc00008a928>] show_stack+0x10/0x1c [<ffffffc00075e46c>] dump_stack+0xa0/0xf8 [<ffffffc0001df490>] kasan_report_error+0x23c/0x264 [<ffffffc0001e0188>] check_memory_region+0xc0/0xe4 [<ffffffc0001dedf0>] __asan_load8+0x10/0x1c [<ffffffc000431294>] gic_raise_softirq+0xc4/0x1b4 [<ffffffc000091fc0>] smp_send_reschedule+0x30/0x3c [<ffffffc0000f0d1c>] try_to_wake_up+0x394/0x434 [<ffffffc0000f0de8>] wake_up_process+0x2c/0x6c [<ffffffc0000d9570>] wake_up_worker+0x38/0x48 [<ffffffc0000dbb50>] insert_work+0xac/0xec [<ffffffc0000dbd38>] __queue_work+0x1a8/0x374 [<ffffffc0000dbf60>] queue_work_on+0x5c/0x7c [<ffffffc0000d8a78>] call_usermodehelper_exec+0x170/0x188 [<ffffffc0004037b8>] kobject_uevent_env+0x650/0x6bc [<ffffffc000403830>] kobject_uevent+0xc/0x18 [<ffffffc00040292c>] kset_register+0xa8/0xc8 [<ffffffc0004d6c88>] bus_register+0x134/0x2e8 [<ffffffc0004d73b4>] subsys_virtual_register+0x2c/0x5c [<ffffffc000a76a4c>] wq_sysfs_init+0x14/0x20 [<ffffffc000082a28>] do_one_initcall+0xa8/0x1fc [<ffffffc000a70db4>] kernel_init_freeable+0x1ec/0x294 [<ffffffc00075aa5c>] kernel_init+0xc/0xec Memory state around the buggy address: ffffff80003e0820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffff80003e0830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffff80003e0840: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffffff80003e0850: 00 00 fa fa fa fa fa fa 00 00 00 00 00 00 00 00 ================================================================== The reason for that cpumask_next() returns >= nr_cpu_ids if no further cpus set, but "==" condition is checked only, so we end up with out-of-bounds access to cpu_logical_map. Fix is by using the condition check for cpumask_next. Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1425659870-11832-7-git-send-email-marc.zyngier@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
f9b531fe |
|
04-Mar-2015 |
Rusty Russell <rusty@rustcorp.com.au> |
drivers: fix up obsolete cpu function usage. Thanks to spatch, plus manual removal of "&*". Then a sweep for for_each_cpu_mask => for_each_cpu. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Chris Metcalf <cmetcalf@ezchip.com> Cc: netdev@vger.kernel.org
|
#
fb7e7deb |
|
20-Jan-2015 |
Liviu Dudau <Liviu.Dudau@arm.com> |
irqchip: gic: Allow interrupt level to be set for PPIs During a recent cleanup of the arm64 DTs it has become clear that the handling of PPIs in xxxx_set_type() is incorrect. The ARM TRMs for GICv2 and later allow for "implementation defined" support for setting the edge or level type of the PPI interrupts and don't restrict the activation level of the signal. Current ARM implementations do restrict the PPI level type to IRQ_TYPE_LEVEL_LOW, but licensees of the IP can decide to shoot themselves in the foot at any time. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Marc Zyngier <Marc.Zyngier@arm.com> Cc: LAKML <linux-arm-kernel@lists.infradead.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Haojian Zhuang <haojian.zhuang@linaro.org> Link: http://lkml.kernel.org/r/1421772779-25764-1-git-send-email-Liviu.Dudau@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
7e580278 |
|
12-Nov-2014 |
Andre Przywara <andre.przywara@arm.com> |
arm64: GICv3: introduce symbolic names for GICv3 ICC_SGI1R_EL1 fields The gic_send_sgi() function used hardcoded bit shift values to generate the ICC_SGI1R_EL1 register value. Replace this with symbolic names to allow reusing them later. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
#
da33f31d |
|
24-Nov-2014 |
Marc Zyngier <maz@kernel.org> |
irqchip: GICv3: ITS: plug ITS init into main GICv3 code As the ITS is always a subsystem if GICv3, its probing/init is driven by the main GICv3 code. Plug that code in (guarded by a config option). Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1416839720-18400-12-git-send-email-marc.zyngier@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
f5c1434c |
|
24-Nov-2014 |
Marc Zyngier <maz@kernel.org> |
irqchip: GICv3: rework redistributor structure The basic GICv3 driver has almost no use for the redistributor (other than the basic per-CPU interrupts), but the ITS needs a lot more from them. As such, rework the set of data structures. The behaviour of the GICv3 driver is otherwise unaffected. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1416839720-18400-4-git-send-email-marc.zyngier@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
443acc4f |
|
24-Nov-2014 |
Marc Zyngier <maz@kernel.org> |
irqchip: GICv3: Convert to domain hierarchy In order to start supporting stacked domains, convert the GICv3 code base to the new domain hierarchy framework, which mostly amounts to supporting the new alloc/free callbacks. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1416839720-18400-3-git-send-email-marc.zyngier@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
3708d52f |
|
26-Aug-2014 |
Sudeep Holla <sudeep.holla@arm.com> |
irqchip: gic-v3: Implement CPU PM notifier When a CPU enters a low power state, the contents of the GICv3/4 system registers are lost. They need to be saved and restored if required. For now, since most of the GICv3 register are set some initial values and not modified at runtime, it is better to re-initialise rather than saving and restoring them. It may need to be saved and restored in future if required. This patch adds a notifier to disable the redistributor(if allowed) and Group1 interrupts when powering down the processor and to re-initialise the system registers on wakeup. Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1409065415-20176-3-git-send-email-sudeep.holla@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
a2c22510 |
|
26-Aug-2014 |
Sudeep Holla <sudeep.holla@arm.com> |
irqchip: gic-v3: Refactor gic_enable_redist to support both enabling and disabling Currently gic_enable_redist configures the redistributors to never assert WakeRequest signal. However when powering down the processors with wake-up enabled(i.e suspend), we need to configure it to assert that signal. This patch extends gic_enable_redist so that the redistributor can be configure to assert WakeRequest and hold interrupts as pending. This is useful in suspending the processors. This patch also adds check to make sure GICR_WAKER is accessible when configuring it. Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> [maz: removed reference to GICD_CTLR.DS and added read-back of GICR_WAKER to check that it is not RAZ/WI] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1409065415-20176-2-git-send-email-sudeep.holla@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
ebc6de00 |
|
26-Aug-2014 |
Marc Zyngier <maz@kernel.org> |
irqchip: gic-v3: Convert to handle_domain_irq Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1409047421-27649-19-git-send-email-marc.zyngier@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
fea322d1 |
|
26-Aug-2014 |
Will Deacon <will@kernel.org> |
irqchip: gic-v3: Declare rdist as __percpu pointer to __iomem pointer The __percpu __iomem annotations on the rdist base are contradictory and confuse static checkers such as sparse. This patch fixes the anotations so that rdist is described as a __percpu pointer to an __iomem pointer. Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1409062410-25891-9-git-send-email-will.deacon@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
c44e9d77 |
|
30-Jul-2014 |
Mark Brown <broonie@linaro.org> |
irqchip: gic-v3: Tag all low level accessors __maybe_unused This is only really needed for gic_write_sgi1r in the !SMP case since it is only referenced in the SMP initialisation code but it seems better to have these functions all next to each other and declared consistently. Signed-off-by: Mark Brown <broonie@linaro.org> Link: https://lkml.kernel.org/r/1406748194-21094-1-git-send-email-broonie@kernel.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
ddc86821 |
|
27-Jul-2014 |
Mark Brown <broonie@linaro.org> |
irqchip: gic-v3: Only define gic_peek_irq() when building SMP If building with CONFIG_SMP disbled (for example, with allnoconfig) then GCC complains that the static function gic_peek_irq() is defined but not used since the only reference is in the SMP initialisation code. Fix this by moving the function definition inside the ifdef. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1406480224-24628-1-git-send-email-broonie@kernel.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
#
72c58395 |
|
24-Jul-2014 |
Catalin Marinas <catalin.marinas@arm.com> |
arm64: gicv3: Allow GICv3 compilation with older binutils GICv3 introduces new system registers accessible with the full msr/mrs syntax (e.g. mrs x0, Sop0_op1_CRm_CRn_op2). However, only recent binutils understand the new syntax. This patch introduces msr_s/mrs_s assembly macros which generate the equivalent instructions above and converts the existing GICv3 code (both drivers/irqchip/ and arch/arm64/kernel/). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Olof Johansson <olof@lixom.net> Suggested-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Cc: Will Deacon <will.deacon@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com>
|
#
021f6537 |
|
30-Jun-2014 |
Marc Zyngier <maz@kernel.org> |
irqchip: gic-v3: Initial support for GICv3 The Generic Interrupt Controller (version 3) offers services that are similar to GICv2, with a number of additional features: - Affinity routing based on the CPU MPIDR (ARE) - System register for the CPU interfaces (SRE) - Support for more that 8 CPUs - Locality-specific Peripheral Interrupts (LPIs) - Interrupt Translation Services (ITS) This patch adds preliminary support for GICv3 with ARE and SRE, non-secure mode only. It relies on higher exception levels to grant ARE and SRE access. Support for LPI and ITS will be added at a later time. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Reviewed-by: Zi Shen Lim <zlim@broadcom.com> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Reviewed-by: Tirumalesh Chalamarla <tchalamarla@cavium.com> Reviewed-by: Yun Wu <wuyun.wu@huawei.com> Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com> Tested-by: Tirumalesh Chalamarla<tchalamarla@cavium.com> Tested-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> Acked-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lkml.kernel.org/r/1404140510-5382-3-git-send-email-marc.zyngier@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|