From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Matt Sealey <matt@genesi-usa.com>
Cc: akpm@osdl.org, Stephen Rothwell <sfr@canb.auug.org.au>,
jgarzik@pobox.com, ppc-dev <linuxppc-dev@ozlabs.org>,
netdev@vger.kernel.org
Subject: Re: Fw: [PATCH] Remove powerpc specific parts of 3c509 driver
Date: Wed, 20 Sep 2006 09:24:29 +1000 [thread overview]
Message-ID: <1158708269.6002.186.camel@localhost.localdomain> (raw)
In-Reply-To: <45103C62.4080003@genesi-usa.com>
On Tue, 2006-09-19 at 20:52 +0200, Matt Sealey wrote:
> Some northbridges and PCI bridges have "clever" byteswapping in
> hardware, maybe this is just an effect of that. In theory depending on
> the host bridge, you should pass in big endian data and have it swap or
> not swap, not pick that way in the driver, UNLESS your driver expects
> bigendian data, in which case on a bigendian platform you can tell it to
> write without swapping. Voila, two functions.
It's generally considered pretty bad for a northbridge to try to muck
around with byte order. There are fairly well defined rules to plug a
little endian bus (PCI, ISA, ...) on a big endian machine.
The trick that some people didn't get a while ago is that while
accessors like inw/inl shall return a byteswapped data, string
operations like in insw/insl who are copying from a fifo basically to
memory (and opposite write versions) shall -not- byteswap since the data
isn't interpreted. it's a byte stream. It doesn't have any endian
semantic associated to it until it's actually read back from memory in
which case the appropriate endian swap (if any) has to be used depending
on the endianness and size of a given field read/written.
Since some people didn't get it, in the early days, some BE
architectures like ppc had versions of insw/insl that did byteswap,
which was wrong. The bits in this driver are remains from that era.
Note that to aggravate the problem, it still happens that HW engineers
try to be "smart" when hooking a 16 bits or 32 bits FIFO to a BE machine
and byteswap it in hardware. This is of course totally bogus but did
happen with IDE controllers typically (I think atari or amiga has one of
these, the Tivo is like that too, and a bunch of embedded things). The
net result is that you have to pump the data fifo using a byteswapping
accessor and you cannot use DMA unless you DMA controller can re-swap
the other way around.... But lots of HW people still don't get it :)
> However the existance of these PCI bridges these days? I haven't seen
> one in years, and when I have nobody has ever enabled the magic swappy
> thing as it's unreliable and can't always tell how you present the data.
>
> One wishes that there was a ntoh and hton style macro in standard use
> for PCI access.. hang on though that jsut wouldn't work would it.
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.
Ben.
next prev parent reply other threads:[~2006-09-19 23:25 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 [this message]
2006-09-20 0:21 ` Segher Boessenkool
2006-09-20 0:25 ` Benjamin Herrenschmidt
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=1158708269.6002.186.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=jgarzik@pobox.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=matt@genesi-usa.com \
--cc=netdev@vger.kernel.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).