> I think we have a problem with the way our bus-space stuff is handled.
> 
> There is an increasing number of cards (all I've seen where ISA ISDN cards)
> whith brain-dead register mappings. Worst example of the week: the USR
> Sporster internal ISDN TA. Hellmuth Michaelis added support for it in FreeBSD
> within a  few hours, but I didn't dare to write the NetBSD low-level routines
> for it:
> 
> It uses 4 io-regions, one realy small just for configuration and three important
> ones. Inside the important ones an address is calculated by:
> 
> #define ADDR(reg)	\
> 	(((reg/4) * 1024) + ((reg%4) * 2))
> 
> where reg is in the 0x00 to 0x40 range. All access is to io-space. The four
> regions are at base+0, base+0x4000, base+0x8000, base+0xc000, where base
> is typicaly something like 0x280.

Oh, that one looks sick, but is easy.

If I watched correclty, the addresses used are constant, once the first range
is picked, like this:

base + 0x0000 + 0x0000 size 8
base + 0x0400 + 0x0000 size 8
...
base + 0x3c00 + 0x0000 size 8
base + 0x0000 + 0x4000 size 8
...
base + 0x3c00 + 0xc000 size 8

or, more easier:

bus_space_handle_t thespace[64];

for (i=0; i<64; i++) {
	rc = bus_space_map(iot, i*0x400, 8, &thespace[i]);
	if (rc)
		break;
}

- config in the config-file just for "base".
- in the probe/match routine, verify you can bus_space_map() all er.. 64
  resulting regions, if this fails, fail.
- else do additional probing/matching as appropriate, then free those 64
  regions.
- in the attach function:
  re-map the 64 spaces and pass them to the chip-level driver, possibly
  hiding the details of addressing from it by some macros.

Now, it might be useful to have convenience functions for sparse mapping... 
but...  it won't help for the internal handling of the addressing, as you
can mix 32 input bits to 16 output bits (assuming we need it ONLY for 
ISA i/o) in err... a lot of ways.

Regards,
	Ignatios