ARM: iop32x: use GENERIC_IRQ_MULTI_HANDLER
authorArnd Bergmann <arnd@arndb.de>
Tue, 30 Nov 2021 10:21:49 +0000 (11:21 +0100)
committerArd Biesheuvel <ardb@kernel.org>
Mon, 6 Dec 2021 11:49:04 +0000 (12:49 +0100)
commit6f5d248d05db9c4991366154f1a657a630faa583
tree5fe395ea47a1de65c5d461e74ab64c469260845a
parent9d67412f24cc3a2c05f35f7c856addb07a2960ce
ARM: iop32x: use GENERIC_IRQ_MULTI_HANDLER

iop32x uses the entry-macro.S file for both the IRQ entry and for
hooking into the arch_ret_to_user code path. This is done because the
cp6 registers have to be enabled before accessing any of the interrupt
controller registers but have to be disabled when running in user space.

There is also a lazy-enable logic in cp6.c, but during a hardirq, we
know it has to be enabled.

Both the cp6-enable code and the code to read the IRQ status can be
lifted into the normal generic_handle_arch_irq() path, but the
cp6-disable code has to remain in the user return code. As nothing
other than iop32x uses this hook, just open-code it there with an
ifdef for the platform that can eventually be removed when iop32x
has reached the end of its life.

The cp6-enable path in the IRQ entry has an extra cp_wait barrier that
the trap version does not have, but it is harmless to do it in both
cases to simplify the logic here at the cost of a few extra cycles
for the trap.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
arch/arm/Kconfig
arch/arm/kernel/entry-common.S
arch/arm/mach-iop32x/cp6.c
arch/arm/mach-iop32x/include/mach/entry-macro.S [deleted file]
arch/arm/mach-iop32x/iop3xx.h
arch/arm/mach-iop32x/irq.c