Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Wednesday 01 October 2014 17:23:58 Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 11:50:13AM +0200, Arnd Bergmann wrote:
> > On Monday 29 September 2014 10:23:25 Thierry Reding wrote:
> > > 
> > > How about if I keep iterating this series? It seems like most failures
> > > can be reproduced by doing ARM defconfig and allmodconfig builds, so
> > > I'll do those and fix up any issues I find. Hopefully I can squash all
> > > these before 3.18-rc1, then we can take it into linux-next early for
> > > 3.19? In the meantime perhaps I can work with Olof to get a branch with
> > > these patches tested on his builder? And perhaps on the 0-day builder in
> > > addition?
> > 
> > Yes, definitely!
> > 
> > Note that I saw a lot of problems only in randconfig build tests but
> > not in any of the default configurations. I'll send you the fixup patch
> > soon so you can integrate that in your series.
> 
> One of the things I've seen a lot is warnings about volatile being
> ignored. This is caused by my latest series dropping the volatile
> keyword for the I/O accessors. The rationale being that use of volatile
> should be an implementation detail of the accessors rather than the
> function signature.

The reason those accessors have the volatile keyword in the argument
list is purely to silence the compiler when a driver passes a variable
that is marked volatile.

> Given the massive amount of changes needed to remove these warnings, is
> it better to just keep the volatile keyword even if it's clearly wrong
> in the context of the I/O accessors? Or should we bite the bullet and
> remove all the wrong uses while at it?
> 
> I suppose if we decide to remove them we can always make that a separate
> patch series.

Right, let's not do that now. We could put it on the kernel janitor wiki
as a task for newbies though.

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