Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-22 Thread Chris Opperman
Okay, in that case I will fix and resend the patch.

Kind Regards,
Chris Opperman


Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-22 Thread Chris Opperman
Okay, in that case I will fix and resend the patch.

Kind Regards,
Chris Opperman


Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-22 Thread Dan Carpenter
I liked the patch, but just go over the 80 character limit instead of
adding a "key" variable.  It's better that it generate a checkpatch
warning and forces someone to rename the variable...

regards,
dan carpenter




Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-22 Thread Dan Carpenter
I liked the patch, but just go over the 80 character limit instead of
adding a "key" variable.  It's better that it generate a checkpatch
warning and forces someone to rename the variable...

regards,
dan carpenter




Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-21 Thread Chris Opperman
Hi Dan,
The header also states "DO NOT EDIT OR MODIFY". As you suggested, I
will rather leave this patch for now.

P.S. Please advise if there is anything specific I can help out with, or I'll 
keep looking for more obvious fixes I can make while I'm learning the
ropes.
Kind Regards,
Chris Opperman


Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-21 Thread Chris Opperman
Hi Dan,
The header also states "DO NOT EDIT OR MODIFY". As you suggested, I
will rather leave this patch for now.

P.S. Please advise if there is anything specific I can help out with, or I'll 
keep looking for more obvious fixes I can make while I'm learning the
ropes.
Kind Regards,
Chris Opperman


Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-21 Thread Dan Carpenter
On Thu, Jun 21, 2018 at 06:42:52AM +0200, Chris Opperman wrote:
> Hi Dan,
> 
> I agree completely. I was concerned whether the preprocessor definitions in
> p80211metadef.h were named according to some convention as there are
> many definitions named similarly there.
> 

Yeah, sure but in that case leave this code alone until we get the time
to update all the definitions.

> I am considering renaming this specific definition to "p80211_dot11_keyid",
> would that be more acceptable?

There is probably a normal define that wireless drivers already use, but
I don't know networking enough to say what it is...  You should try
asking on linux-wireless.

It says in the header that the name is generated automatically?  Is that
true?  How does that work?

Probably it's better to make it upper case?  Are both the P80211 and the
DOT11 required or is DOT11 a subset?  Anyway, I don't think it's
possible to create a worse naming scheme than the driver already has so
I'm likely to approve anything you send.

regards,
dan carpenter



Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-21 Thread Dan Carpenter
On Thu, Jun 21, 2018 at 06:42:52AM +0200, Chris Opperman wrote:
> Hi Dan,
> 
> I agree completely. I was concerned whether the preprocessor definitions in
> p80211metadef.h were named according to some convention as there are
> many definitions named similarly there.
> 

Yeah, sure but in that case leave this code alone until we get the time
to update all the definitions.

> I am considering renaming this specific definition to "p80211_dot11_keyid",
> would that be more acceptable?

There is probably a normal define that wireless drivers already use, but
I don't know networking enough to say what it is...  You should try
asking on linux-wireless.

It says in the header that the name is generated automatically?  Is that
true?  How does that work?

Probably it's better to make it upper case?  Are both the P80211 and the
DOT11 required or is DOT11 a subset?  Anyway, I don't think it's
possible to create a worse naming scheme than the driver already has so
I'm likely to approve anything you send.

regards,
dan carpenter



Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-20 Thread Chris Opperman
Hi Dan,

I agree completely. I was concerned whether the preprocessor definitions in
p80211metadef.h were named according to some convention as there are
many definitions named similarly there. 

I am considering renaming this specific definition to "p80211_dot11_keyid", 
would that be more acceptable?

Kind Regards,
Chris Opperman


Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-20 Thread Chris Opperman
Hi Dan,

I agree completely. I was concerned whether the preprocessor definitions in
p80211metadef.h were named according to some convention as there are
many definitions named similarly there. 

I am considering renaming this specific definition to "p80211_dot11_keyid", 
would that be more acceptable?

Kind Regards,
Chris Opperman


Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-20 Thread Dan Carpenter
On Wed, Jun 20, 2018 at 07:10:26PM +0200, Chris Opperman wrote:
> b) Added temporary "key" variable to reduce line length.

No, that's nonsense.  Just fix the original variable so that it's not a
million characters long.

Using a shorter variable is good if it simplifies the code like so:

struct foo *foo = >random_variable[INDEX].whatever;

You've reduced 4 variable names and a butt load of punctuation down to
just "foo" so that we don't have to look at it repeated over and over
on every line.

But if you're just using a temporary variable because the original
variable name was poorly chosen, that's not the right thing.

regards,
dan carpenter



Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key

2018-06-20 Thread Dan Carpenter
On Wed, Jun 20, 2018 at 07:10:26PM +0200, Chris Opperman wrote:
> b) Added temporary "key" variable to reduce line length.

No, that's nonsense.  Just fix the original variable so that it's not a
million characters long.

Using a shorter variable is good if it simplifies the code like so:

struct foo *foo = >random_variable[INDEX].whatever;

You've reduced 4 variable names and a butt load of punctuation down to
just "foo" so that we don't have to look at it repeated over and over
on every line.

But if you're just using a temporary variable because the original
variable name was poorly chosen, that's not the right thing.

regards,
dan carpenter