[PATCH] ARM: io: avoid writeback addressing modes for __raw_ accessors

Arnd Bergmann arnd at arndb.de
Tue Aug 21 06:11:40 EDT 2012


On Tuesday 21 August 2012, Will Deacon wrote:
> On Mon, Aug 20, 2012 at 07:45:20PM +0100, Nicolas Pitre wrote:
> > On Mon, 20 Aug 2012, Will Deacon wrote:
> > > On Mon, Aug 20, 2012 at 07:04:01PM +0100, Nicolas Pitre wrote:
> > > > Nah... the const is wrong.  The way you wrote it means that addr may 
> > > > change but the pointed data is constant.  This is obviously wrong since 
> > > > we expect the pointed location to change even from a read.
> > > 
> > > That's the prototype for the read accessors though -- a bunch of other
> > > architectures define them that way (including asm-generic), so I wonder what
> > > the reasoning behind that was?
> > 
> > I'm still asserting that they're wrong.
> 
> I did a bit of digging around and `const volatile void *' is apparently used
> because a function with such a parameter type can be passed any old pointer
> without warnings. Torvalds says something about them here:
> 
>   http://readlist.com/lists/vger.kernel.org/linux-kernel/14/72300.html
> 
> Personally, I too think that the const is misleading and who on Earth would
> be passing in pointers to const for an I/O region? However, it's an argument
> I'd rather avoid so, for the sake of consistency, I'll cast away the const in
> the asm block.
> 

You could have a read-only register area, and I would regard it as sensible
to mark a pointer to it as "const", although there should not be any
optimizations based on that.

There is no need to cast away the constness of the pointer when passing
it into the inline assembly, as the "asm volatile" already implies that
gcc cannot remove the contents.

On a related topic, thank you very much for introducing the inline
assemblies here, as they finally solve a lingering problem that has
hit us in the past [1] and that could happen again in other drivers.

	Arnd

[1] http://old.nabble.com/ARM-unaligned-MMIO-access-with-attribute%28%28packed%29%29-td30827280.html



More information about the linux-arm-kernel mailing list