Indeed. It's not the first time that would happen.
> 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)
Well, you could do that.
A well-written driver would not. A well-written driver will usually have
something like
#define read_device(dev,offset) \
readl((dev)->mapping+(offset))
#define write_device(dev,offset,data) \
__writel(cpu_to_le32(data), (dev)->mapping+(offset)
but admittedly rather few of them are right now.
> 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.
I was wrong.
But the whole discussion started as a _byte_ order discussion. And I still
do not agree with _any_ of those arguments. I will not call it
"writel_na()", because I still do not agree at all with the concept of
making the IO thing byte-order-dependent.
What you and others have convinced me about is to have a "raw" interface.
That is actually very different from what the original discussion was
about. It is not really about "native" byte order at all: in fact the
native IO byte order might be different from the native CPU byteorder, so
we might need to use "io_to_le32()" instead of "cpu_to_le32()".
So think of "__writel()" as something completely different than a
byte-order issue: think of it as a "raw access". The byte order it then
just a small subset of the bigger picture.
Just as an extreme example: __writel() might not just re-order and buffer,
maybe the native IO interface needs explicit flushing to make it out to
the bus _at_all_, and might be delayed indefinitely if there isn't an
eventual accompanying flush operation. You might want to allow caching of
IO accesses - and with a write-back cache it might not be flushed out to
the bus at all if the cache is big enough. Until somebody does a "flush
this region out to the bus NOW" operation.
Linus
-
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/