1) Always implement missing bus space methods using a panic() stub rather
than a NULL pointer. This appeared not to trip up any existing device
drivers, but due to the nature of the devices I'm supporting locally,
I'm making use of some of the more obscure busspace methods, and
panic() is a preferred failure mode. For example, do this for the
setregion methods.
2) Hook up several existing busspace method implementations that were
provided in the file, but not actually present in the methods
structure. Especially, single-byte bus I/O routines. This should
allow bugs to be fixed in the Atheros 802.11 driver.
There are still some remaining unimplemented methods that would be
desirable to implement -- especially, 64-bit I/O calls that would
observably accelerate device performance on FPGA-based soft CPU cores
that are typically clocked an order of magnitude slower than
conventional hard core CPUs, but that remains for another day.
MFC after: 3 weeks
Discussed with: jmallett, scottl
Sponsored by: DARPA, AFRL