From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966819AbcHBNqB (ORCPT ); Tue, 2 Aug 2016 09:46:01 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:40800 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966626AbcHBNps (ORCPT ); Tue, 2 Aug 2016 09:45:48 -0400 Date: Tue, 2 Aug 2016 15:44:18 +0200 From: Ralf Baechle To: Baole Ni , Atsushi Nemoto Cc: fenghua.yu@intel.com, robert.jarzmik@free.fr, linux@armlinux.org.uk, linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, chuansheng.liu@intel.com Subject: Re: [PATCH 0014/1285] Replace numeric parameter like 0444 with macro Message-ID: <20160802134418.GF15910@linux-mips.org> References: <20160802103421.14690-1-baolex.ni@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160802103421.14690-1-baolex.ni@intel.com> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 02, 2016 at 06:34:21PM +0800, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the corresponding macro, > and that using macro can improve the robustness and readability of the code, > thus, I suggest replacing the numeric parameter with the macro. > > Signed-off-by: Chuansheng Liu > Signed-off-by: Baole Ni > --- > arch/mips/txx9/generic/7segled.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/mips/txx9/generic/7segled.c b/arch/mips/txx9/generic/7segled.c > index 566c58b..1fcd1ec 100644 > --- a/arch/mips/txx9/generic/7segled.c > +++ b/arch/mips/txx9/generic/7segled.c > @@ -55,8 +55,8 @@ static ssize_t raw_store(struct device *dev, > return size; > } > > -static DEVICE_ATTR(ascii, 0200, NULL, ascii_store); > -static DEVICE_ATTR(raw, 0200, NULL, raw_store); > +static DEVICE_ATTR(ascii, S_IWUSR, NULL, ascii_store); > +static DEVICE_ATTR(raw, S_IWUSR, NULL, raw_store); > > static ssize_t map_seg7_show(struct device *dev, > struct device_attribute *attr, > @@ -76,7 +76,7 @@ static ssize_t map_seg7_store(struct device *dev, > return size; > } > > -static DEVICE_ATTR(map_seg7, 0600, map_seg7_show, map_seg7_store); > +static DEVICE_ATTR(map_seg7, S_IRUSR | S_IWUSR, map_seg7_show, map_seg7_store); > > static struct bus_type tx_7segled_subsys = { > .name = "7segled", I find this one of the case where the number is much understandable than a cryptic symbol whos name was chosen when C compilers still had limitations on the symbol length and every byte was sacred. Ralf