Re: New resources - pls, explain :-(

Mitchell Blank Jr (mitch@sfgoth.com)
Fri, 13 Aug 1999 02:21:23 -0700


Linus Torvalds wrote:
> But the point is _still_ that the driver needs to know.

Definately

> The the drivers that know about the issue might
> do something like this:
[...]
> #ifdef BIG_ENDIAN
> #define gfx_readl(x) bigendian_readl(x)
> #define gfx_writel(x,y) bigendian_writel(x,y)
> #else
> #define gfx_readl(x) readl(x)
> #define gfx_writel(x,y) writel(x,y)
> #endif

Yes, but if you are going to need that boilerplate in every such driver
why not just put it in one place? Then your API is just:
readl_le(), writel_le() /* Little endian */
readl_be(), writel_be() /* Big endian */
readl_ne(), writel_ne() /* Native endian */
readl(), writel() /* aliased to *_le() for comaptibility */

The asm/io.h would only #define either the _le() or _be() variant as
appropriate for that arch (or maybe both if the CPU provides a fast
byte-swapped bus i/o), and then #include's <linux/endianio.h> which
would be:

#include <asm/byteorder.h>
#ifdef BIG_ENDIAN
#ifndef readl_le
#define readl_le(x) __arch__swab32(readl_be(x))
#endif
#ifndef writel_le
#define writel_le(x,y) writel_be(__arch__swab32(x),y)
#endif
#define readl_ne(x) readl_be(x)
#define writel_ne(x,y) writel_be(x,y)
#else /* !BIG_ENDIAN */
#ifndef readl_be
#define readl_be(x) __arch__swab32(readl_le(x))
#endif
#ifndef writel_be
#define writel_be(x,y) writel_le(__arch__swab32(x),y)
#endif
#define readl_ne(x) readl_le(x)
#define writel_ne(x,y) writel_le(x,y)
#endif /* BIG_ENDIAN */
#define readl(x) readl_le(x)
#define writel(x,y) writel_le(x,y)

Simple, easy, consistant, and complete. All that's left to do is fix
drivers that depend on readl being readl_ne() instead of readl_le().

> But note how it would NOT really have made any sense to have a "generic"
> don't-swap, because that is not a generic problem.

It's generic in the sense that its shared between a bunch of drivers.

-Mitch

-
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/