[PATCH 1/2] staging: rtl8192u: Using function name as string

[PATCH 1/2] staging: rtl8192u: Using function name as string

[Camylla Goncalves Cantanheide]

Solves the following checkpatch.pl for a triggered function:
WARNING: Prefer using '"%s...", __func__' to using 'setKey',
this function's name, in a string

Signed-off-by: Camylla Goncalves Cantanheide <c.cantanheide@gmail.com>
---
 drivers/staging/rtl8192u/r8192U_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
index 9e222172b..93a15d57e 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4886,11 +4886,11 @@ void setKey(struct net_device *dev, u8 EntryNo, u8 KeyIndex, u16 KeyType,
 	u8 i;
 
 	if (EntryNo >= TOTAL_CAM_ENTRY)
-		RT_TRACE(COMP_ERR, "cam entry exceeds in setKey()\n");
+		RT_TRACE(COMP_ERR, "cam entry exceeds in %s\n", __func__);
 
 	RT_TRACE(COMP_SEC,
-		 "====>to setKey(), dev:%p, EntryNo:%d, KeyIndex:%d, KeyType:%d, MacAddr%pM\n",
-		 dev, EntryNo, KeyIndex, KeyType, MacAddr);
+		 "====>to %s, dev:%p, EntryNo:%d, KeyIndex:%d, KeyType:%d, MacAddr%pM\n",
+		 __func__, dev, EntryNo, KeyIndex, KeyType, MacAddr);
 
 	if (DefaultKey)
 		usConfig |= BIT(15) | (KeyType << 2);
-- 
2.20.1

[PATCH 2/2] staging: rtl8192u: Corrects 'Avoid CamelCase' for variables

[Camylla Goncalves Cantanheide]

The variables of function setKey triggered a 'Avoid CamelCase'
warning from checkpatch.pl. This patch renames these
variables to correct this warning.

Signed-off-by: Camylla Goncalves Cantanheide <c.cantanheide@gmail.com>
---
 drivers/staging/rtl8192u/r8192U_core.c | 52 +++++++++++++-------------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
index 93a15d57e..fcfb9024a 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4877,50 +4877,50 @@ void EnableHWSecurityConfig8192(struct net_device *dev)
 	write_nic_byte(dev, SECR,  SECR_value);
 }
 
-void setKey(struct net_device *dev, u8 EntryNo, u8 KeyIndex, u16 KeyType,
-	    u8 *MacAddr, u8 DefaultKey, u32 *KeyContent)
+void setKey(struct net_device *dev, u8 entryno, u8 keyindex, u16 keytype,
+	    u8 *macaddr, u8 defaultkey, u32 *keycontent)
 {
-	u32 TargetCommand = 0;
-	u32 TargetContent = 0;
-	u16 usConfig = 0;
+	u32 target_command = 0;
+	u32 target_content = 0;
+	u16 us_config = 0;
 	u8 i;
 
-	if (EntryNo >= TOTAL_CAM_ENTRY)
+	if (entryno >= TOTAL_CAM_ENTRY)
 		RT_TRACE(COMP_ERR, "cam entry exceeds in %s\n", __func__);
 
 	RT_TRACE(COMP_SEC,
 		 "====>to %s, dev:%p, EntryNo:%d, KeyIndex:%d, KeyType:%d, MacAddr%pM\n",
-		 __func__, dev, EntryNo, KeyIndex, KeyType, MacAddr);
+		 __func__, dev, entryno, keyindex, keytype, macaddr);
 
-	if (DefaultKey)
-		usConfig |= BIT(15) | (KeyType << 2);
+	if (defaultkey)
+		us_config |= BIT(15) | (keytype << 2);
 	else
