From: Mike Frysinger <vapier@gentoo.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
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>
Subject: Re: [PATCH 1/2] asm-generic: io: remove {read,write} string functions
Date: Fri, 27 Apr 2012 19:26:11 -0400 [thread overview]
Message-ID: <201204271926.14872.vapier@gentoo.org> (raw)
In-Reply-To: <201204272052.34489.arnd@arndb.de>
[-- Attachment #1: Type: Text/Plain, Size: 2310 bytes --]
On Friday 27 April 2012 16:52:34 Arnd Bergmann wrote:
> 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.
i'm ambivalent with keeping or tossing these funcs. Blackfin (afaik) picked
them up really only for the reasons Arnd cited -- drivers using memory mapped
registers originally for ARM (or m68k/coldfire i think) used this API, and it
was easier for us to implement these defines in our asm/io.h and get the
drivers "for free".
i am strongly in favor though of agreeing on & documenting the baseline API
first before attempting to clean anything up. sorry to keep harping on this.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-04-27 23:24 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
2012-04-27 23:26 ` Mike Frysinger [this message]
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=201204271926.14872.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=arnd@arndb.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=uclinux-dist-devel@blackfin.uclinux.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.