Benjamin Herrenschmidt wrote:
This is why I said "good enough for drivers". This is _key_.
I have run into several [PCI] devices with 64-bit registers, and
__none__ of them had requirements such that the Linux platform code
-must- provide an atomic readq/writeq. Probably because everybody wants
to support 32-bit platforms with their devices.
What you call "fairly bogus" is precisely what drivers need. These
devices with 64-bit registers just don't need the atomicity that arch
developers harp about :)
Is there any consistency in that case in which half need to be
read/written first ? Or none of these ever had side effects ?
Generally the kernel code should write the two 32-bit chunks to the
memory-mapped region in order (low dword first), and let things take
care of themselves from there.
That's pretty much the implementation that -every- driver copies, when
they need readq/writeq to work on a 32-bit platform.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
