lkml.org 
[lkml]   [2004]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.147 / U:22.132 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site