> Now, as the things seem to be, I end up with a 16 bit value in unknown
> byte order. How the hell should I, the poor driver writer, tell which 
> byteorder it is if the driver is supposed to be MI?

The byte order of the data returned to the user is always the native
byte order (or should be, if the code is working properly).


In other words, if the device is logically presenting a 16-bit
register containing the value 0xabcd, it should show up as 0xabcd when
read with bus_space_read_2.

Byte swapping shold be done -- either in hardware or software -- to
make sure that the data is converted from the bus's "native"
endianness to the endianness of the CPU.  (There do exist bus bridges,
e.g. which interface big-endaian CPUs to ISA busses, which
automatically do byte swapping on multi-byte reads, so register values
a preserved.)

If you're trying to read or write a string of characters, you should
either do thatf with _1 macros (which are supposed to do the 'right'
thing with the data), or be prepared to byte swap them yourself if the
bus the device you're talking to is attached to is a different
endianness than the CPU.



cgd