1. Patchew
  2. linux
  3. [PATCH 0/5] [Series 2] rename variable posHTCap and (4) others
  4. View patch

[PATCH 4/5] staging: rtl8192e: rename variable pHT

Gary Rookard posted 5 patches 2 years ago
[PATCH 4/5] staging: rtl8192e: rename variable pHT
Posted by Gary Rookard 2 years ago 
Coding style issue, Avoid CamelCase
rename it. pHT -> ht

Signed-off-by: Gary Rookard <garyrookard@fastmail.org>
---
 drivers/staging/rtl8192e/rtl819x_HTProc.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index ac85151a6069..add8f58b5b1e 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -250,17 +250,17 @@ void ht_reset_iot_setting(struct rt_hi_throughput *ht_info)
 void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
 				  u8 *len, u8 is_encrypt, bool assoc)
 {
-	struct rt_hi_throughput *pHT = ieee->ht_info;
+	struct rt_hi_throughput *ht = ieee->ht_info;
 	struct ht_capab_ele *pCapELE = NULL;
 
-	if (!pos_ht_cap || !pHT) {
+	if (!pos_ht_cap || !ht) {
 		netdev_warn(ieee->dev,
 			    "%s(): posHTCap and ht_info are null\n", __func__);
 		return;
 	}
 	memset(pos_ht_cap, 0, *len);
 
-	if ((assoc) && (pHT->ePeerHTSpecVer == HT_SPEC_VER_EWC)) {
+	if ((assoc) && (ht->ePeerHTSpecVer == HT_SPEC_VER_EWC)) {
 		static const u8	EWC11NHTCap[] = { 0x00, 0x90, 0x4c, 0x33 };
 
 		memcpy(pos_ht_cap, EWC11NHTCap, sizeof(EWC11NHTCap));
@@ -275,9 +275,9 @@ void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
 	if (ieee->GetHalfNmodeSupportByAPsHandler(ieee->dev))
 		pCapELE->ChlWidth = 0;
 	else
-		pCapELE->ChlWidth = (pHT->reg_bw_40mhz ? 1 : 0);
+		pCapELE->ChlWidth = (ht->reg_bw_40mhz ? 1 : 0);
 
-	pCapELE->MimoPwrSave		= pHT->self_mimo_ps;
+	pCapELE->MimoPwrSave		= ht->self_mimo_ps;
 	pCapELE->GreenField		= 0;
 	pCapELE->ShortGI20Mhz		= 1;
 	pCapELE->ShortGI40Mhz		= 1;
@@ -286,7 +286,7 @@ void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
 	pCapELE->RxSTBC			= 0;
 	pCapELE->DelayBA		= 0;
 	pCapELE->MaxAMSDUSize = (MAX_RECEIVE_BUFFER_SIZE >= 7935) ? 1 : 0;
-	pCapELE->DssCCk = ((pHT->reg_bw_40mhz) ? (pHT->reg_supp_cck ? 1 : 0) : 0);
+	pCapELE->DssCCk = ((ht->reg_bw_40mhz) ? (ht->reg_supp_cck ? 1 : 0) : 0);
 	pCapELE->PSMP = 0;
 	pCapELE->LSigTxopProtect = 0;
 
@@ -309,16 +309,16 @@ void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
 	pCapELE->ASCap = 0;
 
 	if (assoc) {
-		if (pHT->iot_action & HT_IOT_ACT_DISABLE_MCS15)
+		if (ht->iot_action & HT_IOT_ACT_DISABLE_MCS15)
 			pCapELE->MCS[1] &= 0x7f;
 
-		if (pHT->iot_action & HT_IOT_ACT_DISABLE_MCS14)
+		if (ht->iot_action & HT_IOT_ACT_DISABLE_MCS14)
 			pCapELE->MCS[1] &= 0xbf;
 
-		if (pHT->iot_action & HT_IOT_ACT_DISABLE_ALL_2SS)
+		if (ht->iot_action & HT_IOT_ACT_DISABLE_ALL_2SS)
 			pCapELE->MCS[1] &= 0x00;
 
-		if (pHT->iot_action & HT_IOT_ACT_DISABLE_RX_40MHZ_SHORT_GI)
+		if (ht->iot_action & HT_IOT_ACT_DISABLE_RX_40MHZ_SHORT_GI)
 			pCapELE->ShortGI40Mhz		= 0;
 
 		if (ieee->GetHalfNmodeSupportByAPsHandler(ieee->dev)) {
-- 
2.41.0
Re: [PATCH 4/5] staging: rtl8192e: rename variable pHT
Posted by Philipp Hortmann 2 years ago 
On 12/12/23 17:56, Gary Rookard wrote:
> oding style issue, Avoid CamelCase
> rename it. pHT -> ht
> 
> Signed-off-by: Gary Rookard<garyrookard@fastmail.org>
> ---
>   drivers/staging/rtl8192e/rtl819x_HTProc.c | 20 ++++++++++----------
>   1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> index ac85151a6069..add8f58b5b1e 100644
> --- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
> +++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> @@ -250,17 +250,17 @@ void ht_reset_iot_setting(struct rt_hi_throughput *ht_info)
>   void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
>   				  u8 *len, u8 is_encrypt, bool assoc)
>   {
> -	struct rt_hi_throughput *pHT = ieee->ht_info;
> +	struct rt_hi_throughput *ht = ieee->ht_info;
>   	struct ht_capab_ele *pCapELE = NULL;
>   
> -	if (!pos_ht_cap || !pHT) {
> +	if (!pos_ht_cap || !ht) {
>   		netdev_warn(ieee->dev,
>   			    "%s(): posHTCap and ht_info are null\n", __func__);
>   		return;
>   	}
>   	memset(pos_ht_cap, 0, *len);
>   
> -	if ((assoc) && (pHT->ePeerHTSpecVer == HT_SPEC_VER_EWC)) {
> +	if ((assoc) && (ht->ePeerHTSpecVer == HT_SPEC_VER_EWC)) {
>   		static const u8	EWC11NHTCap[] = { 0x00, 0x90, 0x4c, 0x33 };
>   
>   		memcpy(pos_ht_cap, EWC11NHTCap, sizeof(EWC11NHTCap));
> @@ -275,9 +275,9 @@ void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
>   	if (ieee->GetHalfNmodeSupportByAPsHandler(ieee->dev))
>   		pCapELE->ChlWidth = 0;
>   	else
> -		pCapELE->ChlWidth = (pHT->reg_bw_40mhz ? 1 : 0);
> +		pCapELE->ChlWidth = (ht->reg_bw_40mhz ? 1 : 0);

The last line changed with my patch:
[PATCH 02/10] staging: rtl8192e: Remove variable ht_info->reg_bw_40mhz

It is always difficult to know which patches are accepted by the 
maintainer but you may want to look into the following mailing list to 
see if there have been any patches send in for this driver.
https://lore.kernel.org/linux-staging/

You could apply the send in patches and build your ones on top. Then you 
do not have this issue. But when the patches you are using are not 
accepted you will run into the same issues.

Thanks for your support.

Bye Philipp
Re: [PATCH 4/5] staging: rtl8192e: rename variable pHT
Posted by Dan Carpenter 2 years ago 
On Tue, Dec 12, 2023 at 07:56:57PM +0100, Philipp Hortmann wrote:
> On 12/12/23 17:56, Gary Rookard wrote:
> > oding style issue, Avoid CamelCase
> > rename it. pHT -> ht
> > 
> > Signed-off-by: Gary Rookard<garyrookard@fastmail.org>
> > ---
> >   drivers/staging/rtl8192e/rtl819x_HTProc.c | 20 ++++++++++----------
> >   1 file changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > index ac85151a6069..add8f58b5b1e 100644
> > --- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > +++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
> > @@ -250,17 +250,17 @@ void ht_reset_iot_setting(struct rt_hi_throughput *ht_info)
> >   void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
> >   				  u8 *len, u8 is_encrypt, bool assoc)
> >   {
> > -	struct rt_hi_throughput *pHT = ieee->ht_info;
> > +	struct rt_hi_throughput *ht = ieee->ht_info;
> >   	struct ht_capab_ele *pCapELE = NULL;
> > -	if (!pos_ht_cap || !pHT) {
> > +	if (!pos_ht_cap || !ht) {
> >   		netdev_warn(ieee->dev,
> >   			    "%s(): posHTCap and ht_info are null\n", __func__);
> >   		return;
> >   	}
> >   	memset(pos_ht_cap, 0, *len);
> > -	if ((assoc) && (pHT->ePeerHTSpecVer == HT_SPEC_VER_EWC)) {
> > +	if ((assoc) && (ht->ePeerHTSpecVer == HT_SPEC_VER_EWC)) {
> >   		static const u8	EWC11NHTCap[] = { 0x00, 0x90, 0x4c, 0x33 };
> >   		memcpy(pos_ht_cap, EWC11NHTCap, sizeof(EWC11NHTCap));
> > @@ -275,9 +275,9 @@ void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
> >   	if (ieee->GetHalfNmodeSupportByAPsHandler(ieee->dev))
> >   		pCapELE->ChlWidth = 0;
> >   	else
> > -		pCapELE->ChlWidth = (pHT->reg_bw_40mhz ? 1 : 0);
> > +		pCapELE->ChlWidth = (ht->reg_bw_40mhz ? 1 : 0);
> 
> The last line changed with my patch:
> [PATCH 02/10] staging: rtl8192e: Remove variable ht_info->reg_bw_40mhz
> 
> It is always difficult to know which patches are accepted by the maintainer
> but you may want to look into the following mailing list to see if there
> have been any patches send in for this driver.
> https://lore.kernel.org/linux-staging/
> 
> You could apply the send in patches and build your ones on top. Then you do
> not have this issue. But when the patches you are using are not accepted you
> will run into the same issues.

Generally, it's first come, first serve.  For you, your patches have
a 95% chance of being merged.

regards,
dan carpenter
Re: [PATCH 4/5] staging: rtl8192e: rename variable pHT
Posted by Gary Rookard 2 years ago 
Philipp Hortmann <philipp.g.hortmann@gmail.com> writes:

> On 12/12/23 17:56, Gary Rookard wrote:
>> oding style issue, Avoid CamelCase
>> rename it. pHT -> ht
>> Signed-off-by: Gary Rookard<garyrookard@fastmail.org>
>> ---
>>   drivers/staging/rtl8192e/rtl819x_HTProc.c | 20 ++++++++++----------
>>   1 file changed, 10 insertions(+), 10 deletions(-)
>> diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
>> b/drivers/staging/rtl8192e/rtl819x_HTProc.c
>> index ac85151a6069..add8f58b5b1e 100644
>> --- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
>> +++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
>> @@ -250,17 +250,17 @@ void ht_reset_iot_setting(struct rt_hi_throughput *ht_info)
>>   void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
>>   				  u8 *len, u8 is_encrypt, bool assoc)
>>   {
>> -	struct rt_hi_throughput *pHT = ieee->ht_info;
>> +	struct rt_hi_throughput *ht = ieee->ht_info;
>>   	struct ht_capab_ele *pCapELE = NULL;
>>   -	if (!pos_ht_cap || !pHT) {
>> +	if (!pos_ht_cap || !ht) {
>>   		netdev_warn(ieee->dev,
>>   			    "%s(): posHTCap and ht_info are null\n", __func__);
>>   		return;
>>   	}
>>   	memset(pos_ht_cap, 0, *len);
>>   -	if ((assoc) && (pHT->ePeerHTSpecVer == HT_SPEC_VER_EWC)) {
>> +	if ((assoc) && (ht->ePeerHTSpecVer == HT_SPEC_VER_EWC)) {
>>   		static const u8	EWC11NHTCap[] = { 0x00, 0x90, 0x4c, 0x33 };
>>     		memcpy(pos_ht_cap, EWC11NHTCap, sizeof(EWC11NHTCap));
>> @@ -275,9 +275,9 @@ void ht_construct_capability_element(struct rtllib_device *ieee, u8 *pos_ht_cap,
>>   	if (ieee->GetHalfNmodeSupportByAPsHandler(ieee->dev))
>>   		pCapELE->ChlWidth = 0;
>>   	else
>> -		pCapELE->ChlWidth = (pHT->reg_bw_40mhz ? 1 : 0);
>> +		pCapELE->ChlWidth = (ht->reg_bw_40mhz ? 1 : 0);
>
> The last line changed with my patch:
> [PATCH 02/10] staging: rtl8192e: Remove variable ht_info->reg_bw_40mhz
>
> It is always difficult to know which patches are accepted by the
> maintainer but you may want to look into the following mailing list to
> see if there have been any patches send in for this driver.
> https://lore.kernel.org/linux-staging/
>
> You could apply the send in patches and build your ones on top. Then
> you do not have this issue. But when the patches you are using are not
> accepted you will run into the same issues.
>
> Thanks for your support.
>
> Bye Philipp

Okay, no problem.

Regards,
Gary

-- 
Sent with my mu4e on Gentoo GNU/linux.

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.