> On 12 Aug 1999, Jes Sorensen wrote:
> >
> > Having a readl_na() would make sense on big endian machines with PCI
> > busses since since some PCI cards (some gfx and network cards) will do
> > the translation for you in hardware making it look like the card is
> > native byte order. For 16 and 24 bit graphics for instance it is
> > absolutely not fun doing the byte swapping in software.
>
> But the point is _still_ that the driver needs to know. The driver needs
> to know which area to select, and in some cases the driver needs to put
> the card in the right endianness mode.
>
> In short, I have not heard a SINGLE argument for this being a generic
> feature. I _have_ heard tons of valid argument for fixing on a known
> byte-order, and I agree with them. And it's very obvious that little-
> endian is THE byteorder, nobody really even argues about that.
IMHO, the point where drivers want to do readl/writel (or similar
things like insl/outsl) without byte-swapping is where they are using
those things to transfer a buffer of bytes, just doing it four bytes
at a time (or 2 in the case of readw/writew/insw/outsw etc.) In that
case you don't want byte-swapping.
You do want byte-swapping on a big-endian platform where you are
accessing a quantity which is interpreted as a 32-bit (or 16-bit)
integer.
I think readl/writel are primarily defined for transferring 32-bit
quantities, and therefore should do byte-swapping on big-endian
platforms (as indeed they do at present).
For the cases where a driver wants to transfer 4 bytes from a buffer
of bytes, it would be *extremely* convenient to have readl_ns,
writel_ns, etc. variants which don't do the byte-swapping. It would
save a lot of #ifdefs in driver code. On a little-endian platform,
readl_ns == readl, etc., of course.
Can I send you a patch to add the *_ns variants?
Regards,
Paul.
-
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/