linux-kernel - Re: ioremap definition in generic io.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1285922150.2639.37.camel@needafix>
Date:	Fri, 01 Oct 2010 10:35:50 +0200
From:	Jonas Bonn <jonas@...thpole.se>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: ioremap definition in generic io.h

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/