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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7d001a49-4e45-fda2-15fe-b05f2c340eaa@gmail.com>
Date:   Tue, 1 Nov 2022 00:07:39 +0100
From:   Philipp Hortmann <philipp.g.hortmann@...il.com>
To:     Jerom van der Sar <jerom.vandersar@...il.com>,
        gregkh@...uxfoundation.org
Cc:     philip.g.hortmann@...il.com, error27@...il.com,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: rtl8192e: cleanup coding style issues with
 spacing

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@...il.com>
> ---
>   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