Re: [PATCH v2] gianfar: Add I/O barriers when touching buffer descriptor ownership.

[Segher Boessenkool <segher@kernel.crashing.org>]

>> Well, Segher doesn't want me to use iobarrier (because it's not I/O).
>> Andy doesn't want me to use wmb() (because it's sync).  I don't think
>> something like gfar_wmb() would be appropriate.  So the remaining
>> options are either eieio(),
>
> ? Just curious... the original intent of eieio was to order I/O,
> such as MMIO; it has no effect on memory that isn't marked
> cache-inhibited or write-trhough or guarded. Has this changed?

eieio orders all accesses to address space that is WIMG=1xxx
or WIMG=x1x1; separately, it orders stores to address space
that is WIMG=001x.

> I guess I haven't kept up with the times ... is eieio now
> being used to provide some other kind of barrier?

Nothing changed.

> Is eieio providing some sort of SMP synchronization side-effect?

It orders stores to "well-behaved" memory yes.

> Point being: if Segher doesn't let you "use iobarrier (because
> it's not I/O)", then I don't understand why eieio would work (since
> that's for io only).

iobarrier() is a kernel-level primitive, meant for ordering
I/O only, as its name indicates.  eieio is a CPU insn that
orders stores to main memory (amongst other things), not that
its name would tell you.


Segher