| Message ID | 20160802105711.703-1-baolex.ni@intel.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
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.
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
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.
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,