if_ath - should it be compiled without ath_hal support?

    I ran into the panic shown below because it appears that some
array indexing went off into the weeds. I haven't seen this happen but
once though when running a buildworld last night using r225089 on
i386.
    This begs the question - is it wise to compile if_ath without
ath_hal support today? I've been doing this recently because ath_hal
isn't available under /sys/modules , and unless I unload the module,
things like suspend and resume don't work because if_ath doesn't
support suspend/resume yet). There are a lot of references to the
ath_hal APIs in if_ath.c now that don't have #ifdefs guarding them as
well which concern me..
TIA!
-Garrett

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0xc5ec97f0
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc0c58968
stack pointer	        = 0x28:0xd87e2bfc
frame pointer	        = 0x28:0xd87e2c78
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 0 (ath0 taskq)
Physical memory: 1001 MB
Dumping 103 MB: 88 72 56 40 24 8

...

(kgdb) list
3659                            m->m_pkthdr.rcvif = ifp;
3660                            m->m_pkthdr.len = len;
3661                    }
3662
3663                    ifp->if_ipackets++;
3664                    sc->sc_stats.ast_ant_rx[rs->rs_antenna]++;
3665
3666                    /*
3667                     * Populate the rx status block.  When there are bpf
3668                     * listeners we do the additional work to provide
(kgdb) p sc->sc_stats.ast_ant_rx
$6 = {0, 3458, 0, 0, 0, 0, 0, 0}
(kgdb) p rs->rs_antenna
$7 = 8399232
(kgdb)