On 2018-08-19 11:44, Maciej W. Rozycki wrote:
On Sun, 19 Aug 2018, Arnd Bergmann wrote:
> > My understanding for mmiowb() is that it should not be implied by
> > writel() itself but that it would be added between a writel() and a
> > spin_unlock(). Putting it into writel() itself would make it completely
> > pointless as an abstraction.
>
> This matches my understanding of mmiowb. In fact, mmiowb is a powerpc
> thing. All other architectures stub out.
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.
We need to define the problem clearly first and then decide on the
solution. And I think platform code must avoid abusing public internal
interfaces for purposes different from what those interfaces have been
invented for, even if the low-level implementation is the same across
some
(or all) of them.
E.g. many MIPS hardware implementations use the hardware SYNC
instruction
as the implementation for all of `mb', `rmb' and `wmb' interfaces, but
those still have to be used according to their purpose, even in
platform
code, and none is therefore *by definition* suitable for MMIO.
Existing
broken code is not an excuse -- broken cases have to be eventually
fixed
(the lack of resources for doing that is of course understandable) and
no
new ones added (no valid excuse here).
If an unusual platform-specific barrier is needed in platform code,
then
a different name has to be chosen at the interface level.
FWIW, here's the proposal I made and referred to in my previous
message:
<https://lkml.org/lkml/2014/4/28/201>. I may have some spare cycles in
the coming days, so I can have a look into wiring this stuff.
Maciej
