Re: [PATCH] staging: rtl8192e: cleanup coding style issues with spacing

[Philipp Hortmann]

On 10/31/22 23:51, Jerom van der Sar wrote:
> Fixed several coding style issues in rtl_cam.c such as double blank lines
> and lack of spaces around binary operators. It passes without trivial
> warnings about spaces. Some other warnings still remain.
>
> Signed-off-by: Jerom van der Sar <jerom.vandersar@xxxxxxxxx>
> ---
>   drivers/staging/rtl8192e/rtl8192e/rtl_cam.c | 25 +++++++++------------
>   1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_cam.c b/drivers/staging/rtl8192e/rtl8192e/rtl_cam.c
> index 41faeb4b9b9b..aeef735679db 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/rtl_cam.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/rtl_cam.c
> @@ -17,7 +17,7 @@ void rtl92e_cam_reset(struct net_device *dev)
>   {
>   	u32 ulcommand = 0;
>   
> -	ulcommand |= BIT31|BIT30;
> +	ulcommand |= BIT31 | BIT30;
>   	rtl92e_writel(dev, RWCAM, ulcommand);
>   }
>   
> @@ -40,7 +40,6 @@ void rtl92e_enable_hw_security_config(struct net_device *dev)
>   		SECR_value |= SCR_TxUseDK;
>   	}
>   
> -
>   	ieee->hwsec_active = 1;
>   	if ((ieee->pHTInfo->iot_action & HT_IOT_ACT_PURE_N_MODE) || !hwwep) {
>   		ieee->hwsec_active = 0;
> @@ -100,33 +99,32 @@ void rtl92e_set_key(struct net_device *dev, u8 EntryNo, u8 KeyIndex,
>   	}
>   
>   	if (DefaultKey)
> -		usConfig |= BIT15 | (KeyType<<2);
> +		usConfig |= BIT15 | (KeyType << 2);
>   	else
> -		usConfig |= BIT15 | (KeyType<<2) | KeyIndex;
> -
> +		usConfig |= BIT15 | (KeyType << 2) | KeyIndex;
>   
>   	for (i = 0; i < CAM_CONTENT_COUNT; i++) {
>   		TargetCommand  = i + CAM_CONTENT_COUNT * EntryNo;
> -		TargetCommand |= BIT31|BIT16;
> +		TargetCommand |= BIT31 | BIT16;
>   
>   		if (i == 0) {
> -			TargetContent = (u32)(*(MacAddr+0)) << 16 |
> -				(u32)(*(MacAddr+1)) << 24 |
> +			TargetContent = (u32)(*(MacAddr + 0)) << 16 |
> +				(u32)(*(MacAddr + 1)) << 24 |
>   				(u32)usConfig;
>   
>   			rtl92e_writel(dev, WCAMI, TargetContent);
>   			rtl92e_writel(dev, RWCAM, TargetCommand);
>   		} else if (i == 1) {
> -			TargetContent = (u32)(*(MacAddr+2)) |
> -				(u32)(*(MacAddr+3)) <<  8 |
> -				(u32)(*(MacAddr+4)) << 16 |
> -				(u32)(*(MacAddr+5)) << 24;
> +			TargetContent = (u32)(*(MacAddr + 2)) |
> +				(u32)(*(MacAddr + 3)) <<  8 |
> +				(u32)(*(MacAddr + 4)) << 16 |
> +				(u32)(*(MacAddr + 5)) << 24;
>   			rtl92e_writel(dev, WCAMI, TargetContent);
>   			rtl92e_writel(dev, RWCAM, TargetCommand);
>   		} else {
>   			if (KeyContent != NULL) {
>   				rtl92e_writel(dev, WCAMI,
> -					      (u32)(*(KeyContent+i-2)));
> +					      (u32)(*(KeyContent + i - 2)));
>   				rtl92e_writel(dev, RWCAM, TargetCommand);
>   				udelay(100);
>   			}
> @@ -152,7 +150,6 @@ void rtl92e_cam_restore(struct net_device *dev)
>   
>   	if ((priv->rtllib->pairwise_key_type == KEY_TYPE_WEP40) ||
>   	    (priv->rtllib->pairwise_key_type == KEY_TYPE_WEP104)) {
> -
>   		for (EntryId = 0; EntryId < 4; EntryId++) {
>   			MacAddr = CAM_CONST_ADDR[EntryId];
>   			if (priv->rtllib->swcamtable[EntryId].bused) {

Text from greg k-h's patch email bot:

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.

Comment PH: Try one simple patch first and then increase. Do not start 
with a series if you do not have any experience.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what is needed in order to
  properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/SubmittingPatches for what a proper Subject: line should
  look like.

Bye Philipp