Thread (32 messages) flat view 32 messages, 5 authors, 2011-10-10

RE: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2011-10-10 08:53:49
Also in: netdev

On Mon, 2011-10-10 at 09:40 +0100, David Laight wrote:
quoted
What is this __iowrite64_copy... oh I see

Nice, somebody _AGAIN_ added a bunch of "generic" IO 
accessors that are utterly wrong on all archs except
x86 (ok, -almost-).
There isn't a single bloody memory barrier in there !
Actually memory barriers shouldn't really be added to
any of these 'accessor' functions.
(Or, at least, ones without barriers should be provided.)
As long as they are documented to provide no guarantee of ordering
between the stores... And x86 driver writers have any clue that they
will not be ordered vs. surrounding accesses.
The driver may want to to a series of writes, then a
single barrier, before a final write of a command (etc).

in_le32() from io.h is specially horrid!
The reason for that is that drivers expect fully ordered writel() vs
everything (including DMA).

Unfortunately, this is how Linux defines those semantics. I would much
prefer to require barriers explicitely but the decision was made back
then simply because the vast majority of driver writers do not
understand weakly ordered memory models and "everything should be made
to look like x86".

It would be great to come up with a set of more relaxed accessors along
with the appropriate barrier to use for drivers who "know better" but so
far all attempts at doing so have failed due to the inability to agree
on their precise semantics. Tho that was a while ago, we should probably
give it a new shot.

Cheers,
Ben. 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help