From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Jeff Garzik <jgarzik@pobox.com>, Andrew Morton <akpm@osdl.org>,
"David S. Miller" <davem@davemloft.net>,
Paul Mackerras <paulus@samba.org>
Subject: Re: lib/iomap.c mmio_{in,out}s* vs. __raw_* accessors
Date: Sun, 05 Nov 2006 15:38:57 +1100 [thread overview]
Message-ID: <1162701537.28571.156.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0611042013400.25218@g5.osdl.org>
> The _only_ reason to use "ioread32be()" would be because the machine is
> actually natively BE, and you want to avoid swab. That's kind of the point
> of using "be32_to_cpu(__raw_readl(addr)))" like we do now - it will do the
> byte swap only if it's necessary.
>
> In contrast, your "swab(readl())" does _two_ byteswaps - once to turn it
> into LE, then to turn it back into BE.
I'm not doing a swab(readl()), I'm doing a swab(insl()) and have the
arch provide a native BE accessor for readl_be(). The idea is that I
don't want to add _be accessors for PIO and PIO is slow anyway. But I'm
providing one for MMIO, along with the repeat versions. Have a second
look.
> So if we can't just rip it out, then we sure as hell shouldn't replace it
> with something that is obviously worse either.
>
> In other words - I don't see the reasoning here again. You seem to want to
> make the code just worse.
Wait, let's make thing clear, there are 2 things here:
- MMIO : For that, I'm providing readw_be etc... which my patch defines
based on __raw_* just as your suggest, I'm just adding a way for the
arch to provide its own.
- PIO : This is broken -now-. The current code doesn't swap at all in
the PIO case, thus you get LE result when using ioread32be() on PIO. I
propose to fix that with swab() because PIO sucks already, there is no
"__raw" for PIO and it doesn't deserve new accessors nor speed.
Cheers,
Ben.
next prev parent reply other threads:[~2006-11-05 4:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-04 7:52 lib/iomap.c mmio_{in,out}s* vs. __raw_* accessors Benjamin Herrenschmidt
2006-11-04 14:06 ` Russell King
2006-11-04 22:17 ` Benjamin Herrenschmidt
2006-11-04 23:52 ` Linus Torvalds
2006-11-05 1:10 ` Benjamin Herrenschmidt
2006-11-05 3:32 ` Benjamin Herrenschmidt
2006-11-05 3:46 ` Linus Torvalds
2006-11-05 3:55 ` Benjamin Herrenschmidt
2006-11-05 4:00 ` Benjamin Herrenschmidt
2006-11-05 4:16 ` Linus Torvalds
2006-11-05 4:38 ` Benjamin Herrenschmidt [this message]
2006-11-05 5:00 ` Linus Torvalds
2006-11-05 5:08 ` Benjamin Herrenschmidt
2006-11-05 5:28 ` Benjamin Herrenschmidt
2006-11-06 2:56 ` Benjamin Herrenschmidt
2006-11-06 3:13 ` Linus Torvalds
2006-11-06 4:50 ` Benjamin Herrenschmidt
2006-11-05 3:34 ` Linus Torvalds
2006-11-05 3:49 ` Benjamin Herrenschmidt
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=1162701537.28571.156.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=torvalds@osdl.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