Messages in this thread | | | Date | Sun, 24 Oct 2010 18:52:08 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] lib/atomic64_test: do not build on non-atomic64 systems |
| |
On Sun, 24 Oct 2010 09:20:34 -0700 Roland Dreier <rdreier@cisco.com> wrote:
> > That's only part of the problem. The following won't build also: > > > drivers/infiniband/hw > > Interesting... I hadn't looked at that usage before. Both drivers that > seem to use atomic64 already depend on 64BIT in Kconfig, so I suspect > the intersection of 64BIT and !ATOMIC64 is empty? > > But eg drivers/infiniband/hw/qib/qib_rc.c does essentially: > > atomic64_t *maddr; > u64 sdata = <something> > ... > maddr = (atomic64_t *) qp->r_sge.sge.vaddr; > atomic64_add_return(sdata, maddr) > > is it legit to cast some random address to atomic64_t and expect it to > work across archs that implement atomic64?
Not really. If someone implements atomic64 on 32-bit they may do it by putting a spinlock in the atomic64_t. Or they might use hashed spinlocks, in which case that'll work.
Probably hashed spinlocks, given the (realtively new) convention that the all-zeroes pattern is a legit way of initialising an atomic_t.
| |