Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors | Date | Wed, 01 Oct 2014 20:34:43 +0200 |
| |
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
| |