On Wed, 20 Feb 2019, Arnd Bergmann wrote: > I personally don't see a problem with having different barrier > semantics between outb() and iowrite8(), the reasoning being that > any caller of iowriteX() would already have to be careful about > posted writes when iowriteX is backed by ioremapped memory > space rather than port I/O. The problem is architectures (such as certainly MIPS) may imply posted writes for accesses that ultimately end up as port I/O (most architectures obviously have no real port I/O, and it all boils down to accessing an MMIO address range used to issue I/O access bus cycles to ISA or PCI), due to write buffering within the CPU itself. This has to be dealt with by explicits barrier instructions inserted in port-specific I/O accessors so that generic driver code has a consistent view regardless of the peculiarities of the underlying CPU architecture. > b) or the barriers are in fact needed for /any/ I/O operation > on alpha, to ensure that a store is ordered with regard to > a following load. If this is the case, we need the barriers > in all three families: outX(), writeX() and iowriteX(). I do believe Alpha is weakly ordered, at least architecturally, when it comes to any I/O (uncached) operations; I'll double-check with the architecture manual, as I recall the wording there was peculiar. NB I did a bunch of fixes for the MIPS port somewhat recently: 8b656253a7a4 MIPS: Provide actually relaxed MMIO accessors 3d474dacae72 MIPS: Enforce strong ordering for MMIO accessors a711d43cbbaa MIPS: Correct `mmiowb' barrier for `wbflush' platforms 4ae0452bddca MIPS: Define MMIO ordering barriers as it was similarly broken in this regard. Maciej
