[lm-sensors] [PATCH] drivers/hwmon: fix trailing whitespace

[lm-sensors] [PATCH] drivers/hwmon: fix trailing whitespace

[Frans Meulenbroeks]

Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
---
 drivers/hwmon/adm1025.c   |    2 +-
 drivers/hwmon/ds1621.c    |    6 +++---
 drivers/hwmon/g760a.c     |    2 +-
 drivers/hwmon/hwmon-vid.c |    2 +-
 drivers/hwmon/lm78.c      |   10 +++++-----
 drivers/hwmon/lm83.c      |    2 +-
 drivers/hwmon/max1619.c   |    2 +-
 drivers/hwmon/sis5595.c   |    4 ++--
 drivers/hwmon/smsc47m1.c  |    2 +-
 drivers/hwmon/w83627hf.c  |    2 +-
 drivers/hwmon/w83l785ts.c |    2 +-
 11 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/hwmon/adm1025.c b/drivers/hwmon/adm1025.c
index 60befc0..80c2b4e 100644
--- a/drivers/hwmon/adm1025.c
+++ b/drivers/hwmon/adm1025.c
@@ -12,7 +12,7 @@
  * resolution of about 0.5% of the nominal value). Temperature values are
  * reported with a 1 deg resolution and a 3 deg accuracy. Complete
  * datasheet can be obtained from Analog's website at:
- *   http://www.onsemi.com/PowerSolutions/product.do?id­M1025 
+ *   http://www.onsemi.com/PowerSolutions/product.do?id­M1025
  *
  * This driver also supports the ADM1025A, which differs from the ADM1025
  * only in that it has "open-drain VID inputs while the ADM1025 has
diff --git a/drivers/hwmon/ds1621.c b/drivers/hwmon/ds1621.c
index ef1ac996..89fe791 100644
--- a/drivers/hwmon/ds1621.c
+++ b/drivers/hwmon/ds1621.c
@@ -3,7 +3,7 @@
              monitoring
     Christian W. Zuckschwerdt  <zany@triq.net>  2000-11-23
     based on lm75.c by Frodo Looijaard <frodol@dds.nl>
-    Ported to Linux 2.6 by Aurelien Jarno <aurelien@aurel32.net> with 
+    Ported to Linux 2.6 by Aurelien Jarno <aurelien@aurel32.net> with
     the help of Jean Delvare <khali@linux-fr.org>
 
     This program is free software; you can redistribute it and/or modify
@@ -212,8 +212,8 @@ static int ds1621_detect(struct i2c_client *client,
 	int conf, temp;
 	int i;
 
-	if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA 
-				     | I2C_FUNC_SMBUS_WORD_DATA 
+	if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA
+				     | I2C_FUNC_SMBUS_WORD_DATA
 				     | I2C_FUNC_SMBUS_WRITE_BYTE))
 		return -ENODEV;
 
diff --git a/drivers/hwmon/g760a.c b/drivers/hwmon/g760a.c
index 1d6a6fa..905e194 100644
--- a/drivers/hwmon/g760a.c
+++ b/drivers/hwmon/g760a.c
@@ -5,7 +5,7 @@
     Copyright (C) 2007  Herbert Valerio Riedel <hvr@gnu.org>
 
     Complete datasheet is available at GMT's website:
-      http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf 
+      http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf
 
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
diff --git a/drivers/hwmon/hwmon-vid.c b/drivers/hwmon/hwmon-vid.c
index 4fcb867..a918426 100644
--- a/drivers/hwmon/hwmon-vid.c
+++ b/drivers/hwmon/hwmon-vid.c
@@ -40,7 +40,7 @@
  * available at http://developer.intel.com/.
  *
  * AMD Athlon 64 and AMD Opteron Processors, AMD Publication 26094,
- * http://support.amd.com/us/Processor_TechDocs/26094.PDF 
+ * http://support.amd.com/us/Processor_TechDocs/26094.PDF
  * Table 74. VID Code Voltages
  * This corresponds to an arbitrary VRM code of 24 in the functions below.
  * These CPU models (K8 revision <= E) have 5 VID pins. See also:
