Linus> On 14 Aug 1999, Jes Sorensen wrote:
>> I think __writel() should expect little endian access as well, we
>> need both __writel() which doesn't do ordering _and_ writel_be()
>> since it will otherwise cause problems on big endian machines if
>> you want to write a portable device driver optimized with wmb()'s
>> in the right place if __writel() suddenly doesn't to byte swapping.
Linus> Why?
Linus> You can do byte-swapping by hand.
Linus> I think it is really _stupid_ to do a writel_be(), and quite
Linus> frankly, the moew people whine about it the less likely I'm
Linus> going to accept it. So far all the arguments have just been
Linus> _stupid_. They haven't had any reasoning.
Sorry I do not get your point here, you are saying that if one wants
to use __writel() then he/she will have to handle byte swapping on big
endian architectures manually? That means if I say write a Gigabit
Ethernet driver and I want to optimize it maximally then I am going to
use __writel() on the x86 and Alphas because those are the machines I
have access to. Now someone wants to use the driver to Linux/PPC and
suddenly all hell breaks lose because __writel() doesn't byteswap so
this person will have to modify the driver in order to make it run at
all.
Linus> If you just say that "__writel()" does the native byte order,
Linus> then you can do cpu_to_be32() and get exactly the semantics
Linus> that you seem to want. I don't understand WHY you'd want them,
Linus> but I can just tell you to do
Linus> __writel(cpu_to_be32(x),y)
Yes this will work, but it is going to make it impossible to use
__writel() for traditional PCI access as I described above unless I
define my own versions of writel in the driver to do
#define __l_writel(x,y) __writel(cpu_to_le32(x),y)
Linus> and it will be equivalent to your __writel_be(). I don't see
Linus> why anybody would ever use the above, as the only arguments for
Linus> the _be version so far have really been arguments for _native_
Linus> byte order on BE machines, but that's all the more reason to
Linus> not do something silly like export hundreds of slightly
Linus> different and useless versions of IO access.
If you read some of my previous postings then you'd remember that I
was arguing for a native byte order in the first place, you were the
one who brought the explicit big endian version into the discussion.
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/