Re: ioremap definition in generic io.h

[Jonas Bonn]

Hi Arnd,

Thanks for the detailed explanation... it's started to make sense now.

> I assume that microblaze is a special case here because you synthesize
> the I/O devices together with the CPU core and choose a common endianess
> for both, right?

Yeah, that's exactly the case I'm looking at.  I'm actually working on
OpenRISC and not Microblaze, but that's just a detail!  The same issues
are applicable to both architectures.

> We have the __raw_readl()/__raw_writel() functions which are defined as
> host-endian, but I would not recommend using them in general because they
> also mean slightly different things depending on the architecture.

OK, I'm curious what you mean here... I would have thought that wrapping
our own functions around these would have been the right way to do
things.  What subtleties exist here that I would need to look out for?

> It's probably best to define your own functions for microblaze. Obviously
> the drivers are not portable to other architectures anyway because those
> might be cross-endian.
> 
> It's probably best to name the accessors by the bus that the devices
> are attached to, and then define them in a a per-bus header file, like
> 
> #ifdef CONFIG_PLB_BIG_ENDIAN
> #define plb_ioread32(p) ioread32be(p)
> #define plb_iowrite32(p) iowrite32be(p)
> #else
> #define plb_ioread32(p) ioread32(p)
> #define plb_iowrite32(p) iowrite32(p)
> #endif
> 

This seems like a reasonable approach.  What got me looking at all of
this was that I wanted to use asm-generic/io.h for our architecture, and
it's mostly OK except for the definition of ioremap which implies NOMMU.
Wouldn't it make sense to drop the ioremap definitions from this file,
thus allowing it to be used by archictectures with MMU?  Or do you know
of something more in this file which prohibits it from being used more
"generically"?

Thanks for your helpful feedback!
/Jonas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/