On 19 January 2011 10:58, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tuesday 18 January 2011 23:22:23 Lars-Peter Clausen wrote: >> On 01/18/2011 10:37 PM, Arnd Bergmann wrote: >> > ... >> The lm32 architecture is a big-endian softcpu architecture. I'm currently working on >> the MilkyMist SoC which uses it and all the SoC components have native endianess. > > ok. I think this is the key concept that's being missed here: devices with _native_ endianess. This is something that I've been grappling with for the OpenRISC platform, as well. The ioread/write accessors are supposed to be a platform-agnostic interface and have a builtin assumption about the endianess of the device/bus. Device drivers that use ioread32 are explicity accessing a little-endian device; ioread32be explicitly a big-endian device. It's not really for the architecture to redefine these. The same applies to the readl/readw accessors as well, as far as I understand it. What's needed is another way of accessing device memory that doesn't carry the endianess implication. For the Wishbone bus, used by the OpenRISC processor, I still haven't found a more satisfactory solution than to define "wishbone accessors" that map to the underlying io-accessors of the desired endianess. These allow the endianess of the bus to be set at compile time and hopefully for all wishbone device drivers to do the right thing. #ifdef CONFIG_WISHBONE_BIG_ENDIAN #define wb_ioread8(p) ioread8(p) #define wb_ioread16(p) ioread16be(p) #define wb_ioread32(p) ioread32be(p) #define wb_iowrite8(p) iowrite8(p) #define wb_iowrite16(p) iowrite16be(p) #define wb_iowrite32(p) iowrite32be(p) #else #define wb_ioread8(p) ioread8(p) #define wb_ioread16(p) ioread16(p) #define wb_ioread32(p) ioread32(p) #define wb_iowrite8(p) iowrite8(p) #define wb_iowrite16(p) iowrite16(p) #define wb_iowrite32(p) iowrite32(p) #endif /* CONFIG_WISHBONE_BIG_ENDIAN */ That said, there are architectures that do redefine the endianess of the io-accessors to mean "native endianess", but this must have implications for a large number of the drivers in the kernel tree and, in my opinion, must be technically _incorrect_. A driver written with ioread32 shouldn't have the endianess of the access changed by the architecture underneath it... or are others of a different opinion? >> > >> > * change the common ioread*/iowrite* functions to all be based on >> > Â the __raw_* I/O versions, not just the big-endian ones. The >> > Â space overhead you quoted is enough of a justification for that. >> Doing this breaks the endianess assumption built into the io-accessors. /Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
