Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp745109imm; Tue, 5 Jun 2018 03:54:53 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIo8FMVZFCIOTDSziRoCBXCrriO47dpegoOKINLUqAEuM+HotBOI0SMj25wdMmQvrTX0fWz X-Received: by 2002:a63:6096:: with SMTP id u144-v6mr20360887pgb.433.1528196093071; Tue, 05 Jun 2018 03:54:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528196093; cv=none; d=google.com; s=arc-20160816; b=iCgdtbZFAok0L941YDNBZIIgVqozhTyVdN3+Wjz7Hou2tEaRKFvPNV7T6yikRfl1sT zxqkhxIG4LemNn4taxvUeBnSP1xzL8AZVYt6KgpkpY4aCs6nOGHvD0/W/1icwnU7m0A3 IetEXP+Ldx1XVhnnZ96huu3RDTWcAMS5jfgOuE6hRFjd2QgMMDepYCwMenFGMbwnGNmM lL/zGPjYlLnHy5KDKE7f5AAUBkEaoy7EyrvW62VTURqhqe74YxZoP9NF9BmAfNM5Piy0 afV+ZbPNFS3H9Z1I9Sew1tPqgAlXyEwgjvl2DEzGwF+N4mZyTID/RvGpxzU7gmQ4YX2A jKKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=jio4qjSJ+EB98qeLkfTmWnFAyt137VJpu6qK9p84Jvw=; b=ykl61KM9eXc7YwO1iJh1F3eB5ozKloErjs5hxOoqGcpUqyWRyBPvNrcohpRVvjHYMD HGuUUzw0oXPqF7FfNdygdyeJ6/sNTKubqPaZ2CU1XIuJiHGyzvmREh2NCLx9A6YQQZwP Y7BDVWqSBdvl6xCpLNc0o3QLypTmDa/ci1UN6NV5BvN7/UuIuHIkawIUG3+Kf6hejP1y CWhr/W/w6v11ujCDIIiP7RvIOfSqHesYhauVpVWKO/K4rMyhoZP5xDTzSszpUfdMOhUe H8r+x0HG40TWMX1byRPkG5f/fomVd6rbkt73+7mDNtMbRdVBzBoqnNewO4eV2OnOKrQN vLIw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m8-v6si46883106plt.29.2018.06.05.03.54.38; Tue, 05 Jun 2018 03:54:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751578AbeFEKyO (ORCPT + 99 others); Tue, 5 Jun 2018 06:54:14 -0400 Received: from ozlabs.org ([203.11.71.1]:50307 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751386AbeFEKyN (ORCPT ); Tue, 5 Jun 2018 06:54:13 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 410TFT4NK7z9rxs; Tue, 5 Jun 2018 20:54:04 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Mark Rutland , Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Boqun Feng , Will Deacon , Arnd Bergmann , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Benjamin Herrenschmidt , Paul Mackerras , Palmer Dabbelt , Albert Ou Subject: Re: [PATCHv2 05/16] atomics: prepare for atomic64_fetch_add_unless() In-Reply-To: <20180605095357.64zgw3uq3py2pjs4@lakrids.cambridge.arm.com> References: <20180529154346.3168-1-mark.rutland@arm.com> <20180529154346.3168-6-mark.rutland@arm.com> <20180605092637.GF12258@hirez.programming.kicks-ass.net> <20180605095357.64zgw3uq3py2pjs4@lakrids.cambridge.arm.com> Date: Tue, 05 Jun 2018 20:54:03 +1000 Message-ID: <87bmcpo65w.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mark Rutland writes: > On Tue, Jun 05, 2018 at 11:26:37AM +0200, Peter Zijlstra wrote: >> On Tue, May 29, 2018 at 04:43:35PM +0100, Mark Rutland wrote: >> > /** >> > + * atomic64_add_unless - add unless the number is already a given value >> > + * @v: pointer of type atomic_t >> > + * @a: the amount to add to v... >> > + * @u: ...unless v is equal to u. >> > + * >> > + * Atomically adds @a to @v, so long as @v was not already @u. >> > + * Returns non-zero if @v was not @u, and zero otherwise. >> >> I always get confused by that wording; would something like: "Returns >> true if the addition was done" not be more clear? > > Sounds clearer to me; I just stole the wording from the existing > atomic_add_unless(). > > I guess you'll want similar for the conditional inc/dec ops, e.g. > > /** > * atomic_inc_not_zero - increment unless the number is zero > * @v: pointer of type atomic_t > * > * Atomically increments @v by 1, so long as @v is non-zero. > * Returns non-zero if @v was non-zero, and zero otherwise. > */ If we're bike-shedding .. :) I think "so long as" is overly wordy and not helpful. It'd be clearer just as: * Atomically increments @v by 1, if @v is non-zero. cheers