public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.



  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