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

[Dan Carpenter]

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@xxxxxxxxxxxx>
> > ---
> >   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