parisc: fix iosapic address compare

Hi Helge,

i just updated my C3750 to latest git, and got the kernel oops below. It looks like the change to using F_EXTEND breaks using 32 bit kernels on at least my C3750. Not sure whether we should revert the F_EXTEND change, or just cast the other side of the compare to long. The patch below does this.

      _______________________________ 
    < Your System ate a SPARC! Gah! >
     ------------------------------- 
            \   ^__^
                (__)\       )\/\
                 U  ||----w |
                    ||     ||
swapper (pid 1): Unknown kernel breakpoint (code 9)
CPU: 0 PID: 1 Comm: swapper Not tainted 5.0.0+ #60
Hardware name: 9000/785/C3750

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001111 Not tainted

r00-03  0004000f 109bf020 10451e1c 4fc58340
r04-07  109bf730 00000000 109bf020 00002710
r08-11  10852cf4 10852d08 1093d800 1093d800
r12-15  4fc43470 0000ffff 10998820 10459834
r16-19  101c9f28 00000000 38be5e00 00000000
r20-23  38be5e00 38000000 10459834 00000000
r24-27  3d090000 00000000 4fc43400 10902020
r28-31  00000000 38be5e00 4fc583c0 101165d4

sr00-03 00000000 00000000 00000000 00000000
sr04-07 00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 10459adc 10459ae0
IIR: 03ffe01f ISR: 102400ff IOR: 1605835c
CPU: 0 CR30: 4fc58000 CR31: ffffffff
ORIG_R28: 109a8820
IAOQ[0]: superio_init+0x2a8/0x508
IAOQ[1]: superio_init+0x2ac/0x508
RP(r2): pci_do_fixups+0x12c/0x208

Backtrace:
 [<10451e1c>] pci_do_fixups+0x12c/0x208
 [<101165d4>] 0x101165d4
 [<10156184>] do_one_initcall+0xa0/0x1d8
 [<101014dc>] 0x101014dc
 [<10762fd8>] kernel_init+0x20/0x1a0
 [<1015e01c>] ret_from_kernel_thread+0x1c/0x24

CPU: 0 PID: 1 Comm: swapper Not tainted 5.0.0+ #60
Hardware name: 9000/785/C3750
Backtrace:
 [<101593a4>] show_stack+0x3c/0x4c
 [<107494a8>] dump_stack+0x3c/0x4c
 [<1015953c>] die_if_kernel+0x16c/0x2ac
 [<1015a16c>] handle_interruption+0x91c/0x960
 [<10459adc>] superio_init+0x2a8/0x508
 [<10451e1c>] pci_do_fixups+0x12c/0x208
 [<101165d4>] 0x101165d4
 [<10156184>] do_one_initcall+0xa0/0x1d8
 [<101014dc>] 0x101014dc
 [<10762fd8>] kernel_init+0x20/0x1a0
 [<1015e01c>] ret_from_kernel_thread+0x1c/0x24

---[ end trace 7170ce927b5084fc ]---

Regards
Sven

Using F_EXTEND doesn't work here as it casts hpa to long,
which is 32 bit on parisc32, while dest_iosapic_addr is 64 bit.
Fix this by doing a cast to long on dest_iosapic_addr.

Fixes: 97d7e2e3fd8a ("parisc: Use F_EXTEND() macro in iosapic code")
Signed-off-by: Sven Schnelle <[email protected]>
---
 drivers/parisc/iosapic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 1be571c20062..1b0c3139d971 100644
@@ -158,7 +158,7 @@
 #endif
 
 #define COMPARE_IRTE_ADDR(irte, hpa)	\
-		((irte)->dest_iosapic_addr == F_EXTEND(hpa))
+		((long)(irte)->dest_iosapic_addr == F_EXTEND(hpa))
 
 #define IOSAPIC_REG_SELECT              0x00
 #define IOSAPIC_REG_WINDOW              0x10

2.20.1

Actually, it casts to unsigned long.

Dave

John David Anglin  [email protected]

Hi Sven,

* Sven Schnelle <[email protected]>:

Thanks for testing!
I think, as suggested by you, revertig parts of my patch makes most sense. I've committed the patch below to my for-next tree.
Can you check if it works for you?

Helge

--------------------
From dae50289effc106df023796eb25d602244e73ac1 Mon Sep 17 00:00:00 2001
From: Helge Deller <[email protected]>
Date: Mon, 18 Mar 2019 22:56:15 +0100
Subject: [PATCH] Revert: parisc: Use F_EXTEND() macro in iosapic code

Revert parts of commit 97d7e2e3fd8a ("parisc: Use F_EXTEND() macro in iosapic code"). It breaks booting the 32-bit kernel.

index 1be571c20062..6bad04cbb1d3 100644
@@ -157,8 +157,12 @@
 #define DBG_IRT(x...)
 #endif
 
+#ifdef CONFIG_64BIT
+#define COMPARE_IRTE_ADDR(irte, hpa)	((irte)->dest_iosapic_addr == (hpa))
+#else
 #define COMPARE_IRTE_ADDR(irte, hpa)	\
-		((irte)->dest_iosapic_addr == F_EXTEND(hpa))
+		((irte)->dest_iosapic_addr == ((hpa) | 0xffffffff00000000ULL))
+#endif
 
 #define IOSAPIC_REG_SELECT              0x00
 #define IOSAPIC_REG_WINDOW              0x10

Hi Helge,

Yes, works for me. The good thing about this Bug is that i was forced to read the NS87560 driver source and have an idea now why it's called SuckyIO :)

Regards
Sven