Re: [PATCH 2/2] irqchip/econet-en751221: Support MIPS 34Kc VEIC mode

Maciej W. Rozycki
2026-05-02T21:54:39Z

On Wed, 29 Apr 2026, Thomas Gleixner wrote:

> Other than those nits, this look like a reasonable solution for a
> completely unreasonable hardware design.

Why do you think this design is unreasonable?

How is that different, at the high level, from say the x86 APIC priority
resolver and vector generator, combined with the interrupt descriptor
table (except for additional optional GPR stack switching, which saves the
handler from the hassle and extra cycles needed for GPR preservation,
though I reckon with x86 you could use task gates in the IDT to yield a
similar effect although at much higher cost performance-wise as x86 does
not implement alternative GPR stacks)?

Analogously to x86 in the MIPS VEIC mode the IRQ number is determined by
the vector rather than the somewhat arbitrarily numbered (particularly in
cascaded topologies) IRQ line and available to the handler in the
CP0.Cause.RIPL register field.

NB this arbitrary non-VEIC IRQ numbering is particularly obvious with
MIPS platforms featuring an x86-style PCI southbridge with an embedded
8259A interrupt controller pair, where for compatibility with our driver
code we give root MIPS CPU IRQ lines numbers 16-23 while 8259A IRQ lines
cascaded from one of the IRQ lines 18-23 are given numbers 0-15.

Example such an odd topology:

CPU0
0: 0 XT-PIC 0 timer
1: 0 XT-PIC 1 i8042
2: 0 XT-PIC 2 cascade
3: 4 XT-PIC 3 ttyS1
4: 37 XT-PIC 4 ttyS0
6: 3 XT-PIC 6 floppy
7: 52456 XT-PIC 7 parport0
8: 0 XT-PIC 8 rtc0
10: 99668740 XT-PIC 10 fddi0
11: 0 XT-PIC 11 uhci_hcd:usb1
12: 1 XT-PIC 12 i8042
14: 0 XT-PIC 14 ata_piix
15: 15 XT-PIC 15 ata_piix
20: 0 MIPS 4 ttyS2
21: 0 MIPS 5 CoreHi
23: 803937130 MIPS 7 timer
ERR: 1

(where XT-PIC interrupts are cascaded from IRQ line 18/MIPS line 2, not
actually given stub registration). At least the VEIC mode brings some
sanity here.

FWIW,

Maciej