Messages in this thread | | | Subject | Re: New resources - pls, explain :-( | From | Jes Sorensen <> | Date | 15 Aug 1999 12:20:33 +0200 |
| |
>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
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/
| |