public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Baole Ni <baolex.ni@intel.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, chuansheng.liu@intel.com
Subject: Re: [PATCH 0001/1285] Replace numeric parameter like 0444 with macro
Date: Tue, 2 Aug 2016 12:29:49 +0100	[thread overview]
Message-ID: <20160802112949.GH1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20160802103322.13810-1-baolex.ni@intel.com>

On Tue, Aug 02, 2016 at 06:33:22PM +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.

Sending a huge patch series is always a no-no.  Please:

(a) group the patches according to maintainer
(b) send in smaller chunks, especially when starting off a new cleanup

I'm not sure why I received powerpc and ia64 changes in addition to ARM
changes, I've nothing to do with powerpc and ia64.  In any case, I'm
not going to read each individual mail to find out whether the patch
is something that is relevent or not.

> 
> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> Signed-off-by: Baole Ni <baolex.ni@intel.com>
> ---
>  arch/arm/common/bL_switcher.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> index 37dc0fe..bd51c35 100644
> --- a/arch/arm/common/bL_switcher.c
> +++ b/arch/arm/common/bL_switcher.c
> @@ -773,7 +773,7 @@ static int bL_switcher_hotplug_callback(struct notifier_block *nfb,
>  }
>  
>  static bool no_bL_switcher;
> -core_param(no_bL_switcher, no_bL_switcher, bool, 0644);
> +core_param(no_bL_switcher, no_bL_switcher, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);

This unnecessarily violates the column limit that we have in the coding
style.  It's also a very simplistic conversion from the octal constant
to the definitions.

core_param(no_bL_switcher, no_bL_switcher, bool, S_IRUGO | S_IWUSR);

would be a better way of saying the same thing - see include/linux/stat.h

However, the cleanup of file modes is at best of questionable value.
Octal file modes are something of a Unix standard - see the chmod man
page.  So, I don't see there's even a need to change file modes to
symbolic constants, especially when it means a _lot_ of mail noise.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2016-08-02 18:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-02 10:33 [PATCH 0001/1285] Replace numeric parameter like 0444 with macro Baole Ni
2016-08-02 11:29 ` Russell King - ARM Linux [this message]
2016-08-02 13:15 ` One Thousand Gnomes
2016-08-02 15:08   ` Masami Hiramatsu
2016-08-02 17:42 ` Pavel Machek
2016-08-02 17:52   ` Joe Perches
2016-08-02 17:54     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160802112949.GH1041@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=baolex.ni@intel.com \
    --cc=chuansheng.liu@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox