From: Arnd Bergmann <arnd@arndb.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Will Deacon <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"uclinux-dist-devel@blackfin.uclinux.org"
<uclinux-dist-devel@blackfin.uclinux.org>,
Mike Frysinger <vapier@gentoo.org>
Subject: Re: [PATCH 1/2] asm-generic: io: remove {read,write} string functions
Date: Fri, 27 Apr 2012 20:52:34 +0000 [thread overview]
Message-ID: <201204272052.34489.arnd@arndb.de> (raw)
In-Reply-To: <4F9ADD22.70003@zytor.com>
On Friday 27 April 2012, H. Peter Anvin wrote:
> On 04/27/2012 10:14 AM, Will Deacon wrote:
> >
> > If you remove the architecture-specific drivers, there's really not a lot left
> > and, even then, we only need to convert those drivers which are intended to
> > be portable between architectures where the string functions are not
> > consistently available.
> >
> > By overheads, I assume you're referring to the IO_COND check on the address
> > space? I wouldn't expect this to be noticeable compared to the cost of the
> > I/O access and I'm not sure it's worth worrying about for the sake of the
> > small number of drivers affected.
> >
>
> It's not in time, but it adds bulk to the code. The point is that what
> is the benefit of not making these part of the general API? For
> architectures where the address space doesn't matter they could just
> alias it to the same functions, or use the generic versions.
>
The main reasons I can see for not making it a general purpose API are:
* It's a very confusing interface, because the endianess rules are different
from the non-string variants and counterintuitive.
* Almost all the users are ancient ARM specific drivers, the others are
either new ARM specific drivers or drivers that started out as ARM-only
and were ported later to other architectures (sh, avr32, mips, mn10300
and blackfin)
* On all these architectures, the PCI I/O space is memory mapped (or
non-existent), so the ioread* functions are trivial wrappers without
additional overhead.
* Most architectures don't implement them today, but all architectures
that support MMIO also implement the ioread string operations.
Arnd
next prev parent reply other threads:[~2012-04-27 20:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 10:42 [PATCH 1/2] asm-generic: io: remove {read,write} string functions Will Deacon
2012-04-27 10:42 ` [PATCH 2/2] asm-generic: io: don't perform swab during {in,out} " Will Deacon
2012-04-27 12:12 ` Arnd Bergmann
2012-04-27 16:18 ` Mike Frysinger
2012-04-27 16:59 ` Will Deacon
2012-04-27 17:26 ` Mike Frysinger
2012-04-27 12:12 ` [PATCH 1/2] asm-generic: io: remove {read,write} " Arnd Bergmann
2012-04-27 16:17 ` Mike Frysinger
2012-04-27 16:53 ` Will Deacon
2012-04-27 17:18 ` Mike Frysinger
2012-04-28 8:46 ` Geert Uytterhoeven
2012-04-27 20:29 ` H. Peter Anvin
2012-04-27 16:23 ` H. Peter Anvin
2012-04-27 17:14 ` Will Deacon
2012-04-27 17:53 ` H. Peter Anvin
2012-04-27 20:52 ` Arnd Bergmann [this message]
2012-04-27 23:26 ` Mike Frysinger
2012-05-01 13:34 ` Will Deacon
2012-05-01 14:40 ` Arnd Bergmann
2012-05-01 18:28 ` Mike Frysinger
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=201204272052.34489.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=uclinux-dist-devel@blackfin.uclinux.org \
--cc=vapier@gentoo.org \
--cc=will.deacon@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.