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

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

[Olof Johansson]

Make ioport_map() handle already mapped port range without trying
to add _IO_BASE to them.


Signed-off-by: Olof Johansson <olof@lixom.net>

Index: 2.6.21/arch/powerpc/kernel/iomap.c
===================================================================
--- 2.6.21.orig/arch/powerpc/kernel/iomap.c
+++ 2.6.21/arch/powerpc/kernel/iomap.c
@@ -106,7 +106,13 @@ EXPORT_SYMBOL(iowrite32_rep);
 
 void __iomem *ioport_map(unsigned long port, unsigned int len)
 {
-	return (void __iomem *) (port + _IO_BASE);
+	/* Do nothing if we're being asked to map an already
+	 * ioremapped() address
+	 */
+	if (port >= IMALLOC_BASE && (port+len) < IMALLOC_END)
+		return (void __iomem *) port;
+	else
+		return (void __iomem *) (port + _IO_BASE);
 }
 
 void ioport_unmap(void __iomem *addr)

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

[Arnd Bergmann]

On Saturday 12 May 2007, Olof Johansson wrote:
> Make ioport_map() handle already mapped port range without trying
> to add _IO_BASE to them.
>=20
>=20
> Signed-off-by: Olof Johansson <olof@lixom.net>
>=20
> Index: 2.6.21/arch/powerpc/kernel/iomap.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- 2.6.21.orig/arch/powerpc/kernel/iomap.c
> +++ 2.6.21/arch/powerpc/kernel/iomap.c
> @@ -106,7 +106,13 @@ EXPORT_SYMBOL(iowrite32_rep);
> =A0
> =A0void __iomem *ioport_map(unsigned long port, unsigned int len)
> =A0{
> -=A0=A0=A0=A0=A0=A0=A0return (void __iomem *) (port + _IO_BASE);
> +=A0=A0=A0=A0=A0=A0=A0/* Do nothing if we're being asked to map an already
> +=A0=A0=A0=A0=A0=A0=A0 * ioremapped() address
> +=A0=A0=A0=A0=A0=A0=A0 */
> +=A0=A0=A0=A0=A0=A0=A0if (port >=3D IMALLOC_BASE && (port+len) < IMALLOC_=
END)
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return (void __iomem *) por=
t;
> +=A0=A0=A0=A0=A0=A0=A0else
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return (void __iomem *) (po=
rt + _IO_BASE);
> =A0}

This patch looks wrong to me, it's an indication that either a driver
is confusing ioport and __iomem addresses, or that something went
wrong during the initialization of the primary PCI bus.

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=3D10840 .

	Arnd <><

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

[Olof Johansson]

On Sun, May 13, 2007 at 12:18:42AM +0200, Arnd Bergmann wrote:
> On Saturday 12 May 2007, Olof Johansson wrote:
> > Make ioport_map() handle already mapped port range without trying
> > to add _IO_BASE to them.
> > 
> > 
> > Signed-off-by: Olof Johansson <olof@lixom.net>
> > 
> > Index: 2.6.21/arch/powerpc/kernel/iomap.c
> > ===================================================================
> > --- 2.6.21.orig/arch/powerpc/kernel/iomap.c
> > +++ 2.6.21/arch/powerpc/kernel/iomap.c
> > @@ -106,7 +106,13 @@ EXPORT_SYMBOL(iowrite32_rep);
> > ?
> > ?void __iomem *ioport_map(unsigned long port, unsigned int len)
> > ?{
> > -???????return (void __iomem *) (port + _IO_BASE);
> > +???????/* Do nothing if we're being asked to map an already
> > +??????? * ioremapped() address
> > +??????? */
> > +???????if (port >= IMALLOC_BASE && (port+len) < IMALLOC_END)
> > +???????????????return (void __iomem *) port;
> > +???????else
> > +???????????????return (void __iomem *) (port + _IO_BASE);
> > ?}
> 
> This patch looks wrong to me, it's an indication that either a driver
> is confusing ioport and __iomem addresses, or that something went
> wrong during the initialization of the primary PCI bus.

It's not for PCI. See discussion in:

http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035744.html

> 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...


-Olof

Re: [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 <><

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

[Benjamin Herrenschmidt]

> 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:

The solution is to use proper allocators for these.

As you pointed out on irc, it seems like the current __get_vm_area()
could match our needs. It might allow us to also get rid of imalloc.

I'll give that a go tomorrow.

Ben.