Re: RTL8723BE performance regression

[Pkshih]

On Wed, 2018-05-09 at 13:33 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 8, 2018 at 1:37 AM, Pkshih <pks...@realtek.com> wrote:
> > On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> >> On Tue, May 1, 2018 at 10:58 PM, Pkshih <pks...@realtek.com> wrote:
> >> > On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> >> >>
> >> >> > -Original Message-
> >> >> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> >> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> >> > To: Larry Finger
> >> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> >> >> > Chaoming_Li; Kalle
> Valo;
> >> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo 
> >> >> > Rechi Vita; linux@endl
> ess
> >> m.c
> >> >> om
> >> >> > Subject: Re: RTL8723BE performance regression
> >> >> >
> >> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger 
> >> >> > <larry.fin...@lwfinger.net> wrote:
> >> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> >> > >>
> >> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> >> >> > >> <larry.fin...@lwfinger.net>
> >> >> > >> wrote:
> >> >> > >>
> >> >> > >> (...)
> >> >> > >>
> >> >> > >>> As the antenna selection code changes affected your first 
> >> >> > >>> bisection, do
> >> >> > >>> you
> >> >> > >>> have one of those HP laptops with only one antenna and the 
> >> >> > >>> incorrect
> >> >> > >>> coding
> >> >> > >>> in the FUSE?
> >> >> > >>
> >> >> > >>
> >> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- 
> >> >> > >> this
> >> >> > >> was needed to achieve a good performance in the past, before this
> >> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> >> > >> card.
> >> >> > >>
> >> >> > >>> If so, please make sure that you still have the same signal
> >> >> > >>> strength for good and bad cases. I have tried to keep the driver 
> >> >> > >>> and the
> >> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> >> > >>>
> >> >> > >>
> >> >> > >> What is the recommended way to monitor the signal strength?
> >> >> > >
> >> >> > >
> >> >> > > The btcoex code is developed for multiple platforms by a different 
> >> >> > > group
> >> >> > > than the Linux driver. I think they made a change that caused 
> >> >> > > ant_sel to
> >> >> > > switch from 1 to 2. At least numerous comments at
> >> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that 
> >> >> > > change.
> >> >> > >
> >> >> > > Mhy recommended method is to verify the wifi device name with "iw 
> >> >> > > dev". Then
> >> >> > > using that device
> >> >> > >
> >> >> > > sudo iw dev  scan | egrep "SSID|signal"
> >> >> > >
> >> >> >
> >> >> > I have confirmed that the performance regression is indeed tied to
> >> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> >> > also switched to testing bandwidth in controlled LAN environment using
> >> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> >> > i

Re: RTL8723BE performance regression

[Pkshih]