-		usConfig |= BIT(15) | (KeyType << 2) | KeyIndex;
+		us_config |= BIT(15) | (keytype << 2) | keyindex;
 
 	for (i = 0; i < CAM_CONTENT_COUNT; i++) {
-		TargetCommand  = i + CAM_CONTENT_COUNT * EntryNo;
-		TargetCommand |= BIT(31) | BIT(16);
+		target_command  = i + CAM_CONTENT_COUNT * entryno;
+		target_command |= BIT(31) | BIT(16);
 
 		if (i == 0) { /* MAC|Config */
-			TargetContent = (u32)(*(MacAddr + 0)) << 16 |
-					(u32)(*(MacAddr + 1)) << 24 |
-					(u32)usConfig;
+			target_content = (u32)(*(macaddr + 0)) << 16 |
+					(u32)(*(macaddr + 1)) << 24 |
+					(u32)us_config;
 
-			write_nic_dword(dev, WCAMI, TargetContent);
-			write_nic_dword(dev, RWCAM, TargetCommand);
+			write_nic_dword(dev, WCAMI, target_content);
+			write_nic_dword(dev, RWCAM, target_command);
 		} else if (i == 1) { /* MAC */
-			TargetContent = (u32)(*(MacAddr + 2))	 |
-					(u32)(*(MacAddr + 3)) <<  8 |
-					(u32)(*(MacAddr + 4)) << 16 |
-					(u32)(*(MacAddr + 5)) << 24;
-			write_nic_dword(dev, WCAMI, TargetContent);
-			write_nic_dword(dev, RWCAM, TargetCommand);
+			target_content = (u32)(*(macaddr + 2))	 |
+					(u32)(*(macaddr + 3)) <<  8 |
+					(u32)(*(macaddr + 4)) << 16 |
+					(u32)(*(macaddr + 5)) << 24;
+			write_nic_dword(dev, WCAMI, target_content);
+			write_nic_dword(dev, RWCAM, target_command);
 		} else {
 			/* Key Material */
-			if (KeyContent) {
+			if (keycontent) {
 				write_nic_dword(dev, WCAMI,
-						*(KeyContent + i - 2));
-				write_nic_dword(dev, RWCAM, TargetCommand);
+						*(keycontent + i - 2));
+				write_nic_dword(dev, RWCAM, target_command);
 			}
 		}
 	}
-- 
2.20.1

Re: [PATCH 2/2] staging: rtl8192u: Corrects 'Avoid CamelCase' for variables

[Dan Carpenter]

