Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752840AbcCYIli (ORCPT ); Fri, 25 Mar 2016 04:41:38 -0400 Received: from cmccmta1.chinamobile.com ([221.176.66.79]:5854 "EHLO cmccmta1.chinamobile.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752570AbcCYIld (ORCPT ); Fri, 25 Mar 2016 04:41:33 -0400 X-RM-TRANSID: 2ee156f4f9b7fc8-da2a3 X-RM-SPAM-FLAG: 00000000 X-RM-TRANSID: 2eea56f4f9b600f-09f3f Date: Fri, 25 Mar 2016 16:41:07 +0800 From: Yaowei Bai To: Richard Weinberger Cc: Dongsheng Yang , dwmw2@infradead.org, computersforpeace@gmail.com, boris.brezillon@free-electrons.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5] drivers/mtd: make several functions return bool Message-ID: <20160325084107.GA4526@yaowei-K42JY> References: <1458873715-3670-1-git-send-email-baiyaowei@cmss.chinamobile.com> <56F4A87B.5090100@easystack.cn> <20160325063153.GA3319@yaowei-K42JY> <56F4EF87.4000003@nod.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F4EF87.4000003@nod.at> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1057 Lines: 32 On Fri, Mar 25, 2016 at 08:57:59AM +0100, Richard Weinberger wrote: > Am 25.03.2016 um 07:31 schrieb Yaowei Bai: > > On Fri, Mar 25, 2016 at 10:54:51AM +0800, Dongsheng Yang wrote: > >> ccing: Brian and Richard > >> > >> Hi Yao, > >> Is that really necessary? I am not sure how much benefit we can > >> achieve from this change. > >> Could you explain more? > > > > Yes, according to these functions' name, a boolean return value is more > > suitable and matchable. > > > > Also personally think this change maybe benfit function's return value > > storage in the stack when called on certain architectures. > > On which archs? And what exactly is the benefit? > I agree that bool might be a better choice for new functions > but here you're touching existing and working(!) code. > The only outcome is git history pollution that makes git blame > less efficient. Working code doesn't mean perfect code. :-) I still think this's a helpful change even though it's small, but you make the decision to merge or drop it. > > Thanks, > //richard >