[PATCH] Keep kernel coding style rule of hfs-s+/sp source

Modified for kernel coding style rule of hfs-s+/sp device driver .
. reference: ./Documentation/CodingStyle

ex)
60 Don't put multiple statements on a single line unless you have
61 something to hide:
62
63         if (condition) do_this;
64           do_something_everytime;

Signed-off-by: Geunsik Lim <redacted>
---
 drivers/isdn/hisax/hfc_sx.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/isdn/hisax/hfc_sx.c b/drivers/isdn/hisax/hfc_sx.c
index 156d7c6..7c41bd8 100644
--- a/drivers/isdn/hisax/hfc_sx.c
+++ b/drivers/isdn/hisax/hfc_sx.c

@@ -381,7 +381,7 @@ reset_hfcsx(struct IsdnCardState *cs)
 	Write_hfc(cs, HFCSX_INT_M1, cs->hw.hfcsx.int_m1);
 
 	/* Clear already pending ints */
-	if (Read_hfc(cs, HFCSX_INT_S1));
+	Read_hfc(cs, HFCSX_INT_S1);
 
 	Write_hfc(cs, HFCSX_STATES, HFCSX_LOAD_STATE | 2);	/* HFC ST 2 */
 	udelay(10);

@@ -411,7 +411,7 @@ reset_hfcsx(struct IsdnCardState *cs)
 	/* Finally enable IRQ output */
 	cs->hw.hfcsx.int_m2 = HFCSX_IRQ_ENABLE;
 	Write_hfc(cs, HFCSX_INT_M2, cs->hw.hfcsx.int_m2);
-	if (Read_hfc(cs, HFCSX_INT_S2));
+	Read_hfc(cs, HFCSX_INT_S2);
 }
 
 /***************************************************/

@@ -1286,7 +1286,7 @@ hfcsx_bh(struct work_struct *work)
 						cs->hw.hfcsx.int_m1 &= ~HFCSX_INTS_TIMER;
 						Write_hfc(cs, HFCSX_INT_M1, cs->hw.hfcsx.int_m1);
 						/* Clear already pending ints */
-						if (Read_hfc(cs, HFCSX_INT_S1));
+						Read_hfc(cs, HFCSX_INT_S1);
 
 						Write_hfc(cs, HFCSX_STATES, 4 | HFCSX_LOAD_STATE);
 						udelay(10);

-- 
1.7.8.1

From: Geunsik Lim <redacted>
Date: Wed,  1 Feb 2012 15:59:53 +0900

Modified for kernel coding style rule of hfs-s+/sp device driver .
. reference: ./Documentation/CodingStyle

ex)
60 Don't put multiple statements on a single line unless you have
61 something to hide:
62
63         if (condition) do_this;
64           do_something_everytime;

Signed-off-by: Geunsik Lim <redacted>

This was probably there to eliminate compiler warnings or avoid the
code being eliminated completely, because the result of the register
read is unused.

Have you verified that neither is the case here?

To be honest I very strongly dislike patches like this.  You're
patching a driver that very few people use, and changes like this can
only risk possible regressions that will be hard to notice and it's
not like people scour over this driver often and thus will be upset by
frequently seeing some minor coding style infraction.

I'm not applying this patch.