diff --git a/drivers/hwmon/lm78.c b/drivers/hwmon/lm78.c
index 6df0b46..7fc3449 100644
--- a/drivers/hwmon/lm78.c
+++ b/drivers/hwmon/lm78.c
@@ -1,7 +1,7 @@
 /*
     lm78.c - Part of lm_sensors, Linux kernel modules for hardware
              monitoring
-    Copyright (c) 1998, 1999  Frodo Looijaard <frodol@dds.nl> 
+    Copyright (c) 1998, 1999  Frodo Looijaard <frodol@dds.nl>
     Copyright (c) 2007, 2011  Jean Delvare <khali@linux-fr.org>
 
     This program is free software; you can redistribute it and/or modify
@@ -74,7 +74,7 @@ enum chips { lm78, lm79 };
 #define LM78_REG_I2C_ADDR 0x48
 
 
-/* Conversions. Rounding and limit checking is only done on the TO_REG 
+/* Conversions. Rounding and limit checking is only done on the TO_REG
    variants. */
 
 /* IN: mV, (0V to 4.08V)
@@ -669,7 +669,7 @@ static struct i2c_driver lm78_driver = {
 	.address_list	= normal_i2c,
 };
 
-/* The SMBus locks itself, but ISA access must be locked explicitly! 
+/* The SMBus locks itself, but ISA access must be locked explicitly!
    We don't want to lock the whole ISA bus, so we lock each client
    separately.
    We ignore the LM78 BUSY flag at this moment - it could lead to deadlocks,
@@ -691,11 +691,11 @@ static int lm78_read_value(struct lm78_data *data, u8 reg)
 		return i2c_smbus_read_byte_data(client, reg);
 }
 
-/* The SMBus locks itself, but ISA access muse be locked explicitly! 
+/* The SMBus locks itself, but ISA access muse be locked explicitly!
    We don't want to lock the whole ISA bus, so we lock each client
    separately.
    We ignore the LM78 BUSY flag at this moment - it could lead to deadlocks,
-   would slow down the LM78 access and should not be necessary. 
+   would slow down the LM78 access and should not be necessary.
    There are some ugly typecasts here, but the good new is - they should
    nowhere else be necessary! */
 static int lm78_write_value(struct lm78_data *data, u8 reg, u8 value)
diff --git a/drivers/hwmon/lm83.c b/drivers/hwmon/lm83.c
index 8290476..565550a 100644
--- a/drivers/hwmon/lm83.c
+++ b/drivers/hwmon/lm83.c
@@ -124,7 +124,7 @@ static struct lm83_data *lm83_update_device(struct device *dev);
 /*
  * Driver data (common to all clients)
  */
