- 04 Jul, 2017 4 commits
-
-
Suzuki K Poulose authored
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 9a1091ef ("irqchip: gic: Support hierarchy irq domain.") Cc: Yingjoe Chen <yingjoe.chen@mediatek.com> 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>
-
Boris Brezillon authored
We are no longer using the root argument passed to the ->fixup() hooks. Remove it. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Boris Brezillon authored
of_find_compatible_node() is calling of_node_put() on its first argument thus leading to an unbalanced of_node_get/put() issue if the node has not been retained before that. Instead of passing the root node, pass NULL, which does exactly the same: iterate over all DT nodes, starting from the root node. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Fixes: 3d61467f ("irqchip: atmel-aic: Implement RTC irq fixup") Cc: <stable@vger.kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Boris Brezillon authored
aic_common_irq_fixup() is calling twice of_node_put() on the same node thus leading to an unbalanced refcount on the root node. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Fixes: b2f579b5 ("irqchip: atmel-aic: Add irq fixup infrastructure") Cc: <stable@vger.kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
- 30 Jun, 2017 3 commits
-
-
Pedro H. Penna authored
Usually, hardware implicitly acknowledges interrupts when reading them. However, if this is not the case, the IRQ gets fired over and over again in the current implementation. This patch uses the right mask acknowledge function to handle the aforementioned situation on or1k processors that interact with such kind of hardware. Acked-by: Stafford Horne <shorne@gmail.com> Signed-off-by: Pedro H. Penna <pedrohenriquepenna@gmail.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Dan Carpenter authored
BITS_TO_LONGS() gives us the number of longs we need, but we want to allocate the number of bytes. Fixes: a68a63cb ("irqchip/irq-mvebu-gicp: Add new driver for Marvell GICP") Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Suzuki K Poulose authored
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 021f6537 ("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>
-
- 23 Jun, 2017 7 commits
-
-
Shanker Donthineni authored
The current ITS driver is assuming every ITS hardware implementation supports minimum of 16bit INTID. But this is not true, as per GICv3 specification, INTID field is IMPLEMENTATION DEFINED in the range of 14-24 bits. We might see an unpredictable system behavior on systems where hardware support less than 16bits and software tries to use 64K LPI interrupts. On Qualcomm Datacenter Technologies QDF2400 platform, boot log shows confusing information about number of LPI chunks as shown below. The QDF2400 ITS hardware supports 24bit INTID. This patch allocates the memory resources for PEND/PROP tables based on discoverable value which is specified in GITS_TYPER.IDbits. Also it fixes the log message that reflects the correct number of LPI chunks were allocated. ITS@0xff7efe0000: allocated 524288 Devices @3c0400000 (indirect, esz 8, psz 64K, shr 1) ITS@0xff7efe0000: allocated 8192 Interrupt Collections @3c0130000 (flat, esz 8, psz 64K, shr 1) ITS@0xff7efe0000: allocated 8192 Virtual CPUs @3c0140000 (flat, esz 8, psz 64K, shr 1) ITS: Allocated 524032 chunks for LPIs PCI/MSI: ITS@0xff7efe0000 domain created Platform MSI: ITS@0xff7efe0000 domain created Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Ganapatrao Kulkarni authored
Add code to parse SRAT ITS Affinity sub table as defined in ACPI 6.2. Later in per device probe, ITS devices are mapped to numa node using ITS Id to proximity domain mapping. [maz: fix dependency on ACPICA, fixed structure name, minor cleanups] Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Arvind Yadav authored
of_device_ids are not supposed to change at runtime. All functions working with of_device_ids provided by <linux/of.h> work with const of_device_ids. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Arvind Yadav authored
of_device_ids are not supposed to change at runtime. All functions working with of_device_ids provided by <linux/of.h> work with const of_device_ids. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Thomas Petazzoni authored
The Marvell ICU unit is found in the CP110 block of the Marvell Armada 7K and 8K SoCs. It collects the wired interrupts of the devices located in the CP110 and turns them into SPI interrupts in the GIC located in the AP806 side of the SoC, by using a memory transaction. Until now, the ICU was configured in a static fashion by the firmware, and Linux was relying on this static configuration. By having Linux configure the ICU, we are more flexible, and we can allocate dynamically the GIC SPI interrupts only for devices that are actually in use. The driver was initially written by Hanna Hawa <hannah@marvell.com>. Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Thomas Petazzoni authored
This commit adds a simple driver for the Marvell GICP, a hardware unit that converts memory writes into GIC SPI interrupts. The driver provides a number of functions to the ICU driver to allocate GICP interrupts, and get the physical addresses that the ICUs should write to to set/clear interrupts. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Thomas Petazzoni authored
This commit adds the Device Tree binding documentation for the Marvell ICU interrupt controller, which collects wired interrupts from the devices located into the CP110 hardware block of Marvell Armada 7K/8K, and converts them into SPI interrupts in the GIC located in the AP hardware block, using the GICP extension. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
- 22 Jun, 2017 24 commits
-
-
Thomas Petazzoni authored
This commit adds the Device Tree binding documentation for the Marvell GICP, an extension to the GIC that allows to trigger GIC SPI interrupts using memory transactions. It is used by the ICU unit in the Marvell CP110 block to turn wired interrupts inside the CP into SPI interrupts at the GIC level in the AP. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Wei Yongjun authored
Use the builtin_platform_driver() macro to make the code simpler. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Brendan Higgins authored
The Aspeed 24XX/25XX chips share a single hardware interrupt across 14 separate I2C busses. This adds a dummy irqchip which maps the single hardware interrupt to software interrupts for each of the busses. Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Brendan Higgins authored
Added device tree binding documentation for Aspeed I2C Interrupt Controller. Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Andrew Jeffery authored
In addition to introducing the new compatible string the bindings description is reworked to be more generic. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Tobias Klauser authored
struct irq_domain_ops is not modified, so it can be made const. Cc: Joel Stanley <joel@jms.id.au> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Thomas Petazzoni authored
This reverts commit 353d6d6c, which is no longer needed, now that the irq-armada-370-xp driver properly re-enables per-CPU interrupt on both the boot CPU and secondary CPUs after resume. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Thomas Petazzoni authored
Commit d17cab44 ("irqchip: Kill off set_irq_flags usage") changed the code of armada_370_xp_mpic_irq_map() from using set_irq_flags() to irq_set_probe(). While the commit log seems to imply that there are no functional changes, there are indeed functional changes introduced by this commit: the IRQ_NOAUTOEN flag is no longer cleared. This functional change caused a regression on Armada XP, which no longer works properly after suspend/resume because per-CPU interrupts remain disabled. This regression was temporarly worked around in commit 353d6d6c ("irqchip/armada-370-xp: Fix regression by clearing IRQ_NOAUTOEN"), but it is not the most satisfying solution. This commit implements the solution that was initially discussed with Thomas Gleixner. Due to how the hardware registers work, the irq-armada-370-xp cannot simply save/restore a bunch of registers at suspend/resume to make sure that the interrupts remain in the same state after resuming. Therefore, it relies on the kernel to say whether the interrupt is disabled or not, using the irqd_irq_disabled() function. This was all working fine while the IRQ_NOAUTOEN flag was cleared. With the change introduced by Rob Herring in d17cab44, the IRQ_NOAUTOEN flag is now set for all interrupts. irqd_irq_disabled() returns false for per-CPU interrupts, and therefore our per-CPU interrupts are no longer re-enabled after resume. This commit fixes that by using irqd_irq_disabled() only for global interrupts, and using the newly introduced irq_percpu_is_enabled() for per-CPU interrupts. Also, it fixes a related problems that per-CPU interrupts were only re-enabled on the boot CPU and not other CPUs. Until now this wasn't a problem since on this platform, only the local timers are using per-CPU interrupts and the local timers of secondary CPUs are turned off/on during CPU hotplug before suspend, after after resume. However, since Linux 4.4, we are also be using per-CPU interrupts for the network controller, so we need to properly restore the per-CPU interrupts on secondary CPUs as well. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Thomas Petazzoni authored
Since the overall logic of the driver to handle the global and per-CPU masking of the interrupts is far from trivial, this commit adds a long comment detailing how the hardware operates and what strategy the driver implements on top of that. Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Thomas Petazzoni authored
In order to clarify to which register base the various register definitions apply, this commit re-orders them, and adds a comment that clearly indicate which registers are relative to "main_int_base" and which registers are relative to "per_cpu_int_base". Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
MaJun authored
Just skip the irq affinity setting when the target cpu is the same as current setting. This is a small optimization for irq affinity setting logic. Signed-off-by: MaJun <majun258@huawei.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Robin Murphy authored
The call to pci_for_each_dma_alias() in the ITS PCI code has aroused suspicion in the past, and upon closer inspection does turn out to be completely backwards. Rather than iterating through each RID alias of the given device, what we actually want to be doing here is iterating through all the *other* devices which may also alias the same RID, in order to size the table for the worst case. Do the right thing by ignoring the initial DMA aliases themselves and just using that walk to detect an aliasing bridge, then walking back down the bus topology as necessary to actually count everything else. Our alias handling still isn't perfect, since we don't account for the cases of certain bridges only taking ownership of transactions under particular circumstances, but without completely reworking the ITS code to cope with the notion of multiple DevIDs per device, it'll have to do. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Tobias Klauser authored
struct irq_domain_ops is not modified, so it can be made const. Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: uclinux-h8-devel@lists.sourceforge.jp Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Tobias Klauser authored
struct irq_domain_ops is not modified, so it can be made const. Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: uclinux-h8-devel@lists.sourceforge.jp Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Tobias Klauser authored
struct irq_domain_ops is not modified, so it can be made const. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Tobias Klauser authored
struct irq_domain_ops is not modified, so it can be made const. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Tobias Klauser authored
struct irq_domain_ops is not modified, so it can be made const. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Tobias Klauser authored
struct irq_domain_ops is not modified, so it can be made const. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Chen-Yu Tsai authored
The R_INTC on the A31 is undocumented. It was previously supported by the sun6i-a31-sc-nmi compatible. This compatible however required the register region to start at the first used register, rather than the boundaries laid out in the SoC's memory map. The new compatible fixes the alignment, while also naming it properly. Since the only difference between the old and new compatibles are a fixed offset for the registers, and since the old one is deprecated, this patch adds a set of register defines for the new compatible, while modifying the old set to reference the new set minus a fixed offset. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Chen-Yu Tsai authored
The A31 and later have an R_INTC block which handles the NMI interrupt pin on the SoC. This interrupt pin is used by the external PMIC to signal interrupts to the SoC. While this hardware block is undocumented, the interrupt offsets combined with the register regions for the existing "sun6i-a31-sc-nmi" compatible line up with the old interrupt controller found on the A10. Experiments show that only the first 32 interrupt lines can be enabled, and only the first (NMI) interrupt is actually connected. This patch adds a new, properly named compatible for the A31 R_INTC block, which requires the register region to be properly aligned to the block boundary. For comparison, the old "sun6i-a31-sc-nmi" compatible had its register region aligned with the first used register. This didn't match up with the memory map in the SoC's datasheet/user manual. Since the new compatible supercedes the old one, deprecate the old one. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Chen-Yu Tsai authored
The sunxi_sc_nmi_reg_offs, which hold the register offsets for the various variants, is never modified, and only used at init time within the init functions referenced by IRQCHIP_DECLARE, which themselves are tagged __init. Const-ify the sunxi_sc_nmi_reg_offs structures, and tag them as __initconst. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Chen-Yu Tsai authored
This is a pure code move to reorder the various sunxi_sc_nmi_reg_offs' by family and alphabetical order. No functionality changes. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Chen-Yu Tsai authored
The sunxi-nmi disables all its interrupts and clears any pending interrupts at probe time. Add comments documenting it, just to make it clear. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
Chen-Yu Tsai authored
The sunxi-nmi driver has a bunch of raw register offsets and bit values. Convert them into define macros for better readability. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
-
- 04 Jun, 2017 2 commits
-
-
Linus Torvalds authored
-
Richard Narron authored
This fixes a problem with reading files larger than 2GB from a UFS-2 file system: https://bugzilla.kernel.org/show_bug.cgi?id=195721 The incorrect UFS s_maxsize limit became a problem as of commit c2a9737f ("vfs,mm: fix a dead loop in truncate_inode_pages_range()") which started using s_maxbytes to avoid a page index overflow in do_generic_file_read(). That caused files to be truncated on UFS-2 file systems because the default maximum file size is 2GB (MAX_NON_LFS) and UFS didn't update it. Here I simply increase the default to a common value used by other file systems. Signed-off-by: Richard Narron <comet.berkeley@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Will B <will.brokenbourgh2877@gmail.com> Cc: Theodore Ts'o <tytso@mit.edu> Cc: <stable@vger.kernel.org> # v4.9 and backports of c2a9737fSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-