summaryrefslogtreecommitdiffstats
path: root/drivers/irqchip/irq-ixp4xx.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* irq: remove handle_domain_{irq,nmi}()Mark Rutland2021-10-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* irqchip/ixp4xx: Register the base PA instead of its VA in fwnodeMarc Zyngier2019-08-071-1/+1
| | | | | | | | | Do not expose the base 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>
* ARM: ixp4xx: mark ixp4xx_irq_setup as __initArnd Bergmann2019-06-181-4/+4
| | | | | | | | | | | | | | | | | | Kbuild complains about ixp4xx_irq_setup not being __init itself in some configurations: WARNING: vmlinux.o(.text+0x85bae4): Section mismatch in reference from the function ixp4xx_irq_setup() to the function .init.text:set_handle_irq() The function ixp4xx_irq_setup() references the function __init set_handle_irq(). This is often because ixp4xx_irq_setup lacks a __init annotation or the annotation of set_handle_irq is wrong. I suspect it normally gets inlined, so we get no such warning, but clang makes this obvious when the function is left out of line. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
* irqchip: ixp4xx: Add OF initialization supportLinus Walleij2019-04-231-0/+41
| | | | | | | | | | This adds support for probing and settin up the IXP4xx irqchip from device tree. Cc: Jason Cooper <jason@lakedaemon.net> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* irqchip: Add driver for IXP4xxLinus Walleij2019-04-191-0/+362
The IXP4xx (arch/arm/mach-ixp4xx) is an old Intel XScale platform that has very wide deployment and use. As part of modernizing the platform, we need to implement a proper irqchip in the irqchip subsystem. The IXP4xx irqchip is tightly jotted together with the GPIO controller, and whereas in the past we would deal with this complex logic by adding necessarily different code, we can nowadays modernize it using a hierarchical irqchip. The actual IXP4 irqchip is a simple active low level IRQ controller, whereas the GPIO functionality resides in a different memory area and adds edge trigger support for the interrupts. The interrupts from GPIO lines 0..12 are 1:1 mapped to a fixed set of hardware IRQs on this IRQchip, so we expect the child GPIO interrupt controller to go in and allocate descriptors for these interrupts. For the other interrupts, as we do not yet have DT support for this platform, we create a linear irqdomain and then go in and allocate the IRQs that the legacy boards use. This code will be removed on the DT probe path when we add DT support to the platform. We add some translation code for supporting DT translations for the fwnodes, but we leave most of that for later. Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Jason Cooper <jason@lakedaemon.net> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>