On Tue, Mar 17, 2020 at 08:51:30AM +0000, Camylla Goncalves Cantanheide wrote:
> The variables of function setKey triggered a 'Avoid CamelCase'
> warning from checkpatch.pl. This patch renames these
> variables to correct this warning.
> 
> Signed-off-by: Camylla Goncalves Cantanheide <c.cantanheide@gmail.com>
> ---
>  drivers/staging/rtl8192u/r8192U_core.c | 52 +++++++++++++-------------
>  1 file changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
> index 93a15d57e..fcfb9024a 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -4877,50 +4877,50 @@ void EnableHWSecurityConfig8192(struct net_device *dev)
>  	write_nic_byte(dev, SECR,  SECR_value);
>  }
>  
> -void setKey(struct net_device *dev, u8 EntryNo, u8 KeyIndex, u16 KeyType,
> -	    u8 *MacAddr, u8 DefaultKey, u32 *KeyContent)
> +void setKey(struct net_device *dev, u8 entryno, u8 keyindex, u16 keytype,
> +	    u8 *macaddr, u8 defaultkey, u32 *keycontent)
>  {
> -	u32 TargetCommand = 0;
> -	u32 TargetContent = 0;
> -	u16 usConfig = 0;
> +	u32 target_command = 0;
> +	u32 target_content = 0;
> +	u16 us_config = 0;

Use these renames to think deeply about naming.

I don't like "entryno".  I would prefer "entry_no".  Use the same
underscore for spaces rule for key_index, mac_addr and all the rest.  Is
"key_idx" better or "key_index"?

What added value or meaning does the "target_" part of "target_command"
add?  Use "cmd" instead of "command".  "target_command" and
"target_content" are the same length and mostly the same letters.  Avoid
that sort of thing because it makes it hard to read at a glance.  The
two get swapped in your head.

What does the "us_" mean in us_config?  Is it microsecond as in usec?
Is it United states?  Actually it turns out it probably means "unsigned
short".  Never make the variable names show the type.  If you have a
good editor you can just hover the mouse over a variable to see the
type.  Or if you're using vim like me, then you have to use '*' to
highlight the variable and scroll to the top of the function.  Either
way, never use "us_" to mean unsigned short.

What does the "config" part of "us_config" mean?  What does the "content"
part of "target_content" mean?  Always think about that.  Variable names
are hard and maybe "config" and "content" are clear enough.  But at
think about it, and consider all the options.

Anyway, the reason that this patch needs to be re-written is because
we want underscores in place of spaces for "key_type" and because
"us_config" is against the rules.  The rest is just something to
consider and if you find better names, then go with that but if you
don't just fix those two things and resend.

regards,
dan carpenter

Re: [PATCH 2/2] staging: rtl8192u: Corrects 'Avoid CamelCase' for variables

[Joe Perches]

On Tue, 2020-03-17 at 16:43 +0300, Dan Carpenter wrote:
> On Tue, Mar 17, 2020 at 08:51:30AM +0000, Camylla Goncalves Cantanheide wrote:
> > The variables of function setKey triggered a 'Avoid CamelCase'
> > warning from checkpatch.pl. This patch renames these
> > variables to correct this warning.
> > 
> > Signed-off-by: Camylla Goncalves Cantanheide <c.cantanheide@gmail.com>
> > ---
> >  drivers/staging/rtl8192u/r8192U_core.c | 52 +++++++++++++-------------
> >  1 file changed, 26 insertions(+), 26 deletions(-)
> > 
> > diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
> > index 93a15d57e..fcfb9024a 100644
> > --- a/drivers/staging/rtl8192u/r8192U_core.c
> > +++ b/drivers/staging/rtl8192u/r8192U_core.c
> > @@ -4877,50 +4877,50 @@ void EnableHWSecurityConfig8192(struct net_device *dev)
> >  	write_nic_byte(dev, SECR,  SECR_value);
> >  }
> >  
> > -void setKey(struct net_device *dev, u8 EntryNo, u8 KeyIndex, u16 KeyType,
> > -	    u8 *MacAddr, u8 DefaultKey, u32 *KeyContent)
> > +void setKey(struct net_device *dev, u8 entryno, u8 keyindex, u16 keytype,
> > +	    u8 *macaddr, u8 defaultkey, u32 *keycontent)
> >  {
> > -	u32 TargetCommand = 0;
> > -	u32 TargetContent = 0;
> > -	u16 usConfig = 0;
> > +	u32 target_command = 0;
> > +	u32 target_content = 0;
> > +	u16 us_config = 0;
> 
> Use these renames to think deeply about naming.
> 
> I don't like "entryno".  I would prefer "entry_no".  Use the same
> underscore for spaces rule for key_index, mac_addr and all the rest.  Is
> "key_idx" better or "key_index"?
> 
> What added value or meaning does the "target_" part of "target_command"
> add?  Use "cmd" instead of "command".  "target_command" and
> "target_content" are the same length and mostly the same letters.  Avoid
> that sort of thing because it makes it hard to read at a glance.  The
> two get swapped in your head.
> 
> What does the "us_" mean in us_config?  Is it microsecond as in usec?
> Is it United states?  Actually it turns out it probably means "unsigned
> short".  Never make the variable names show the type.  If you have a
> good editor you can just hover the mouse over a variable to see the
> type.  Or if you're using vim like me, then you have to use '*' to
> highlight the variable and scroll to the top of the function.  Either
> way, never use "us_" to mean unsigned short.
> 
> What does the "config" part of "us_config" mean?  What does the "content"
> part of "target_content" mean?  Always think about that.  Variable names
> are hard and maybe "config" and "content" are clear enough.  But at
> think about it, and consider all the options.
> 
> Anyway, the reason that this patch needs to be re-written is because
> we want underscores in place of spaces for "key_type" and because
> "us_config" is against the rules.  The rest is just something to
> consider and if you find better names, then go with that but if you
> don't just fix those two things and resend.

What Dan said and:

Make sure to successfully compile the source files the patch
modifies before sending the patch.

Renaming function arguments and not renaming the uses of the
arguments in the function is not good.

Re: [PATCH 2/2] staging: rtl8192u: Corrects 'Avoid CamelCase' for variables

[Joe Perches]

On Wed, 2020-03-18 at 14:31 -0300, Camylla Cantanheide wrote:
> Dear Dan Carpenter and Joe Perches,
> 
> Thank you very much for the suggestions, I found the evaluation of both
> very significant. Now, I have another perspective on variables.
> 
> I solved the problem for the *setKey *function, however, when executing the
> checkpatch, more *Checks* of the same type appeared.
> 
> Should I send the second version of the patch, only to the *setKey*
> function or do I resolve all *Checks* for the entire file?

A single patch refactoring the function would be fine.

Also perhaps a name change as a separate patch later as
setKey is a relatively generic name and not obviously
specific to the rtl8192u..

Perhaps a first refactoring patch like the below
then a renaming one.

(untested)
---
 drivers/staging/rtl8192u/r8192U_core.c | 50 ++++++++++++++++------------------
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
index 89dd1fb..0c0cb08 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4880,7 +4880,7 @@ void EnableHWSecurityConfig8192(struct net_device *dev)
 void setKey(struct net_device *dev, u8 EntryNo, u8 KeyIndex, u16 KeyType,
 	    u8 *MacAddr, u8 DefaultKey, u32 *KeyContent)
 {
-	u32 TargetCommand = 0;
+	u32 TargetCommand = CAM_CONTENT_COUNT * EntryNo |  BIT(31) | BIT(16);
 	u32 TargetContent = 0;
 	u16 usConfig = 0;
 	u8 i;
@@ -4897,32 +4897,28 @@ void setKey(struct net_device *dev, u8 EntryNo, u8 KeyIndex, u16 KeyType,
 	else
 		usConfig |= BIT(15) | (KeyType << 2) | KeyIndex;
 
-	for (i = 0; i < CAM_CONTENT_COUNT; i++) {
-		TargetCommand  = i + CAM_CONTENT_COUNT * EntryNo;
-		TargetCommand |= BIT(31) | BIT(16);
-
-		if (i == 0) { /* MAC|Config */
-			TargetContent = (u32)(*(MacAddr + 0)) << 16 |
-					(u32)(*(MacAddr + 1)) << 24 |
-					(u32)usConfig;
-
-			write_nic_dword(dev, WCAMI, TargetContent);
-			write_nic_dword(dev, RWCAM, TargetCommand);
-		} else if (i == 1) { /* MAC */
-			TargetContent = (u32)(*(MacAddr + 2))	 |
-					(u32)(*(MacAddr + 3)) <<  8 |
-					(u32)(*(MacAddr + 4)) << 16 |
-					(u32)(*(MacAddr + 5)) << 24;
-			write_nic_dword(dev, WCAMI, TargetContent);
-			write_nic_dword(dev, RWCAM, TargetCommand);
-		} else {
-			/* Key Material */
-			if (KeyContent) {
-				write_nic_dword(dev, WCAMI,
-						*(KeyContent + i - 2));
-				write_nic_dword(dev, RWCAM, TargetCommand);
-			}
-		}
+	TargetContent = MacAddr[0] << 16 |
+			MacAddr[0] << 24 |
+			(u32)usConfig;
+
+	write_nic_dword(dev, WCAMI, TargetContent);
+	write_nic_dword(dev, RWCAM, TargetCommand++);
+
+	 /* MAC */
+	TargetContent = MacAddr[2]	 |
+			MacAddr[3] <<  8 |
+			MacAddr[4] << 16 |
+			MacAddr[5] << 24;
+	write_nic_dword(dev, WCAMI, TargetContent);
+	write_nic_dword(dev, RWCAM, TargetCommand++);
+
+	/* Key Material */
+	if (!KeyContent)
+		return;
+
+	for (i = 2; i < CAM_CONTENT_COUNT; i++) {
+		write_nic_dword(dev, WCAMI, *KeyContent++);
+		write_nic_dword(dev, RWCAM, TargetCommand++);
 	}
 }
 

Re: [PATCH 2/2] staging: rtl8192u: Corrects 'Avoid CamelCase' for variables

[Dan Carpenter]

On Wed, Mar 18, 2020 at 02:31:27PM -0300, Camylla Cantanheide wrote:
> Dear Dan Carpenter and Joe Perches,
> 
> Thank you very much for the suggestions, I found the evaluation of both
> very significant. Now, I have another perspective on variables.
> 
> I solved the problem for the *setKey *function, however, when executing the
> checkpatch, more *Checks* of the same type appeared.

If your changed introduces more warnings then you should fix them.  Like
say you rename variables and now the line goes over 80 characters, then
fix the new 80 character warning.  But if it was already over 80
characters then ignore the warning.

> 
> Should I send the second version of the patch, only to the *setKey*
> function or do I resolve all *Checks* for the entire file?

We want patches which are easy to review.  If you change everything in
the file, it will probably be too complicated for me to review.  So I
guess ignore those warnings.

regards,
dan carpenter