On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 1, 2018 at 10:58 PM, Pkshih <pks...@realtek.com> wrote:
> > On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> >>
> >> > -Original Message-
> >> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> > To: Larry Finger
> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> >> > Chaoming_Li; Kalle Valo;
> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo 
> >> > Rechi Vita; linux@endless
> m.c
> >> om
> >> > Subject: Re: RTL8723BE performance regression
> >> >
> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <larry.fin...@lwfinger.net> 
> >> > wrote:
> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> > >>
> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> >> > >> <larry.fin...@lwfinger.net>
> >> > >> wrote:
> >> > >>
> >> > >> (...)
> >> > >>
> >> > >>> As the antenna selection code changes affected your first bisection, 
> >> > >>> do
> >> > >>> you
> >> > >>> have one of those HP laptops with only one antenna and the incorrect
> >> > >>> coding
> >> > >>> in the FUSE?
> >> > >>
> >> > >>
> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> > >> was needed to achieve a good performance in the past, before this
> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> > >> card.
> >> > >>
> >> > >>> If so, please make sure that you still have the same signal
> >> > >>> strength for good and bad cases. I have tried to keep the driver and 
> >> > >>> the
> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> > >>>
> >> > >>
> >> > >> What is the recommended way to monitor the signal strength?
> >> > >
> >> > >
> >> > > The btcoex code is developed for multiple platforms by a different 
> >> > > group
> >> > > than the Linux driver. I think they made a change that caused ant_sel 
> >> > > to
> >> > > switch from 1 to 2. At least numerous comments at
> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that 
> >> > > change.
> >> > >
> >> > > Mhy recommended method is to verify the wifi device name with "iw 
> >> > > dev". Then
> >> > > using that device
> >> > >
> >> > > sudo iw dev  scan | egrep "SSID|signal"
> >> > >
> >> >
> >> > I have confirmed that the performance regression is indeed tied to
> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> > also switched to testing bandwidth in controlled LAN environment using
> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> > iperf3 server connected via ethernet.
> >> >
> >>
> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: 
> >> cleanup
> >> 8723be ant_sel definition"). You can use the above commit and do the same
> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your 
> >> results.
> >> Since performance is tied to signal strength, you can only share signal 
> >> strength.
> >>
> >
> > Please pay attention to cold reboot once ant_sel is changed.
> >
> 
> I've tested the commit mentioned above and it fixes the problem on top
> of v4.16 (in addition to the latest wireless-drivers-next also been
> fixed as it already contains such commit). On v4.15, we also need the
> following commits before "af8a41cccf8f rtlwifi: c

Re: RTL8723BE performance regression

[Pkshih]

On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> 
> > -Original Message-
> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> > Sent: Wednesday, May 02, 2018 6:41 AM
> > To: Larry Finger
> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> > Chaoming_Li; Kalle Valo;
> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi 
> > Vita; linux@endlessm.c
> om
> > Subject: Re: RTL8723BE performance regression
> > 
> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <larry.fin...@lwfinger.net> 
> > wrote:
> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> > >>
> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <larry.fin...@lwfinger.net>
> > >> wrote:
> > >>
> > >> (...)
> > >>
> > >>> As the antenna selection code changes affected your first bisection, do
> > >>> you
> > >>> have one of those HP laptops with only one antenna and the incorrect
> > >>> coding
> > >>> in the FUSE?
> > >>
> > >>
> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> > >> was needed to achieve a good performance in the past, before this
> > >> regression. I've also opened the laptop chassis and confirmed the
> > >> antenna cable is plugged to the connector labeled with "1" on the
> > >> card.
> > >>
> > >>> If so, please make sure that you still have the same signal
> > >>> strength for good and bad cases. I have tried to keep the driver and the
> > >>> btcoex code in sync, but there may be some combinations of antenna
> > >>> configuration and FUSE contents that cause the code to fail.
> > >>>
> > >>
> > >> What is the recommended way to monitor the signal strength?
> > >
> > >
> > > The btcoex code is developed for multiple platforms by a different group
> > > than the Linux driver. I think they made a change that caused ant_sel to
> > > switch from 1 to 2. At least numerous comments at
> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> > >
> > > Mhy recommended method is to verify the wifi device name with "iw dev". 
> > > Then
> > > using that device
> > >
> > > sudo iw dev  scan | egrep "SSID|signal"
> > >
> > 
> > I have confirmed that the performance regression is indeed tied to
> > signal strength: on the good cases signal was between -16 and -8 dBm,
> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> > also switched to testing bandwidth in controlled LAN environment using
> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> > machine connected to the 2.4 GHz radio and the machine running the
> > iperf3 server connected via ethernet.
> > 
> 
> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup 
> 8723be ant_sel definition"). You can use the above commit and do the same 
> experiments (with ant_sel=0, 1 and 2) in your side, and then share your 
> results.
> Since performance is tied to signal strength, you can only share signal 
> strength.
> 

Please pay attention to cold reboot once ant_sel is changed.

RE: RTL8723BE performance regression

[Pkshih]

