MIPS32 cache functions now using c-r4k?

[Hartvig Ekner <hartvig@ekner.info>]

On a MIPS32 CPU (Au1500), I now end up in:

Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Autoconfig PCI channel 0x802d0ab8
Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
Reserved instruction in kernel code in traps.c::do_ri, line 650:
$0 : 00000000 810e4000 802d0000 80109654 810e3000 802c4754 00000000 80000000
$8 : 8102e720 00000001 8010b98c c0000000 001fffff c0000000 fffffff4 00000010
$16: 810e3000 802d1340 802b9800 802bc000 00000000 00000000 00101000 00000000
$24: ffffffff 810ebde7                   810ea000 810ebd68 00000000 80121adc
Hi : 00000000
Lo : 000000c0
epc  : 8010965c    Not tainted
Status: 1000fc02
Cause : 00800028
Process swapper (pid: 1, stackpage=810ea000)

Which is:

80109654 <r4k_clear_page_d32>:
80109654:       24811000        addiu   $at,$a0,4096
80109658:       bc8d0000        cache   0xd,0($a0)
8010965c:       fc800000        sdc3    $0,0($a0)
80109660:       fc800008        sdc3    $0,8($a0)
80109664:       fc800010        sdc3    $0,16($a0)
80109668:       fc800018        sdc3    $0,24($a0)
8010966c:       24840040        addiu   $a0,$a0,64
80109670:       bc8dffe0        cache   0xd,-32($a0)
80109674:       fc80ffe0        sdc3    $0,-32($a0)
80109678:       fc80ffe8        sdc3    $0,-24($a0)
8010967c:       fc80fff0        sdc3    $0,-16($a0)
80109680:       1424fff5        bne     $at,$a0,80109658 <r4k_clear_page_d32+0x4>
80109684:       fc80fff8        sdc3    $0,-8($a0)
80109688:       03e00008        jr      $ra

It seems much of the r4k cache code assumes the presence of SD - which breaks on all MIPS32 CPU's?

/Hartvig