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] [day] [month] [year] [list]
Message-ID: <9a10f72e-b5d6-7c9a-50d4-cc750454ff2b@gmail.com>
Date:   Mon, 1 Nov 2021 00:28:02 +0530
From:   Saurav Girepunje <saurav.girepunje@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     dan.carpenter@...cle.com, will+git@...d.me,
        mitaliborkar810@...il.com, eduard.vintila47@...il.com,
        zhaoxiao@...ontech.com, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org, saurav.girepunje@...mail.com,
        Pavel Skripkin <paskripkin@...il.com>
Subject: Re: [PATCH] staging: rtl8192e: remove condition with no effect



On 30/10/21 2:45 pm, Greg KH wrote:
> On Thu, Oct 28, 2021 at 12:04:43AM +0530, Saurav Girepunje wrote:
>> Remove the if and else code section for variable pHTInfo->bRegBW40MHz.
>> Just before the if condition variable is assign with value 1.
>> So if condition check for pHTInfo->bRegBW40MHz is always true.
>>
>> Similarly for the variable pHTInfo->SelfMimoPs value '3' is assign.
>> So if condition check with value '2' will never be true. Remove the
>> if condition check for pHTInfo->SelfMimoPs.
>>
>> Remove the extra blank lines from HTUpdateDefaultSetting function.
>>
>> Signed-off-by: Saurav Girepunje <saurav.girepunje@...il.com>
>> ---
>>  drivers/staging/rtl8192e/rtl819x_HTProc.c | 16 +---------------
>>  1 file changed, 1 insertion(+), 15 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c b/drivers/staging/rtl8192e/rtl819x_HTProc.c
>> index 3b8efaf9b88c..6925654dbc03 100644
>> --- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
>> +++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
>> @@ -72,34 +72,20 @@ void HTUpdateDefaultSetting(struct rtllib_device *ieee)
>>  	struct rt_hi_throughput *pHTInfo = ieee->pHTInfo;
>>
>>  	pHTInfo->bAcceptAddbaReq = 1;
>> -
>>  	pHTInfo->bRegShortGI20MHz = 1;
>>  	pHTInfo->bRegShortGI40MHz = 1;
>> -
>>  	pHTInfo->bRegBW40MHz = 1;
>> -
>> -	if (pHTInfo->bRegBW40MHz)
>> -		pHTInfo->bRegSuppCCK = 1;
>> -	else
>> -		pHTInfo->bRegSuppCCK = true;
>> -
>> +	pHTInfo->bRegSuppCCK = 1;
>>  	pHTInfo->nAMSDU_MaxSize = 7935UL;
>>  	pHTInfo->bAMSDU_Support = 0;
>> -
>>  	pHTInfo->bAMPDUEnable = 1;
>>  	pHTInfo->AMPDU_Factor = 2;
>>  	pHTInfo->MPDU_Density = 0;
>> -
>>  	pHTInfo->SelfMimoPs = 3;
>> -	if (pHTInfo->SelfMimoPs == 2)
>> -		pHTInfo->SelfMimoPs = 3;
>>  	ieee->bTxDisableRateFallBack = 0;
>>  	ieee->bTxUseDriverAssingedRate = 0;
>> -
>>  	ieee->bTxEnableFwCalcDur = 1;
>> -
>>  	pHTInfo->bRegRT2RTAggregation = 1;
>> -
>>  	pHTInfo->bRegRxReorderEnable = 1;
>>  	pHTInfo->RxReorderWinSize = 64;
>>  	pHTInfo->RxReorderPendingTime = 30;
>> --
>> 2.33.0
>>
>>
> 
> Hi,
> 
> This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
> a patch that has triggered this response.  He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created.  Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
> 
> You are receiving this message because of the following common error(s)
> as indicated below:
> 
> - 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.

> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
> 
> thanks,
> 
> greg k-h's patch email bot
> 

I will break this in multiple patch , One thing at a time.

Regards,
Saurav 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