mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: olof@lixom.net (Olof Johansson)
To: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
	linux-pcmcia@lists.infradead.org, akpm@osdl.org,
	paulus@samba.org
Subject: Re: [PATCH] pcmcia: ppc64 needs 32-bit ioaddr_t
Date: Sun, 24 Jun 2007 21:42:52 -0500	[thread overview]
Message-ID: <20070625024252.GA31653@lixom.net> (raw)
In-Reply-To: <200706250335.56739.arnd@arndb.de>

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

  reply	other threads:[~2007-06-25  2:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-25  0:54 Olof Johansson
2007-06-25  1:35 ` Arnd Bergmann
2007-06-25  2:42   ` Olof Johansson [this message]
2007-06-25  5:53 ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070625024252.GA31653@lixom.net \
    --to=olof@lixom.net \
    --cc=akpm@osdl.org \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pcmcia@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®