[PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t

[PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t

[Olof Johansson]

ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
MMIO addresses, and remapped at an offset that's well above 16 bits in
some cases.

While the type is exported to userspace, there hasn't been any platforms
with PCMCIA on 64-bit powerpc until now, so changing it won't regress
any existing users.


Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Paul Mackerras <paulus@samba.org>

Index: 2.6.21/include/pcmcia/cs_types.h
===================================================================
--- 2.6.21.orig/include/pcmcia/cs_types.h
+++ 2.6.21/include/pcmcia/cs_types.h
@@ -21,7 +21,7 @@
 #include <sys/types.h>
 #endif
 
-#if defined(__arm__) || defined(__mips__)
+#if defined(__arm__) || defined(__mips__) || defined(__powerpc64__)
 /* This (ioaddr_t) is exposed to userspace & hence cannot be changed. */
 typedef u_int   ioaddr_t;
 #else

Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t

[Arnd Bergmann]

On Monday 25 June 2007, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
> 
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> any existing users.

I just realized that this argument is bogus, because the user space tools
are probably, or at least potentially, built as 32 bit binaries, which
means that any interface using these _will_ break.

However, I could not find any actual user space interfaces in 2.6.22-rc
that are built around ioaddr_t. What are they, or have the been removed
by now?

	Arnd <><

Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t

[Olof Johansson]

On Mon, Jun 25, 2007 at 03:35:56AM +0200, Arnd Bergmann wrote:
> On Monday 25 June 2007, Olof Johansson wrote:
> > ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> > MMIO addresses, and remapped at an offset that's well above 16 bits in
> > some cases.
> > 
> > While the type is exported to userspace, there hasn't been any platforms
> > with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> > any existing users.
> 
> I just realized that this argument is bogus, because the user space tools
> are probably, or at least potentially, built as 32 bit binaries, which
> means that any interface using these _will_ break.

Fortunately, on the userspace ABI, it should just be the cardmgr
ioctls that are affected. In this case there are no current 64-bit PPC
platforms with PCMCIA, so there are no existing users to regress. New
users (with 32-bit userspace) shouldn't be using the cardmgr tools.

So yes, someone who takes an old 32-bit userspace with cardmgr, moves
it to a new 64-bit platform and expects the old 32-bit tools to work
will find that they don't. Not that they would have otherwise either.

> However, I could not find any actual user space interfaces in 2.6.22-rc
> that are built around ioaddr_t. What are they, or have the been removed
> by now?

Last time I posted this I got the answer from Christoph that it's cardmgr
and the ioctl interface it uses, and there's still users out there that
have been neglecting the error messages, etc.

Unfortunately, ioaddr_t is used both in the ioctl interface as well as
to pass around some of the same structures within the kernel. So I could
either do major overhaul of the PCMCIA stack, or change this type for
ppc64. I went for the latter given that MIPS and ARM obviously already
got away with doing it.


-Olof

Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t

[Christoph Hellwig]

On Sun, Jun 24, 2007 at 07:54:39PM -0500, Olof Johansson wrote:
> ppc64 really needs ioaddr_t to be 32-bit, since I/O addresses really are
> MMIO addresses, and remapped at an offset that's well above 16 bits in
> some cases.
> 
> While the type is exported to userspace, there hasn't been any platforms
> with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> any existing users.

Drivers should be using kio_addr_t, please fix up the remaining drivers
to do this instead of chaning the user-visible type.