From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: akpm@osdl.org, Stephen Rothwell <sfr@canb.auug.org.au>,
ppc-dev <linuxppc-dev@ozlabs.org>,
netdev@vger.kernel.org, jgarzik@pobox.com
Subject: Re: [PATCH] Remove powerpc specific parts of 3c509 driver
Date: Wed, 20 Sep 2006 10:25:35 +1000 [thread overview]
Message-ID: <1158711935.6002.226.camel@localhost.localdomain> (raw)
In-Reply-To: <488875E7-CCBC-47E1-A273-A2D037A997B2@kernel.crashing.org>
On Wed, 2006-09-20 at 02:21 +0200, Segher Boessenkool wrote:
> > Nah. We have the basic rule that readl/writel are little endian.
> > PowerPC
> > additionally provides arch specific low level in_{be,le}32 type
> > accessors with explicit endianness. Or you can also use
> > cpu_to_le32/le32_to_cpu kind of macros to convert between native and
> > explicit endianness.
>
> Sure, PCI busses are little-endian. But is readX()/writeX() for PCI
> only? I sure hope not.
It's defined for PCI and possibly ISA memory. You can use it for other
things if you whish to, but "other things" are arch specific in any
case.
> It would make a lot more sense if readX()/writeX() used the endianness
> of the bus they are performed on.
No way ! Again, it's evil if such a simple thing start doing different
things depending on random external factors.
Different bus -> different accessor.
We defined on PowerPC that readl was fine for anything that comes out of
ioremap and is little endian, but that's also why you have the explicit
{in,out}_{le,be}{16,32}. That's what you should use in fact with non-PCI
busses unless you know you are LE.
> PowerPC byteswaps are cheap -- for 16- and 32-bit accesses. They're quite bad for 64-bit though; it would
> be a pity to end up doing two of those for a 64-bit big-endian I/O
> access
> (one on the access itself, one to convert the data back to CPU order).
>
> This would happily solve the problem of the various variations of
> byte-swapping bus bridges, too ("natural" swap, 32-bit swap, 64-bit
> swap,
> perhaps others that I thankfully have never seen or cannot remember).
>
> Now you can say, use readl_be() or something similar, but that's a)
> ugly,
> b) error-prone, c) exponential interface explosion, d) ugly.
I'd rather has an interface explosion than having black endian magic
happening inside of the accessors.
Ben.
next prev parent reply other threads:[~2006-09-20 0:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-19 4:54 Fw: [PATCH] Remove powerpc specific parts of 3c509 driver Stephen Rothwell
2006-09-19 18:42 ` Linas Vepstas
2006-09-19 18:52 ` Matt Sealey
2006-09-19 19:44 ` Linas Vepstas
2006-09-19 23:24 ` Benjamin Herrenschmidt
2006-09-20 0:21 ` Segher Boessenkool
2006-09-20 0:25 ` Benjamin Herrenschmidt [this message]
2006-09-20 0:58 ` Segher Boessenkool
2006-09-20 1:17 ` Linas Vepstas
2006-09-20 1:41 ` Segher Boessenkool
2006-09-20 0:57 ` Jeff Garzik
2006-09-20 1:08 ` Segher Boessenkool
2006-09-20 1:18 ` Jeff Garzik
2006-09-20 20:06 ` Segher Boessenkool
2006-09-20 21:29 ` Jeff Garzik
2006-09-19 23:18 ` Fw: " Benjamin Herrenschmidt
2006-09-19 23:27 ` Paul Mackerras
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=1158711935.6002.226.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=jgarzik@pobox.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=segher@kernel.crashing.org \
--cc=sfr@canb.auug.org.au \
/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;
as well as URLs for NNTP newsgroup(s).