This time, I'm *sure* it doesn't have an obvious answer.  I think.

Having unearthed a copy of the ProAudio Spectrum SDK, I have stumbled
across some interesting questions raised by its use of ISA I/O space.

The PAS card is documented as normally occupying 0x388 through 0x38B
in I/O space, a mere four I/O ports.  But they mention that it also
uses I/O ports that "normally" decode to the same I/O locations,
i.e. 788-78B, 1388-138B, 1f88-1f8B, etc.  (And the PAS2 card
elaborates that to a noxious degree, using all the way up to 0xFF88.)
And sure enough, when I checked "The Undocumented PC", I learn that
"motherboards and many adapter cards do not decode I/O address lines
A10 and above", meaning there are really only 1024 unique ISA bus I/O
ports.  (Actually less, since many motherboards do not fully decode
port numbers in the on-board port range.)

EISA fully decodes the addresses, but still assumes that user cards in
the 0x100 through 0x3FF region backslide (thus appearing at 0500-07FF,
0900-0BFF, 0D00-0FFF); plus there's the fact that the high order
nybble of the address is reserved for the bus slot number (so slot 1
has addresses 0x1XXX, of which 0x1100 through 0x13FF is taken out as
yet another duplicate of 0100 through 03FF).

So I have a practical question and a theoretical question.

The practical question:  it appears that, at least on the i386 port,
if I call bus_space_map to reserve 4 I/O ports starting at 0x388, I
could fearlessly address I/O port 0xF789 with an offset of 0xF401
because (a) there's no bounds checking in the implementation of
bus_space_XXX_1(), and (b) the ISA bus guarantees that the card I
address will be the correct one.  However, I assume that I should not
do that, because on some other CPU architectures victimized by the ISA
bus, that map call may actually establish a memory mapping which
potentially will have bounds checking.  So am I correct in believing
that I should map individual chunks for each duplicate of interest?
(I'll need about 18, are bus mappings likely to be scarce?)

The theoretical question:  the bus_space_map functionality, at least
on the i386 port, does not really match the underlying hardware.  On
an ISA or EISA bus, if a card uses 0x388 through 0x38B, it also uses
all the other duplicates of that range, and no other driver should be
able to map the mirrored ports; of course, that means that *my* driver
would (at best) have to stand on its head to map those ports as well.

And what's the story with PCI?  I hope that PCI demands that cards
fully decode I/O port addresses, but how are mixed ISA/PCI systems
handled?  Does the ISA bus attach through the PCI bridge, and if so,
does the PCI bridge pass all I/O ports unfiltered through to the ISA
(thus implicitly mirroring I/O ports on the PCI bus), or is it
necessary to specifically tell the PCI bridge to pass through I/O
ports to the ISA?  (I don't see any hint of that kind of configuration
code in the kernel sources, so I assume it's most likely the former,
though the BIOS might set up the latter?)  (Or maybe PCI only passes
through 0x000 through 0x3FF to the ISA bus, which would avoid
mirroring issues but break cards which abused the addressing scheme.)

I hate hardware engineers.