From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vineet Gupta Subject: Re: [PATCH] atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE Date: Thu, 8 Sep 2016 11:34:29 -0700 Message-ID: References: <1473352098-5822-1-git-send-email-vgupta@synopsys.com> <20160908181905.GY10153@twins.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160908181905.GY10153@twins.programming.kicks-ass.net> Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Peter Zijlstra Cc: "linux-mips@linux-mips.org" , Catalin Marinas , Linus Walleij , Alexey Brodkin , Heiko Carstens , "James E.J. Bottomley" , Paul Mackerras , "H. Peter Anvin" , "sparclinux@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , Andi Kleen , Herbert Xu , Michael Ellerman , Helge Deller , "x86@kernel.org" , Russell King , Ingo Molnar List-Id: linux-arch.vger.kernel.org On 09/08/2016 11:19 AM, Peter Zijlstra wrote: > On Thu, Sep 08, 2016 at 09:28:18AM -0700, Vineet Gupta wrote: >> This came to light when implementing native 64-bit atomics for ARCv2. >> >> The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE >> to check whether atomic64_dec_if_positive() is available. >> It seems it was needed when not every arch defined it. >> However as of current code the Kconfig option seems needless >> >> - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a >> generic definition of API is present lib/atomic64.c >> - arches with native 64-bit atomics select it in arch/*/Kconfig and >> define the API in their headers >> >> So I see no point in keeping the Kconfig option >> >> Compile tested for 2 representatives: >> - blackfin (CONFIG_GENERIC_ATOMIC64) >> - x86 (!CONFIG_GENERIC_ATOMIC64) >> >> Also logistics wise it seemed simpler to just do this in 1 patch vs. >> splitting per arch - but I can break it up if maintainer feel that >> is better to avoid conflicts. > Works for me; you want me to take this, or do you need it for you ARCv2 > patches? Please do. ARCv2 patch (following shortly) doesn't need it - I selected the option in orig patch - which I can just take out. Thx, -Vineet