RFC on writel and writel_relaxed

[Will Deacon]

On Tue, Mar 27, 2018 at 11:44:22AM +0200, Arnd Bergmann wrote:
> On Tue, Mar 27, 2018 at 10:56 AM, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
> > On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote:
> >> On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe <jgg at ziepe.ca> wrote:
> >>
> >> I'm pretty sure I've never seen
> >> any bug reports pointing to a missing wmb() between memory
> >> and MMIO write accesses, but if you remember seeing them in the
> >> list, maybe you can look again for some evidence of something going
> >> wrong on x86 without it?
> >
> > The interesting thing is that we do seem to have a whole LOT of these
> > spurrious wmb before writel all over the tree, I suspect because of
> > that incorrect recommendation in memory-barriers.txt.
> >
> > We should fix that.
> 
> Maybe the problem is just that it's so counter-intuitive that we don't
> need that barrier in Linux, when the hardware does need one on some
> architectures.
> 
> How about we define a barrier type instruction specifically for this
> purpose, something like wmb_before_mmio() and have all architectures
> define that to an empty macro?
> 
> That way, having correct code using wmb_before_mmio() will not
> trigger an incorrect review comment that leads to extra wmb(). ;-)

Please don't add more barriers :)! I think that will make it even more
difficult to understand how to use the ones we already have -- the problem
here seems to be that the documentation that was added for the dma_*
barriers got this wrong, but it was at least in contradiction with the
section elsewhere in memory-barriers.txt that describes the relaxed I/O
accessors.

I guess somebody could hack checkpatch to look for back-to-back wmb/writel
sequences? I suspect we could do something with coccinelle too.

Will