> -Original Message-
> From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> Sent: Wednesday, May 02, 2018 6:41 AM
> To: Larry Finger
> Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> Chaoming_Li; Kalle Valo;
> linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi 
> Vita; li...@endlessm.com
> Subject: Re: RTL8723BE performance regression
> 
> On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <larry.fin...@lwfinger.net> 
> wrote:
> > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >>
> >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <larry.fin...@lwfinger.net>
> >> wrote:
> >>
> >> (...)
> >>
> >>> As the antenna selection code changes affected your first bisection, do
> >>> you
> >>> have one of those HP laptops with only one antenna and the incorrect
> >>> coding
> >>> in the FUSE?
> >>
> >>
> >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> was needed to achieve a good performance in the past, before this
> >> regression. I've also opened the laptop chassis and confirmed the
> >> antenna cable is plugged to the connector labeled with "1" on the
> >> card.
> >>
> >>> If so, please make sure that you still have the same signal
> >>> strength for good and bad cases. I have tried to keep the driver and the
> >>> btcoex code in sync, but there may be some combinations of antenna
> >>> configuration and FUSE contents that cause the code to fail.
> >>>
> >>
> >> What is the recommended way to monitor the signal strength?
> >
> >
> > The btcoex code is developed for multiple platforms by a different group
> > than the Linux driver. I think they made a change that caused ant_sel to
> > switch from 1 to 2. At least numerous comments at
> > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> >
> > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> > using that device
> >
> > sudo iw dev  scan | egrep "SSID|signal"
> >
> 
> I have confirmed that the performance regression is indeed tied to
> signal strength: on the good cases signal was between -16 and -8 dBm,
> whereas in bad cases signal was always between -50 to - 40 dBm. I've
> also switched to testing bandwidth in controlled LAN environment using
> iperf3, as suggested by Steve deRosier, with the DUT being the only
> machine connected to the 2.4 GHz radio and the machine running the
> iperf3 server connected via ethernet.
> 

We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup 
8723be ant_sel definition"). You can use the above commit and do the same 
experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
Since performance is tied to signal strength, you can only share signal 
strength.

Regards
PK

Re: [rtlwifi-btcoex] Suspicious code in halbtc8821a1ant driver

[Pkshih]

On Thu, 2018-04-05 at 01:25 +, Gustavo A. R. Silva wrote:
> Hi all,
> 
> While doing some static analysis I came across the following piece of code at
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:1581:
> 
> 1581 static void btc8821a1ant_act_bt_sco_hid_only_busy(struct btc_coexist 
> *btcoexist,
> 1582   u8 wifi_status)
> 1583 {
> 1584 /* tdma and coex table */
> 1585 btc8821a1ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 5);
> 1586 
> 1587 if (BT_8821A_1ANT_WIFI_STATUS_NON_CONNECTED_ASSO_AUTH_SCAN ==
> 1588 wifi_status)
> 1589 btc8821a1ant_coex_table_with_type(btcoexist, 
> NORMAL_EXEC, 1);
> 1590 else
> 1591 btc8821a1ant_coex_table_with_type(btcoexist, 
> NORMAL_EXEC, 1);
> 1592 }
> 
> The issue here is that the code for both branches of the if-else statement is 
> identical.
> 
> The if-else was introduced a year ago in this commit c6821613e653
> 
> I wonder if an argument should be changed in any of the calls to
> btc8821a1ant_coex_table_with_type?
> 
> 

It looks weird. Since we're in spring vacation, I'll check my colleague next 
Monday.

PK

Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address

[Pkshih]

