In the SH-3/4 TLB access violation path we were enabling IRQs before
the call in to trace_hardirqs_on(), which ended up triggering:
        if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
                return;
in kernel/lockdep.c:2031. Fix this up by removing the early re-enable,
we were already re-enabling IRQs post-trace_hardirqs_on() already, so
the semantics are now as was initially intended.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
         lds    r10, pr
        rts
         nop
-0:     sti
-       mov.l   3f, r0
+0:     mov.l   3f, r0
        mov     r9, r6
        mov     r8, r5
        jmp     @r0