Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 22 May 2004 18:08:37 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.6-mm5 |
| |
ebiederm@xmission.com (Eric W. Biederman) wrote: > > Andrew Morton <akpm@osdl.org> writes: > > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/ > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/ > > > > > > add-i386-readq.patch > > add i386 readq()/writeq() > > > static inline u64 readq(void *addr) > > { > > return readl(addr) | (((u64)readl(addr + 4)) << 32); > > } > > > > static inline void writeq(u64 v, void *addr) > > { > > u32 v32; > > > > v32 = v; > > writel(v32, addr); > > v32 = v >> 32; > > writel(v32, addr + 4); > > } > > > > #endif > > The implementation is broken and it will break drivers that actually > expect writeq and readq to be 64bit reads and writes.
I don't think we can expect all architectures to be able to implement atomic 64-bit IO's, can we?
ergo, drivers which want to use readq and writeq should provide the appropriate locking.
> I attempted to suggest some alternative implementations earlier > in the original thread that brought this up but it looks like > you missed that.
I saw some stuff float past, but I don't recall seeing anything which would work on all architectures? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |