From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH] atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE Date: Thu, 8 Sep 2016 20:19:05 +0200 Message-ID: <20160908181905.GY10153@twins.programming.kicks-ass.net> References: <1473352098-5822-1-git-send-email-vgupta@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1473352098-5822-1-git-send-email-vgupta@synopsys.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org List-Archive: List-Post: To: Vineet Gupta 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 , Geert Uytterhoeven , Benjamin Herrenschmidt , Matthew Wilcox , Matt Turner , Borislav Petkov , Ming Lin , Chris List-ID: 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?