[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: New resources - pls, explain :-(

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.


You can do byte-swapping by hand.

I think it is really _stupid_ to do a writel_be(), and quite frankly, the
moew people whine about it the less likely I'm going to accept it. So far
all the arguments have just been _stupid_. They haven't had any reasoning.

> In fact we will need at least:
> writel() - ordered, little endian
> __writel() - non ordered (and possibly other things) - little endian
> writel_be() - like writel() but big endian
> __writel_be() - non ordered - big endian

IN FACT we would be extremely stupid if we were to do the above. Why
export four interfaces when two would do?

Why do you continue to think that endianness is an issue? You have
perfectly fine macros to handle endianness already, why mix that in with
the IO part?

If you just say that "__writel()" does the native byte order, then you can
do cpu_to_be32() and get exactly the semantics that you seem to want. I
don't understand WHY you'd want them, but I can just tell you to do


and it will be equivalent to your __writel_be(). I don't see why anybody
would ever use the above, as the only arguments for the _be version so far
have really been arguments for _native_ byte order on BE machines, but
that's all the more reason to not do something silly like export hundreds
of slightly different and useless versions of IO access.

The UNIX philosophy is do ONE thing, and do it well. Don't mix up
endianness and IO. We have perfectly functional endianness functions, so
why would be try to make the IO functions do that too?

We'll need to do a "io_[wr]mb()" macro too - because plain "mb()" is
conceptually very different from the issue of serialized IO. But then you
could conceptually think of

static inline void writel(u32 x, u32 addr)
__writel(cpu_to_le32(x), addr);

(even though on the x86, for example, the two would just be exactly the
same thing).

Don't make this more complicated than it needs to be. We do _not_ need
four different macros.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.122 / U:28.364 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site