[0290/1285] Replace numeric parameter like 0444 with macro
diff mbox

Message ID 20160802105711.703-1-baolex.ni@intel.com
State Rejected
Headers show

Commit Message

baolex.ni Aug. 2, 2016, 10:57 a.m. UTC
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 <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
 drivers/input/touchscreen/ads7846.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Mark Brown Aug. 2, 2016, 2:31 p.m. UTC | #1
On Tue, Aug 02, 2016 at 06:57:11PM +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.

Please split these up and send them independently to the relevant
maintainers with sensible subject lines - a single 1000+ patch series is
far too large and you're CCing random people so it's hard to tell which
patches are relevant (for example the batch I'm replying to here are for
the input subsystem which I don't maintain so I'm not 100% sure why I'm
being copied here).

With this sort of thing it's often best to send one series per directory
or something similar.
Andrew F. Davis Aug. 2, 2016, 2:51 p.m. UTC | #2
On 08/02/2016 09:31 AM, Mark Brown wrote:
> On Tue, Aug 02, 2016 at 06:57:11PM +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.
> 
> Please split these up and send them independently to the relevant
> maintainers with sensible subject lines - a single 1000+ patch series is
> far too large and you're CCing random people so it's hard to tell which
> patches are relevant (for example the batch I'm replying to here are for
> the input subsystem which I don't maintain so I'm not 100% sure why I'm
> being copied here).
> 
> With this sort of thing it's often best to send one series per directory
> or something similar.
> 

I would recommend just adding whatever script you used to find all of
these to patchcheck or coccinelle, then let people familiar with each
subsystem make and submit the fix-ups for each subsystem. You won't get
1000+ patches to your name, but the work still gets done and you avoid
bothering a lot of people.

(I got about several of these for files I've never touched :/)

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dmitry Torokhov Aug. 2, 2016, 5:27 p.m. UTC | #3
On Tue, Aug 02, 2016 at 06:57:11PM +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 <chuansheng.liu@intel.com>
> Signed-off-by: Baole Ni <baolex.ni@intel.com>
> ---
>  drivers/input/touchscreen/ads7846.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> index a61b215..0f882cb 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -591,7 +591,7 @@ static ssize_t ads7846_disable_store(struct device *dev,
>  	return count;
>  }
>  
> -static DEVICE_ATTR(disable, 0664, ads7846_disable_show, ads7846_disable_store);
> +static DEVICE_ATTR(disable, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH, ads7846_disable_show, ads7846_disable_store);

No, this does not improve neither robustness nor readability.

Thanks.

Patch
diff mbox

diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index a61b215..0f882cb 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -591,7 +591,7 @@  static ssize_t ads7846_disable_store(struct device *dev,
 	return count;
 }
 
-static DEVICE_ATTR(disable, 0664, ads7846_disable_show, ads7846_disable_store);
+static DEVICE_ATTR(disable, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH, ads7846_disable_show, ads7846_disable_store);
 
 static struct attribute *ads784x_attributes[] = {
 	&dev_attr_pen_down.attr,