On Sun, 19 Aug 2018, Arnd Bergmann wrote:
> On Sun, Aug 19, 2018 at 5:12 PM <okaya@xxxxxxxxxxxxxx> wrote:
> > On 2018-08-18 19:03, Arnd Bergmann wrote:
> > > On Sat, Aug 18, 2018 at 12:05 AM Maciej W. Rozycki
> > >
> > >> A while ago I proposed a set of different MMIO barriers, that some
> > >> systems may require, corresponding to the respective regular memory
> > >> barriers, but in the I/O context. I never got to implementing that
> > >> proposal, but I still think it's the right thing to do and will see if
> > >> I
> > >> can find some time to try doing that. Right now we have quite a mess
> > >> with
> > >> that. :(
> > >
> > > 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.
>
> Arnd
Alpha already has a memory barrier inside arch_spin_unlock.
BTW. I think that arch_spinlock_t (and atomic_t) on alpha should be
8-byte. See this case - writing the variable "x" performs
read-modify-write cycle on the spinlock, corrupting it.
struct s {
spinlock_t lock;
unsigned char x;
};
Mikulas
