From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753553AbbJSJh0 (ORCPT ); Mon, 19 Oct 2015 05:37:26 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:52354 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751358AbbJSJhX (ORCPT ); Mon, 19 Oct 2015 05:37:23 -0400 Date: Mon, 19 Oct 2015 11:37:00 +0200 From: Ralf Baechle To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, linux-mips@linux-mips.org, Russell King - ARM Linux , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, Gerd Hoffmann , Dave Airlie , Arun Sharma Subject: Re: [PATCH] drm/virtio: use %llu format string form atomic64_t Message-ID: <20151019093700.GC2092@linux-mips.org> References: <5082760.FgB9zHNfte@wuerfel> <20151007104502.GH21513@n2100.arm.linux.org.uk> <6260324.3MlUEc3veg@wuerfel> <5152101.mD2bWzUJ2V@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5152101.mD2bWzUJ2V@wuerfel> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote: > > I haven't checked all architectures, but I assume what happens is that > > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have > > to provide three sets of functions. > > scratch that, I just looked at all the architectures and found that it's > just completely arbitrary, even within one architecture you get a mix > of 'long' and 'long long', plus this gem from MIPS: > > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > which truncates the result to 32 bit. Eh... The result is 0/1 so nothing is truncated. Alpha, MIPS, PARISC and PowerPC are using the same prototype and x86 only differs in the use of inline instead __inline__. And anyway, that function on MIPS is only built for CONFIG_64BIT. What's wrong on MIPS is the comment describing the function's return value which was changed by f24219b4e90cf70ec4a211b17fbabc725a0ddf3c (atomic: move atomic_add_unless to generic code) and I've queued up a patch to fix that since a few days. I guess that was a cut and paste error from __atomic_add_unless which indeed does return the old value. Ralf