On Sat, 2018-03-31 at 00:05 -0700, Joe Perches wrote:
> Use the new ether_broadcast_addr global instead to save some object code.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/net/wireless/admtek/adm8211.c   | 3 +--
>  drivers/net/wireless/ath/carl9170/mac.c | 4 +---
>  drivers/net/wireless/broadcom/b43/main.c| 3 +--
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 3 +--
>  drivers/net/wireless/realtek/rtlwifi/core.c | 5 ++---
>  drivers/net/wireless/rndis_wlan.c   | 6 +-
>  drivers/net/wireless/ti/wl1251/main.c   | 5 +
>  drivers/net/wireless/ti/wlcore/main.c   | 5 +
>  8 files changed, 9 insertions(+), 25 deletions(-)
> 
>  
> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
> b/drivers/net/wireless/realtek/rtlwifi/core.c
> index cfea57efa7f4..8c534a93dad5 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> @@ -1527,7 +1527,6 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   bool wep_only = false;
>   int err = 0;
>   u8 mac_addr[ETH_ALEN];
> - u8 bcast_addr[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
>  
>   rtlpriv->btcoexist.btc_info.in_4way = false;
>  
> @@ -1544,7 +1543,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
>    "%s hardware based encryption for keyidx: %d, mac: %pM\n",
>     cmd == SET_KEY ? "Using" : "Disabling", key->keyidx,
> -   sta ? sta->addr : bcast_addr);
> +   sta ? sta->addr : ether_broadcast_addr);
>   rtlpriv->sec.being_setkey = true;
>   rtl_ips_nic_on(hw);
>   mutex_lock(>locks.conf_mutex);
> @@ -1649,7 +1648,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   memcpy(rtlpriv->sec.key_buf[key_idx],
>      key->key, key->keylen);
>   rtlpriv->sec.key_len[key_idx] = key->keylen;
> - memcpy(mac_addr, bcast_addr, ETH_ALEN);
> + memcpy(mac_addr, ether_broadcast_addr, ETH_ALEN);

Use ether_addr_copy(mac_addr, ether_broadcast_addr) ?


>   } else {/* pairwise key */
>   RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
>    "set pairwise key\n");

Re: [PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

[Pkshih]

On Wed, 2018-02-07 at 12:51 -0800, Matthias Kaehlcke wrote:
> El Wed, Feb 07, 2018 at 02:35:59PM -0600 Larry Finger ha dit:
> 
> > On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote:
> > > In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
> > > is assigned to itself in an if ... else statement, apparently only to
> > > document that the branch condition is handled and that a previously read
> > > value should be returned unmodified. The self-assignment causes clang to
> > > raise the following warning:
> > > 
> > > drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
> > >error: explicitly assigning value of variable of type 'u32'
> > >  (aka 'unsigned int') to itself [-Werror,-Wself-assign]
> > >writeVal = writeVal;
> > > 
> > > Replace the self-assignment with a semicolon, which still serves to
> > > document the 'handling' of the branch condition.
> > > 
> > > Signed-off-by: Matthias Kaehlcke 
> > > ---
> > >   drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > index 9cff6bc4049c..4db92496c122 100644
> > > --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > @@ -301,7 +301,7 @@ static void 
> > > _rtl92c_get_txpower_writeval_by_regulatory(struct ieee80211_hw
> *hw,
> > >   writeVal = writeVal - 0x06060606;
> > >   else if (rtlpriv->dm.dynamic_txhighpower_lvl ==
> > >    TXHIGHPWRLEVEL_BT2)
> > > - writeVal = writeVal;
> > > + ;
> > >   *(p_outwriteval + rf) = writeVal;
> > >   }
> > >   }
> > > 
> > 
> > As the branch condition does nothing, why not remove it and save the
> > compiler's optimizer a bit of work? The code looks strange, but it matches
> > the rest of Realtek's USB drivers.

Agree Larry's comment.

> 
> Sure, I am happy to change it to whatever the authors/maintainers prefer.
> 
> I'll wait a bit before respinning for if others feel strongly about
> keeping the branch.
> 
> --Please consider the environment before printing this e-mail.

[PATCH] rtlwifi: Remove seq_number from rtl_tid_data

[pkshih]

From: Ping-Ke Shih 

