Staging: rtl8192e: rtl8192e: Removed extra space before break statement

Fixed a style issues reported by checkpatch.pl
break statements had extra spaces before them, so they didn't end at tabstop. Removed the extra space before them to correct the issue.
WARNING: Statements should start on a tabstop
+ break;
WARNING: Statements should start on a tabstop
+ break;

---
 drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 0353f7ee5341..ef92ce957466 100644
@@ -1913,7 +1913,7 @@ static void _rtl92e_update_received_rate_histogram_stats(
 		break;
 	case MGN_2M:
 		rateIndex = 1;
-		 break;
+		break;
 	case MGN_5_5M:
 		rateIndex = 2;
 		break;

@@ -1931,7 +1931,7 @@ static void _rtl92e_update_received_rate_histogram_stats(
 		break;
 	case MGN_18M:
 		rateIndex = 7;
-		 break;
+		break;
 	case MGN_24M:
 		rateIndex = 8;
 		break;

2.21.0

You could rephrase the above to say

"Removed extra spaces before "break" statements to fix the following warnings from checkpatch.pl"

<add warning here>

Your subject line has duplicate information:

rtl8192e twice?

thanks,
-- Shuah

Here's a great post about commit logs: https://chris.beams.io/posts/git-commit/

One hint is to use the imperative mood, as though you're giving a command, e.g., "Remove extra spaces ..." That matches the messages git generates for merges and reverts. Chris says this is only important in the subject line, not in the body, but I enforce it everywhere. I might be OCD.

It also conveniently matches the existing convention for the file:

$ git log --oneline drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
e4441911d969 staging: rtl8192e: fix various indentation issues
90be652c9f15 staging: rtl8192e: rtl92e_get_eeprom_size Fix read size
of EPROM_CMD.
867510bde14e staging: rtl8192e: fix 2 byte alignment of register BSSIDR.
baabd567f87b staging: rtl8192e: rtl92e_fill_tx_desc fix write to
mapped out memory.
a959dec11557 Staging: rtl8192e - fixed style of block comments
4db665e50ccc staging: rtl8192e: Remove useless type conversion
...

Some of those existing subjects include a period at the end (definitely pointless) and also the function name (probably not really useful here). You should also match the existing capitalization style.

General rule: the resulting code and logs should look like the work of a single person, not a mixture of different styles.

Bjorn

I agree with Bjorn. Another way to think of it is to describe what your patch does when one applies it to their tree, as opposed to describing what you have done in the patch.

--
Khalid