On Sun, 19 Aug 2018, okaya@xxxxxxxxxxxxxx wrote: > >> There are a few architectures that define mmiowb to something other > >> than a nop: some ia64, some mips and sh in particular, plus also the > >> new riscv. > >> > >> It does make some sense that alpha might need a barrier between > >> an mmio store and a spin_unlock, but it was decided earlier to make > >> that barrier implied by the writel() function rather than require an > >> explicit mmiowb after it. > > > > A completion barrier then? In the MIPS port this has been `iob', another > > local invention. Other ports may or may not have an equivalent. > > I am not sure. Linus pushed back several times that code needs to be x86 > compatible. We can't introduce a new api to make weakly ordered architectures > happy. Both Documentation/io_ordering.txt and Documentation/memory-barriers.txt (in `KERNEL I/O BARRIER EFFECTS' and also `ASSUMED MINIMUM EXECUTION ORDERING MODEL') imply that weakly-ordered MMIO semantics is actually supported, and that memory accesses issued by `writeX' accessors are allowed to be reordered by hardware (or presumably merged or cancelled if accessing adjacent or overlapping locations; there's MIPS hardware in existence that does exactly that). That is that the caller must not assume that writes issued by `writeX' calls will be observed in order on the external bus or specifically by the device addressed. There's also an implication there (in Documentation/io_ordering.txt) that `readX' accessors act as completion barriers, which may be a bit heavyweight on platforms where reads can bypass writes entirely or snoop outstanding writes (again various MIPS hardware does that), but does require that such platforms have an MMIO r/w barrier defined and used within `readX' functions regardless of whether these platforms also need to have an MMIO write barrier defined or not. Many platforms would have an MMIO r/w barrier defined as an empty operation I suppose. Platforms can then have lightweight accessors defined without any ordering implications for use with their internal stuff if nothing else. In any case I fail to see x86 strong MMIO ordering semantics being required for platforms across public internal interfaces already defined, and I think there would be a benefit from having MMIO barriers named uniformly across ports. The matter of bus access ordering (whether memory or MMIO) seems already quite difficult for people to understand and having different names across ports doesn't make it any easier. FWIW, Maciej
