[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMk6uBmvMsLEkRoVjoLUD4WUpchxGp2ZhQx8gN2a=NbC4hnUMw@mail.gmail.com>
Date: Tue, 16 Jul 2013 13:16:25 +0800
From: Steven Miao <realmz6@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Steven Miao <realmz6@...nel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"uclinux-dist-devel@...ckfin.uclinux.org"
<uclinux-dist-devel@...ckfin.uclinux.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [uclinux-dist-devel] [GIT PULL] Blackfin updates for 3.11
On Tue, Jul 16, 2013 at 1:49 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, Jul 15, 2013 at 10:28 AM, Geert Uytterhoeven
> <geert@...ux-m68k.org> wrote:
>>
>> but the first one is non-trivial: using xchg() on atomic_t is a bit gross...
>
> It's also broken. There's no guarantee that an "atomic_t" is just a
> value. Now, the old sparc32 stuff (which hid lock bits in atomic_t)
> may be gone, but it's still the case that atomic_t may not actually
> work with xchg.
>
> (In *practice* it works on normal architectures, so I'm not saying
> that we don't have it, but it's a bug if we do).
>
> There are "atomic_xchg()" and "atomic_xchg64()" functions that are supported.
I'll send a patch to fix it.
>
> Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists