[PATCH] powerpc: make ioport_map() handle already mapped ranges

[Arnd Bergmann]

On Sunday 13 May 2007, Olof Johansson wrote:
> > We have a bug on cell that would be fixed with this patch, so it
> > might be the same problem, see the patch that I suggested for
> > this at http://patchwork.ozlabs.org/linuxppc/patch?id=10840 .
> 
> Not in this case, but thanks for the pointer. Your case is still based
> on the fact that you only have one io space range, you're just making
> sure you're allocating out of that range. In my case, I have two distinct
> ranges, they're even on different busses...

There is a global io space range for all buses, which is maintained
by the reserve_phb_iospace() call. You should get your I/O ports in there
if you want them to just work. Note that while the reserve_phb_iospace() 
logic works in practice, it does have a few shortcomings that should
eventually be resolved:

* There is no way to free these ranges, so you can't use this mechanism
to allocate space for hotpluggable buses, or you might run out of
space eventually

* there is no locking around the use of reserve_phb_iospace().

* Buses that are already hotplugged get an io port range above the
range maintained by reserve_phb_iospace(), but that may be larger
than 4GB, so that I/O port numbers allocated on thoses buses require
64 bit integers to store them.

* If you have registered primary PCI bus, the whole logic breaks down
and you always need 64 bit integers to store I/O port numbers, at best.

* Worse things happen if you try to use pci_iomap, which checks
PIO_MASK. This mask is currently defined for 30 bit addresses, while
the range managed by reserve_phb_iospace() is already 31 bits, not
to mention ports outside of that range.

* If you call reserve_phb_iospace() for a secondary bus before
 setting pci_io_base to the primary bus, you actually get negative
I/O port numbers, and you crash when using a 32  bit number to store
it.
	Arnd <><