Since mac80211 maintains the sequence number for each STA/TID,
driver doesn't need to maintain a copy.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c |  6 ++
 drivers/net/wireless/realtek/rtlwifi/pci.c  | 17 -
 drivers/net/wireless/realtek/rtlwifi/usb.c  | 17 -
 drivers/net/wireless/realtek/rtlwifi/wifi.h |  1 -
 4 files changed, 2 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 0b34886321f1..9f35b25bddf2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1618,9 +1618,8 @@ int rtl_tx_agg_start(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 
RT_TRACE(rtlpriv, COMP_SEND, DBG_DMESG,
 "on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
-tid_data->seq_number);
+*ssn);
 
-   *ssn = tid_data->seq_number;
tid_data->agg.agg_state = RTL_AGG_START;
 
ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);
@@ -1679,8 +1678,7 @@ int rtl_rx_agg_start(struct ieee80211_hw *hw,
tid_data = _entry->tids[tid];
 
RT_TRACE(rtlpriv, COMP_RECV, DBG_DMESG,
-"on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
-tid_data->seq_number);
+"on ra = %pM tid = %d\n", sta->addr, tid);
 
tid_data->agg.rx_agg_state = RTL_RX_AGG_START;
return 0;
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index b9a6d23364be..eb12818b46b3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1623,7 +1623,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
  struct rtl_tcb_desc *ptcb_desc)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_sta_info *sta_entry = NULL;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rtl8192_tx_ring *ring;
struct rtl_tx_desc *pdesc;
@@ -1635,9 +1634,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
__le16 fc = rtl_get_fc(skb);
u8 *pda_addr = hdr->addr1;
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-   /*ssn */
-   u8 tid = 0;
-   u16 seq_number = 0;
u8 own;
u8 temp_one = 1;
 
@@ -1699,19 +1695,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
return skb->len;
}
 
-   if (ieee80211_is_data_qos(fc)) {
-   tid = rtl_get_tid(skb);
-   if (sta) {
-   sta_entry = (struct rtl_sta_info *)sta->drv_priv;
-   seq_number = (le16_to_cpu(hdr->seq_ctrl) &
- IEEE80211_SCTL_SEQ) >> 4;
-   seq_number += 1;
-
-   if (!ieee80211_has_morefrags(hdr->frame_control))
-   sta_entry->tids[tid].seq_number = seq_number;
-   }
-   }
-
if (ieee80211_is_data(fc))
rtlpriv->cfg->ops->led_control(hw, LED_CTL_TX);
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 5590d07d0918..39b033b3b53a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -952,17 +952,12 @@ static void _rtl_usb_tx_preprocess(struct ieee80211_hw 
*hw,
   u16 hw_queue)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rtl_tx_desc *pdesc = NULL;
struct rtl_tcb_desc tcb_desc;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
__le16 fc = hdr->frame_control;
u8 *pda_addr = hdr->addr1;
-   /* ssn */
-   u8 *qc = NULL;
-   u8 tid = 0;
-   u16 seq_number = 0;
 
memset(_desc, 0, sizeof(struct rtl_tcb_desc));
if (ieee80211_is_auth(fc)) {
@@ -983,20 +978,8 @@ static void _rtl_usb_tx_preprocess(struct ieee80211_hw *hw,
rtlpriv->stats.txbytesbroadcast += skb->len;
else
rtlpriv->stats.txbytesunicast += skb->len;
-   if (ieee80211_is_data_qos(fc)) {
-   qc = ieee80211_get_qos_ctl(hdr);
-   tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
-   seq_number = (le16_to_cpu(hdr->seq_ctrl) &
-IEEE80211_SCTL_SEQ) >> 4;
-   seq_number += 1;
-   seq_number <<= 4;
-   }
rtlpriv->cfg->ops->fill_tx_desc(hw, hdr, (u8 *)pdesc, NULL, info, sta, 
skb,
hw_queue, _desc);
-   if (!ieee80211_has_morefrags(hdr->frame_control)) {
-   if (qc)
-