- 
+
 static const struct i2c_device_id lm83_id[] = {
 	{ "lm83", lm83 },
 	{ "lm82", lm82 },
diff --git a/drivers/hwmon/max1619.c b/drivers/hwmon/max1619.c
index 022ded0..e0586cc 100644
--- a/drivers/hwmon/max1619.c
+++ b/drivers/hwmon/max1619.c
@@ -125,7 +125,7 @@ struct max1619_data {
 	u8 temp_input2, temp_low2, temp_high2; /* remote */
 	u8 temp_crit2;
 	u8 temp_hyst2;
-	u8 alarms; 
+	u8 alarms;
 };
 
 /*
diff --git a/drivers/hwmon/sis5595.c b/drivers/hwmon/sis5595.c
index 3324245..6254eb2 100644
--- a/drivers/hwmon/sis5595.c
+++ b/drivers/hwmon/sis5595.c
@@ -26,7 +26,7 @@
 /*
    SiS southbridge has a LM78-like chip integrated on the same IC.
    This driver is a customized copy of lm78.c
-   
+
    Supports following revisions:
 	Version		PCI ID		PCI Revision
 	1		1039/0008	AF or less
@@ -521,7 +521,7 @@ static struct attribute *sis5595_attributes_temp1[] = {
 static const struct attribute_group sis5595_group_temp1 = {
 	.attrs = sis5595_attributes_temp1,
 };
- 
+
 /* This is called when the module is loaded */
 static int __devinit sis5595_probe(struct platform_device *pdev)
 {
diff --git a/drivers/hwmon/smsc47m1.c b/drivers/hwmon/smsc47m1.c
index f44a89a..c3326f9 100644
--- a/drivers/hwmon/smsc47m1.c
+++ b/drivers/hwmon/smsc47m1.c
@@ -508,7 +508,7 @@ static void smsc47m1_restore(const struct smsc47m1_sio_data *sio_data)
 
 /*
  * This function can be used to:
- *  - test for resource conflicts with ACPI
+ *  - test for resource conflicts with ACP
  *  - request the resources
  *  - release the resources
  * We only allocate the I/O ports we really need, to minimize the risk of
diff --git a/drivers/hwmon/w83627hf.c b/drivers/hwmon/w83627hf.c
index 2192662..2f528a0 100644
--- a/drivers/hwmon/w83627hf.c
+++ b/drivers/hwmon/w83627hf.c
@@ -1605,7 +1605,7 @@ static void __devinit w83627hf_init_device(struct platform_device *pdev)
 
 	/* Read VRM & OVT Config only once */
 	if (type = w83627thf || type = w83637hf || type = w83687thf) {
-		data->vrm_ovt = 
+		data->vrm_ovt  			w83627hf_read_value(data, W83627THF_REG_VRM_OVT_CFG);
 	}
 
diff --git a/drivers/hwmon/w83l785ts.c b/drivers/hwmon/w83l785ts.c
index 20781de..edfc1ec 100644
--- a/drivers/hwmon/w83l785ts.c
+++ b/drivers/hwmon/w83l785ts.c
@@ -86,7 +86,7 @@ static struct w83l785ts_data *w83l785ts_update_device(struct device *dev);
 /*
  * Driver data (common to all clients)
  */
- 
+
 static const struct i2c_device_id w83l785ts_id[] = {
 	{ "w83l785ts", 0 },
 	{ }
-- 
1.7.8.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] drivers/hwmon: fix trailing whitespace

[Guenter Roeck]

Hi Frans,

On Thu, Jan 05, 2012 at 04:23:56PM -0500, Frans Meulenbroeks wrote:
> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
> ---
>  drivers/hwmon/adm1025.c   |    2 +-
>  drivers/hwmon/ds1621.c    |    6 +++---
>  drivers/hwmon/g760a.c     |    2 +-
>  drivers/hwmon/hwmon-vid.c |    2 +-
>  drivers/hwmon/lm78.c      |   10 +++++-----
>  drivers/hwmon/lm83.c      |    2 +-
>  drivers/hwmon/max1619.c   |    2 +-
>  drivers/hwmon/sis5595.c   |    4 ++--
>  drivers/hwmon/smsc47m1.c  |    2 +-
>  drivers/hwmon/w83627hf.c  |    2 +-
>  drivers/hwmon/w83l785ts.c |    2 +-
>  11 files changed, 18 insertions(+), 18 deletions(-)
> 
Your other patches are fine, but this one has checkpatch errors and warnings:

ERROR: code indent should use tabs where possible
#793: FILE: drivers/hwmon/hwmon-vid.c:122:
+^I^I                       1850 - val * 25;$

ERROR: code indent should use tabs where possible
#812: FILE: drivers/hwmon/hwmon-vid.c:137:
+^I^I                     2050 - (val) * 50;$

WARNING: please, no spaces at the start of a line
#1276: FILE: drivers/hwmon/ds1621.c:6:
+    Ported to Linux 2.6 by Aurelien Jarno <aurelien@aurel32.net> with$

WARNING: please, no spaces at the start of a line
#1300: FILE: drivers/hwmon/g760a.c:8:
+      http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf$

total: 2 errors, 2 warnings, 607 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

While those were already there in the original files, it doesn't really help much
to only remove the spaces at the end of the line. And newly submitted patches should
not have any checkpatch errors or warnings.

I enqueued the other patches for one of the rc candidates.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] drivers/hwmon: fix trailing whitespace

[Frans Meulenbroeks]

[-- Attachment #1.1: Type: text/plain, Size: 2542 bytes --]

2012/1/6 Guenter Roeck <guenter.roeck@ericsson.com>

> Hi Frans,
>
> On Thu, Jan 05, 2012 at 04:23:56PM -0500, Frans Meulenbroeks wrote:
> > Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
> > ---
> >  drivers/hwmon/adm1025.c   |    2 +-
> >  drivers/hwmon/ds1621.c    |    6 +++---
> >  drivers/hwmon/g760a.c     |    2 +-
> >  drivers/hwmon/hwmon-vid.c |    2 +-
> >  drivers/hwmon/lm78.c      |   10 +++++-----
> >  drivers/hwmon/lm83.c      |    2 +-
> >  drivers/hwmon/max1619.c   |    2 +-
> >  drivers/hwmon/sis5595.c   |    4 ++--
> >  drivers/hwmon/smsc47m1.c  |    2 +-
> >  drivers/hwmon/w83627hf.c  |    2 +-
> >  drivers/hwmon/w83l785ts.c |    2 +-
> >  11 files changed, 18 insertions(+), 18 deletions(-)
> >
> Your other patches are fine, but this one has checkpatch errors and
> warnings:
>
> ERROR: code indent should use tabs where possible
> #793: FILE: drivers/hwmon/hwmon-vid.c:122:
> +^I^I                       1850 - val * 25;$
>
> ERROR: code indent should use tabs where possible
> #812: FILE: drivers/hwmon/hwmon-vid.c:137:
> +^I^I                     2050 - (val) * 50;$
>
> WARNING: please, no spaces at the start of a line
> #1276: FILE: drivers/hwmon/ds1621.c:6:
> +    Ported to Linux 2.6 by Aurelien Jarno <aurelien@aurel32.net> with$
>
> WARNING: please, no spaces at the start of a line
> #1300: FILE: drivers/hwmon/g760a.c:8:
> +      http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf$
>
> total: 2 errors, 2 warnings, 607 lines checked
>
> NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
>      scripts/cleanfile
>
> While those were already there in the original files, it doesn't really
> help much
> to only remove the spaces at the end of the line. And newly submitted
> patches should
> not have any checkpatch errors or warnings.
>
> I enqueued the other patches for one of the rc candidates.
>
> Thanks,
> Guenter
>

Guenter,

Thanks for your reply.

Probably i should explain a little bit on my way of working.
For me the most efficient way to tackle this is to only fix one error type
at a time.
This reduces the chance of mistakes (like mixing up simple_strtoul and
strict_strtoul), and also makes doing the edits simpler.
However the side effect of this is that not all problems in a file are
solved.

(btw I also peeked at cleanfile, but for some reason it won't work for me.
Probably something at my side).

Best regards, Frans

PS: note that I don't own most of the hardware, so i cannot really run-time
verify my work, only do a compile-test.

[-- Attachment #1.2: Type: text/html, Size: 3254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] drivers/hwmon: fix trailing whitespace

[Jean Delvare]

Hi Frans,

On Fri, 6 Jan 2012 08:32:43 +0100, Frans Meulenbroeks wrote:
> 2012/1/6 Guenter Roeck <guenter.roeck@ericsson.com>
> > Your other patches are fine, but this one has checkpatch errors and
> > warnings:
> >
> > ERROR: code indent should use tabs where possible
> > #793: FILE: drivers/hwmon/hwmon-vid.c:122:
> > +^I^I                       1850 - val * 25;$
> >
> > ERROR: code indent should use tabs where possible
> > #812: FILE: drivers/hwmon/hwmon-vid.c:137:
> > +^I^I                     2050 - (val) * 50;$
> >
> > WARNING: please, no spaces at the start of a line
> > #1276: FILE: drivers/hwmon/ds1621.c:6:
> > +    Ported to Linux 2.6 by Aurelien Jarno <aurelien@aurel32.net> with$
> >
> > WARNING: please, no spaces at the start of a line
> > #1300: FILE: drivers/hwmon/g760a.c:8:
> > +      http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf$
> >
> > total: 2 errors, 2 warnings, 607 lines checked
> >
> > NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
> >      scripts/cleanfile
> >
> > While those were already there in the original files, it doesn't really
> > help much
> > to only remove the spaces at the end of the line. And newly submitted
> > patches should
> > not have any checkpatch errors or warnings.
> (...)
> Probably i should explain a little bit on my way of working.
> For me the most efficient way to tackle this is to only fix one error type
> at a time.
> This reduces the chance of mistakes (like mixing up simple_strtoul and
> strict_strtoul), and also makes doing the edits simpler.

That's a bad example IMHO. These two changes should really go in the
same commit, as they are so similar. You can easily generate them
separately and then merge them together before sending.

> However the side effect of this is that not all problems in a file are
> solved.

I definitely prefer doing it the other way around: take one driver and
fix all (or most) style issues. While it is slightly more time
consuming to review, it has advantages:
* When backporting a driver to an older kernel, you can pick all
  patches touching the driver, without having to filter out all changes
  affecting other drivers.
* Checkpatch is happy on every patch, which compensates for the harder
  review.
* Per-driver patches are easier for me and Guenter to handle. We tend
  to each concentrate on a subset of the drivers for each release
  cycle, so that our trees don't collide in linux-next. With
  cross-driver patches we can't do that, which basically puts all the
  handling burden on a single one of us for the whole release cycle.
* It makes the history of each individual driver much easier to read.
  Having 10 patches in the history to clean up 10 different style
  issues doesn't exactly help.

> PS: note that I don't own most of the hardware, so i cannot really run-time
> verify my work, only do a compile-test.

And so:
* Testing by people with the hardware is much easier.

If you still prefer cross-driver patches, I guess that's better than
not getting contributions from you at all, but then please at least
ensure that checkpatch doesn't complain about your patches, even if
that means fixing more than one issue at once. BTW, all whitespace
fixes can go in the same patch to start with, it makes sense to group
them IMHO.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] drivers/hwmon: fix trailing whitespace

[Frans Meulenbroeks]

[-- Attachment #1.1: Type: text/plain, Size: 2598 bytes --]

2012/1/6 Jean Delvare <khali@linux-fr.org>

> Hi Frans,
>
> [...]


> > > not have any checkpatch errors or warnings.
> > (...)
> > Probably i should explain a little bit on my way of working.
> > For me the most efficient way to tackle this is to only fix one error
> type
> > at a time.
> > This reduces the chance of mistakes (like mixing up simple_strtoul and
> > strict_strtoul), and also makes doing the edits simpler.
>
> That's a bad example IMHO. These two changes should really go in the
> same commit, as they are so similar. You can easily generate them
> separately and then merge them together before sending.
>
> > However the side effect of this is that not all problems in a file are
> > solved.
>
> I definitely prefer doing it the other way around: take one driver and
> fix all (or most) style issues. While it is slightly more time
> consuming to review, it has advantages:
> * When backporting a driver to an older kernel, you can pick all
>  patches touching the driver, without having to filter out all changes
>  affecting other drivers.
> * Checkpatch is happy on every patch, which compensates for the harder
>  review.
> * Per-driver patches are easier for me and Guenter to handle. We tend
>  to each concentrate on a subset of the drivers for each release
>  cycle, so that our trees don't collide in linux-next. With
>  cross-driver patches we can't do that, which basically puts all the
>  handling burden on a single one of us for the whole release cycle.
> * It makes the history of each individual driver much easier to read.
>  Having 10 patches in the history to clean up 10 different style
>  issues doesn't exactly help.
>
> > PS: note that I don't own most of the hardware, so i cannot really
> run-time
> > verify my work, only do a compile-test.
>
> And so:
> * Testing by people with the hardware is much easier.
>
> If you still prefer cross-driver patches, I guess that's better than
> not getting contributions from you at all, but then please at least
> ensure that checkpatch doesn't complain about your patches, even if
> that means fixing more than one issue at once. BTW, all whitespace
> fixes can go in the same patch to start with, it makes sense to group
> them IMHO.
>
> Hi Jean,

Thanks for your feedback.
I did not really consider things from the perspective of the reviewer and
user.
Please ignore this patch. I'll revert back to file specific patches.
Note that I am not planning to clean all files with checkpatch problems,
but I'll probably do a few more inbetween other things (e.g. waiting for a
kernel rebuild).

Best regards, Frans

[-- Attachment #1.2: Type: text/html, Size: 3407 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH] drivers/hwmon: fix trailing whitespace

[Guenter Roeck]

Hi Frans,

On Fri, Jan 06, 2012 at 03:35:05AM -0500, Frans Meulenbroeks wrote:
> 
[...]
>  
>     If you still prefer cross-driver patches, I guess that's better than
>     not getting contributions from you at all, but then please at least
>     ensure that checkpatch doesn't complain about your patches, even if
>     that means fixing more than one issue at once. BTW, all whitespace
>     fixes can go in the same patch to start with, it makes sense to group
>     them IMHO.
>    
> 
> Hi Jean,
> 
> Thanks for your feedback.
> I did not really consider things from the perspective of the reviewer and user.
> Please ignore this patch. I'll revert back to file specific patches.
> Note that I am not planning to clean all files with checkpatch problems, but
> I'll probably do a few more inbetween other things (e.g. waiting for a kernel
> rebuild).
> 
Please don't feel discouraged. You are doing extremely well for a kernel newbie.

I agree with Jean that file specific patches are better for us, but, yes, cross-drive
patches are better than none.  The only thing we really ask for is that any patches
you submit should not have any checkpatch errors or warnings.

There is also a script named cleanpatch which is supposed to fix whitespace errors
in patches.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors