[PATCH] m68k: irq: Fix irq numbering in m68k_setup_user_interrupt()

[PATCH] m68k: irq: Fix irq numbering in m68k_setup_user_interrupt()

[Graeme Harker]

m68k_setup_user_interrupt() is meant to set up the user vector
interrupts IRQ_USER to IRQ_USER + cnt - 1, as its BUG_ON() check
assumes.  Since the change to irq_set_chip_and_handler(), however, it
sets up interrupts 0 to cnt - 1 instead, having lost the IRQ_USER
offset on the way.

The VME boards pass a count of 192, so the user vector interrupts they
use are still covered.  Sun-3 passes 128 but requests IRQ_USER + 127,
interrupt 135, which has been left without a chip, so its vec255
handler has failed to register ever since.  All of them have also had
user_irq_chip put on the autovector interrupts 1 to 7.  A machine with
only a few user vectors, such as one with a single vectored interrupt
source and cnt = 1, is left with its interrupt on handle_bad_irq().

Restore the offset.  Only tested on a machine that calls this with
cnt = 1; the VME, Sun-3, Atari and Apollo callers have not been
tested.

Fixes: 378f7ca6aa22 ("m68k/irq: Vector ints need a valid interrupt handler")
Signed-off-by: Graeme Harker <graeme.harker@gmail.com>
Assisted-by: Claude:claude-opus-5.5
---
The machine with cnt = 1 is a homebrew 68030 board whose support is
not upstream: one vectored interrupt source (a 68681 DUART, vector 64),
which stayed on handle_bad_irq() until this change.

The Sun-3 statement is from reading the code, not from running it:
sun3_init_IRQ() passes 128, so interrupts 0-127 got the chip, and then
requests IRQ_USER + 127 = 135.

Build-tested on m68k master (v7.4-rc2) with multi_defconfig,
sun3_defconfig and virt_defconfig.

 arch/m68k/kernel/ints.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/m68k/kernel/ints.c b/arch/m68k/kernel/ints.c
index cf2b13488476..eb41aace61d4 100644
--- a/arch/m68k/kernel/ints.c
+++ b/arch/m68k/kernel/ints.c
@@ -97,7 +97,8 @@ void __init m68k_setup_user_interrupt(unsigned int vec, unsigned int cnt)
 	BUG_ON(IRQ_USER + cnt > NR_IRQS);
 	m68k_first_user_vec = vec;
 	for (i = 0; i < cnt; i++)
-		irq_set_chip_and_handler(i, &user_irq_chip, handle_simple_irq);
+		irq_set_chip_and_handler(IRQ_USER + i, &user_irq_chip,
+					 handle_simple_irq);
 	*user_irqvec_fixup = vec - IRQ_USER;
 	flush_icache();
 }

base-commit: 8c9ddebb300c719362a52a2d465f44e7d055778d
-- 
2.53.0

Re: [PATCH] m68k: irq: Fix irq numbering in m68k_setup_user_interrupt()

[Graeme Harker]

Eero Tamminen recommended the Hatari emulator to me for testing the
Atari caller, so I have now done that.

Hatari from Git (4894d9a), emulating a Falcon and a TT (68030 with MMU,
68882, 14 MB ST-RAM, 64 MB TT-RAM), booted through Hatari's LILO with
its tools/linux/kernel.config and a small BusyBox initramfs. Kernels:
m68k master 8c9ddebb300c (v7.4-rc2) with and without this patch.

On both machines the two kernels boot to init with the same kernel log
and the same /proc/interrupts apart from the counts:

  Falcon: 4, 8, 12, 13, 14, 15, 21
  TT:     8, 12, 13, 14, 15, 39

all on the "atari" chip, ERR 0. That is what the code suggests:
atari_init_IRQ() puts atari_irq_chip on interrupts 1 to 141 straight
after the call, so on Atari the patch only stops user_irq_chip being
left on interrupt 0.

The Sun-3, VME and Apollo callers are still untested.

Thanks to Eero for the pointer.

Graeme