Re: RTL8723BE performance regression
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
> > 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
> > >> 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: [PATCH] staging: wilc1000: fix infinite loop and out-of-bounds access
On Mon, 30 Apr 2018 18:23:21 +0300
Dan Carpenter wrote:
> On Mon, Apr 30, 2018 at 07:59:16PM +0530, Ajay Singh wrote:
> > Reviewed-by: Ajay Singh
> >
> > On Mon, 30 Apr 2018 07:50:40 -0500
> > "Gustavo A. R. Silva" wrote:
> >
> > > If i < slot_id is initially true then it will remain true. Also,
> > > as i is being decremented it will end up accessing memory out of
> > > bounds.
> > >
> > > Fix this by incrementing *i* instead of decrementing it.
> >
> > Nice catch!
> > Thanks for submitting the changes.
> >
> > >
> > > Addresses-Coverity-ID: 1468454 ("Infinite loop")
> > > Fixes: faa657641081 ("staging: wilc1000: refactor scan() to free
> > > kmalloc memory on failure cases")
> > > Signed-off-by: Gustavo A. R. Silva
> > > ---
> > >
> > > BTW... at first sight it seems to me that variables slot_id
> > > and i should be of type unsigned instead of signed.
> >
> > Yes, 'slot_id' & 'i' can be changed to unsigned int.
> >
>
> A lot of people think making things unsigned improves the code but I
> hate "unsigned int i"... I understand that in certain cases we do
> loop more than INT_MAX but those are a tiny tiny minority of loops.
>
> Simple types like "int" are more readable than complicated types
> like "unsigned int". Unsigned int just draws attention to itself
> and distracts people from things that might potentially matter. We
> have real life subtle loops like in xtea_encrypt() where we need to
> use unsigned types.
>
> And look at the function we're talking about here:
>
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
>577 static inline int
>578 wilc_wfi_cfg_alloc_fill_ssid(struct cfg80211_scan_request
> *request, 579 struct hidden_network
> *ntwk) 580 {
>581 int i;
>582 int slot_id = 0;
>583
>584 ntwk->net_info = kcalloc(request->n_ssids,
>585 sizeof(struct
> hidden_network), GFP_KERNEL); 586 if (!ntwk->net_info)
>587 goto out;
>588
>589 ntwk->n_ssids = request->n_ssids;
>590
>591 for (i = 0; i < request->n_ssids; i++) {
>
> request->n_ssids is an int. It can't possibly be INT_MAX because
> the kcalloc() will fail. Ideally the static analysis tool should
> be able to tell you that if you seed it with the knowledge of how
> much memory it's possible to kmalloc(). So it's just laziness here
> is why the static checker complains, it should see there is no
> issue. Smatch fails here as well but I'll see if I can fix it.
>
> Anyway let's say it could be negative then 0 is greater than
> negative values so the loop would be a no-op. I've seen code where
> the user could set the loop bounds to s32min-4 but because it was
> "int i" instead of "unsigned int i" then it meant the loop was a
> no-op instead of being a security problem. In other words,
> unsigned can be less secure.
>
> I honestly have never seen a bug in the kernel where we intended to
> loop more than INT_MAX times, but there was a signedness bug
> preventing it. That's the only reason I can see to change the
> signedness. Am I missing something?
>
Hi Dan,
Thanks for providing the detailed explanation.
I understand your point, but what's your opinion about variable
'slot_id', as this variable is added to take only the positive
value(i.e from 0 to maximum number of filled elements), so for more
readability should we keep it same.
BTW in my opinion 'request->n_ssids' should have been unsigned
because it is suppose to hold only positive values along with
smaller data type(may be u8 or u16, as the range might be enough to
hold the value of n_ssids). So we have advantage of size reduction
not just the increase in value range.
Suppose we get negative value for "request->n_ssids" & kmalloc is
pass then we have to add some more extra code to free data and
return error code in wilc_wfi_cfg_alloc_fill_ssid(). In your opinion
should this condition be handled as the received 'request->n_ssids' is
of 'int' type.
Regards,
Ajay
RE: RTL8723BE performance regression
> -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
> 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
> >> 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
[RFC PATCH 2/3] Revert "rtlwifi: fill FW version and subversion"
This reverts commit 874e837d67d0db179c9771f38fd21df07c703e93. This drastically affects the upload performance and signal strenght on the HP 240 G4 laptop, as shown by the results bellow: Without this change: $ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal signal: -42.00 dBm $ iperf3 -c 192.168.1.254 Connecting to host 192.168.1.254, port 5201 [ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec1 1.41 KBytes [ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec1 1.41 KBytes [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec1 28.3 KBytes [ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec3 41.0 KBytes [ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec0 58.0 KBytes [ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec1 1.41 KBytes [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec7 sender [ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver iperf Done. With this change: $ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal signal: -14.00 dBm $ iperf3 -c 192.168.1.254 Connecting to host 192.168.1.254, port 5201 [ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec0194 KBytes [ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec0273 KBytes [ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec0332 KBytes [ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec0393 KBytes [ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec0434 KBytes [ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec0434 KBytes [ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec0464 KBytes [ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec0481 KBytes [ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec0508 KBytes [ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec0564 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec0 sender [ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver iperf Done. Signed-off-by: João Paulo Rechi Vita --- drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 2 -- drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c index 63874512598b..a2eca669873b 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/fw.c @@ -141,8 +141,6 @@ int rtl88e_download_fw(struct ieee80211_hw *hw, return 1; pfwheader = (struct rtlwifi_firmware_header *)rtlhal->pfirmware; - rtlhal->fw_version = le16_to_cpu(pfwheader->version); - rtlhal->fw_subversion = pfwheader->subversion; pfwdata = rtlhal->pfirmware; fwsize = rtlhal->fwsize; RT_TRACE(rtlpriv, COMP_FW, DBG_DMESG, diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c index 521039c5d4ce..0d1ebc861720 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.c @@ -200,8 +200,6 @@ int rtl8723_download_fw(struct ieee80211_hw *hw, return 1; pfwheader = (struct rtlwifi_firmware_header *)rtlhal->pfirmware; - rtlhal->fw_version = le16_to_cpu(pfwheader->version); - rtlhal->fw_subversion = pfwheader->subversion; pfwdata = rtlhal->pfirmware; fwsize = rtlhal->fwsize; -- 2.17.0
[RFC PATCH 3/3] rtlwifi: btcoex: Always use 2ant-functions for RTL8723BE
This partially reverts commit 7937f02d1953952a6eaf626b175ea9db5541e699,
which not only hooked external functions for newer ICs, as described in
its commit message, but also changed the behavior for RTL8723BE
depending on the value of board_info.btdm_ant_num.
When board_info.btdm_ant_num == 1, 7937f02d19 changes the codepath to
use a whole different set of functions ex_btc8723b1ant_*, instead of the
ex_btc8723b2ant_* that were used before it.
This drastically affects the upload performance and signal strenght on
the HP 240 G4 laptop, as shown by the results bellow:
Without this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -42.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec1 1.41 KBytes
[ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec1 1.41 KBytes
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec1 28.3 KBytes
[ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec3 41.0 KBytes
[ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec0 58.0 KBytes
[ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec1 1.41 KBytes
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes
[ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec7 sender
[ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver
iperf Done.
With this change:
$ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal
signal: -14.00 dBm
$ iperf3 -c 192.168.1.254
Connecting to host 192.168.1.254, port 5201
[ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec0194 KBytes
[ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec0273 KBytes
[ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec0332 KBytes
[ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec0393 KBytes
[ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec0434 KBytes
[ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec0434 KBytes
[ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec0464 KBytes
[ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec0481 KBytes
[ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec0508 KBytes
[ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec0564 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec0 sender
[ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver
iperf Done.
Signed-off-by: João Paulo Rechi Vita
---
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 62 ---
1 file changed, 12 insertions(+), 50 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 86182b917c92..a862b5efdf55 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1452,10 +1452,7 @@ void exhalbtc_init_hw_config(struct btc_coexist
*btcoexist, bool wifi_only)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_init_hwconfig(btcoexist, wifi_only);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_init_hwconfig(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
- ex_btc8723b1ant_init_hwconfig(btcoexist, wifi_only);
+ ex_btc8723b2ant_init_hwconfig(btcoexist);
} else if (IS_HARDWARE_TYPE_8723A(btcoexist->adapter)) {
/* 8723A has no this function */
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
@@ -1481,10 +1478,7 @@ void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8821a1ant_init_coex_dm(btcoexist);
} else if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
- if (btcoexist->board_info.btdm_ant_num == 2)
- ex_btc8723b2ant_init_coex_dm(btcoexist);
- else if (btcoexist->board_info.btdm_ant_num == 1)
-
[RFC PATCH 1/3] rtlwifi: btcoex: Don't init antenna position to main port
This partially reverts commit 40d9dd4f1c5dcd0d4a2a1f0efcd225c9c4b36d6f, which does not only remove global variables from btcoex, as described on its commit message, but also does a few other things -- in particular, setting the default antenna position to BTC_ANTENNA_AT_MAIN_PORT. This drastically affects the upload performance and signal strenght on the HP 240 G4 laptop, as shown by the results bellow: Without this change: $ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal signal: -42.00 dBm $ iperf3 -c 192.168.1.254 Connecting to host 192.168.1.254, port 5201 [ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec1 1.41 KBytes [ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec1 1.41 KBytes [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec1 28.3 KBytes [ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec3 41.0 KBytes [ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec0 58.0 KBytes [ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec1 1.41 KBytes [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 3.03 MBytes 2.54 Mbits/sec7 sender [ 4] 0.00-10.00 sec 2.88 MBytes 2.41 Mbits/sec receiver iperf Done. With this change: $ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal signal: -14.00 dBm $ iperf3 -c 192.168.1.254 Connecting to host 192.168.1.254, port 5201 [ 4] local 192.168.1.253 port 59380 connected to 192.168.1.254 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 4.63 MBytes 38.8 Mbits/sec0194 KBytes [ 4] 1.00-2.00 sec 4.58 MBytes 38.4 Mbits/sec0273 KBytes [ 4] 2.00-3.00 sec 5.05 MBytes 42.3 Mbits/sec0332 KBytes [ 4] 3.00-4.00 sec 4.98 MBytes 41.8 Mbits/sec0393 KBytes [ 4] 4.00-5.00 sec 4.76 MBytes 39.9 Mbits/sec0434 KBytes [ 4] 5.00-6.00 sec 4.85 MBytes 40.7 Mbits/sec0434 KBytes [ 4] 6.00-7.00 sec 3.96 MBytes 33.2 Mbits/sec0464 KBytes [ 4] 7.00-8.00 sec 4.74 MBytes 39.8 Mbits/sec0481 KBytes [ 4] 8.00-9.00 sec 4.22 MBytes 35.4 Mbits/sec0508 KBytes [ 4] 9.00-10.00 sec 4.09 MBytes 34.3 Mbits/sec0564 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 45.9 MBytes 38.5 Mbits/sec0 sender [ 4] 0.00-10.00 sec 45.0 MBytes 37.7 Mbits/sec receiver iperf Done. Signed-off-by: João Paulo Rechi Vita --- drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c index b026e80940a4..86182b917c92 100644 --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c @@ -1388,9 +1388,6 @@ bool exhalbtc_bind_bt_coex_withadapter(void *adapter) ant_num = rtl_get_hwpg_ant_num(rtlpriv); exhalbtc_set_ant_num(rtlpriv, BT_COEX_ANT_TYPE_PG, ant_num); - /* set default antenna position to main port */ - btcoexist->board_info.btdm_ant_pos = BTC_ANTENNA_AT_MAIN_PORT; - single_ant_path = rtl_get_hwpg_single_ant_path(rtlpriv); exhalbtc_set_single_ant_path(btcoexist, single_ant_path); -- 2.17.0
Re: RTL8723BE performance regression
On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger 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 >> 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. Using those two tests (iperf3 and signal strength) I've dug deeper into the culprit I had found previously, commit 7937f02d1953, reverting it partially and testing the resulting driver, to isolate which change was causing the problem. Besides "hooking up external functions for newer ICs", as described by the commit message, that commit also added code to decided whether ex_btc8723b1ant_*() or ex_btc8723b2ant_*() functions should be used in halbtcoutsrc.c, depending on the value of board_info.btdm_ant_num, whereas before that commit ex_btc8723b2ant_*() were always used. Reverting to always using ex_btc8723b2ant_*() functions fixes the regression on v4.15. I've also tried to bisect between v4.15..v4.16 to find what else was causing problems there, as the changes mentioned above on top of v4.16 did not solve the problem. The bisect pointed to "874e837d67d0 rtlwifi: fill FW version and subversion", only but reverting it plus the changes mentioned above also didn't yield good results. That's when I decided to get a bit creative: starting on v4.16 I first applied the changes to have ex_btc8723b2ant_*() always being used, as mentioned above, then reverted every commit between v4.15..v4.16 affecting drivers/net/wireless/realtek/rtlwifi/, and verified the resulting kernel had a good performance. Then I started trimming down the history and testing along the way, to reduce to the minimum set of changes that had to be reverted in order to restore the good performance. In addition to the ex_btc8723b2ant_*() changes and reverting "874e837d67d0 rtlwifi: fill FW version and subversion", I've also had to remove the following lines from drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c, which were introduced by "40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex", in order to restore the upload performance and signal strength. /* set default antenna position to main port */ btcoexist->board_info.btdm_ant_pos = BTC_ANTENNA_AT_MAIN_PORT; These are the results I've got on v4.16 (similarly on wireless-drivers-next-for-davem-2018-03-29 or v4.15): $ sudo iw dev wlp2s0 scan | grep -B3 JJ | grep signal signal: -42.00 dBm $ iperf3 -c 192.168.1.254 Connecting to host 192.168.1.254, port 5201 [ 4] local 192.168.1.253 port 39678 connected to 192.168.1.254 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 735 KBytes 6.02 Mbits/sec1 1.41 KBytes [ 4] 1.00-2.00 sec 274 KBytes 2.25 Mbits/sec1 1.41 KBytes [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec0 1.41 KBytes [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec1 28.3 KBytes [ 4] 5.00-6.00 sec 423 KBytes 3.47 Mbits/sec3 41.0 KBytes [ 4] 6.00-7.00 sec 840 KBytes 6.88 Mbits/sec0 58.0 KBytes [ 4] 7.00-8.00 sec 830 KBytes 6.79 Mbits/sec1 1.41 KBytes [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec0 1.41
Re: [wireless-regdb] [PATCH 2/2] wireless-regdb: Parse wmm rule data
On Tue, 2018-05-01 at 15:02 -0500, Seth Forshee wrote: > > > +import attr > > I'm a little hesitant to add use of non-standard libraries if it isn't > necessary, as some distros have traditionally built the regdb from > source (not sure how practical that is after the db-as-firmware changes > though). Do we lose anything critical if we don't use attr? I probably suggested the use of attr. It's super useful, for things like this: > > +@attr.s(frozen=True) > > +class WmmRule(object): > > +vo_c = attr.ib() > > +vi_c = attr.ib() > > +be_c = attr.ib() > > +bk_c = attr.ib() > > +vo_ap = attr.ib() > > +vi_ap = attr.ib() > > +be_ap = attr.ib() > > +bk_ap = attr.ib() > > + > > +def _as_tuple(self): > > +return (self.vo_c, self.vi_c, self.be_c, self.bk_c, > > +self.vo_ap, self.vi_ap, self.be_ap, self.bk_ap) Spelling this out as a real object with all the __repr__ and comparisons etc. gets far more verbose. While we can get rid of it in theory, it's a ~100KiB package without any further dependencies, and the code is better off for it. Ultimately it's your decision, but I suspect that python is already such a big dependency that adding this library is in the noise. johannes
Re: [PATCH 2/2] wireless-regdb: Parse wmm rule data
On Tue, May 01, 2018 at 04:36:12PM +0300, Haim Dreyfuss wrote:
> Add code to parse wmm rule data.
> Also write it to the the regulatory.db fw file
>
> Signed-off-by: Haim Dreyfuss
This patch doesn't seem to be based off the tip of master and has
conflicts. Generally they look easy to resolve, but I also have a few
other comments, below.
> ---
> db2fw.py | 31 +++--
> dbparse.py | 111
> +++--
> 2 files changed, 136 insertions(+), 6 deletions(-)
>
> diff --git a/db2fw.py b/db2fw.py
> index 7b2b141..6d0ae5f 100755
> --- a/db2fw.py
> +++ b/db2fw.py
> @@ -5,6 +5,7 @@ import struct
> import hashlib
> from dbparse import DBParser
> import sys
> +from math import log
>
> MAGIC = 0x52474442
> VERSION = 20
> @@ -26,6 +27,13 @@ def create_collections(countries):
> result[(c.permissions, c.dfs_region)] = 1
> return result.keys()
>
> +def create_wmms(countries):
> +result = {}
> +for c in countries.itervalues():
> +for rule in c.permissions:
> +if rule.wmmrule is not None:
> +result[rule.wmmrule] = 1
> +return result.keys()
See recent updates for python 3, should use list(result) instead.
> def be32(output, val):
> output.write(struct.pack('>I', val))
> @@ -63,6 +71,8 @@ rules = create_rules(countries)
> rules.sort(cmp=lambda x, y: cmp(x.freqband, y.freqband))
> collections = create_collections(countries)
> collections.sort(cmp=lambda x, y: cmp(x[0][0].freqband, y[0][0].freqband))
> +wmms = create_wmms(countries)
> +wmms.sort(cmp=lambda x, y: cmp(x.vo_c, y.vo_c))
See the recent patch "wireless-regdb: do not rely on sorting of dict
keys in conversion scripts". Let's do likewise to ensure sort order is
consistent across python versions.
>
> output = StringIO()
>
> @@ -79,10 +89,19 @@ for alpha2 in countrynames:
> country_ptrs[alpha2] = PTR(output)
> output.write('\x00' * 4)
>
> +wmmdb = {}
> +for w in wmms:
> +assert output.tell() & 3 == 0
> +wmmdb[w] = output.tell() >> 2
> +for r in w._as_tuple():
> +ecw = int(log(r[0] + 1, 2)) << 4 | int(log(r[1] + 1, 2))
> +ac = (ecw, r[2],r[3])
> +output.write(struct.pack('>BBH', *ac))
> +
> reg_rules = {}
> flags = 0
> for reg_rule in rules:
> -freq_range, power_rule = reg_rule.freqband, reg_rule.power
> +freq_range, power_rule, wmm_rule = reg_rule.freqband, reg_rule.power,
> reg_rule.wmmrule
> reg_rules[reg_rule] = output.tell()
> assert power_rule.max_ant_gain == 0
> flags = 0
> @@ -102,13 +121,19 @@ for reg_rule in rules:
> cac_timeout = 0 # TODO
> if not (flags & 1<<2):
> cac_timeout = 0
> -if cac_timeout:
> +if cac_timeout or wmm_rule:
> +rule_len += 2
> +if wmm_rule is not None:
> rule_len += 2
> output.write(struct.pack('>BBHIII', rule_len, flags, power_rule.max_eirp
> * 100,
> freq_range.start * 1000, freq_range.end * 1000,
> freq_range.maxbw * 1000,
> ))
> -if cac_timeout:
> +if rule_len > 16:
> output.write(struct.pack('>H', cac_timeout))
> +
> +if rule_len > 18:
> +be16(output, wmmdb[wmm_rule])
> +
> while rule_len % 4:
> output.write('\0')
> rule_len += 1
> diff --git a/dbparse.py b/dbparse.py
> index b735b6a..409fbb8 100755
> --- a/dbparse.py
> +++ b/dbparse.py
> @@ -1,6 +1,9 @@
> #!/usr/bin/env python
>
> import sys, math
> +from math import ceil, log
> +from collections import defaultdict, OrderedDict
> +import attr
I'm a little hesitant to add use of non-standard libraries if it isn't
necessary, as some distros have traditionally built the regdb from
source (not sure how practical that is after the db-as-firmware changes
though). Do we lose anything critical if we don't use attr?
>
> # must match enum nl80211_reg_rule_flags
>
> @@ -25,6 +28,21 @@ dfs_regions = {
> 'DFS-JP':3,
> }
>
> +@attr.s(frozen=True)
> +class WmmRule(object):
> +vo_c = attr.ib()
> +vi_c = attr.ib()
> +be_c = attr.ib()
> +bk_c = attr.ib()
> +vo_ap = attr.ib()
> +vi_ap = attr.ib()
> +be_ap = attr.ib()
> +bk_ap = attr.ib()
> +
> +def _as_tuple(self):
> +return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
> +self.vo_ap, self.vi_ap, self.be_ap, self.bk_ap)
> +
> class FreqBand(object):
> def __init__(self, start, end, bw, comments=None):
> self.start = start
> @@ -77,11 +95,13 @@ class FlagError(Exception):
> self.flag = flag
>
> class Permission(object):
> -def __init__(self, freqband, power, flags):
> +def __init__(self, freqband, power, flags, wmmrule):
> assert isinstance(freqband, FreqBand)
> assert isinstance(power, PowerRestriction)
> +assert isinstance(wmmrule, WmmRule) or wmmrule is None
> self.freqband = freqband
> self.
Patch: Support Killer 1550 in MSI laptop
Hello, all
I have an MSI 8th-gen notebook with a Killer 1550 wifi card. This card
has a different subsystem ID than I have seen in prior patches:
Output of lspci -nnvvv:
00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 9560
[Jefferson Peak] [8086:a370] (rev 10)
Subsystem: Bigfoot Networks, Inc. Device [1a56:1552]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at ad414000 (64-bit, non-prefetchable) [size=16K]
Capabilities:
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
Without this patch no driver is shown, not even pci_stub. This has been
tested on my laptop, and only on my home wifi which is wireless-N, not
-AC (no 5GHz). The speed seems to be slower than the Windows driver,
but at least this gets the device recognized and working.
Signed-off-by: Stephen Wille Padnos
---
diff --git a/drv.c.orig b/drv.c
index ccd7c33..8920169 100644
--- a/drv.c.orig
+++ b/drv.c
@@ -648,6 +648,7 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0xA370, 0x02A0, iwl9462_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x02A4, iwl9462_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg_soc)},
+ {IWL_PCI_DEVICE(0xA370, 0x1552, iwl9560_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x4030, iwl9560_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x4034, iwl9560_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x40A4, iwl9462_2ac_cfg_soc)},
Re: [PATCH 2/2 - linux-stable-4.4] ath10k: rebuild crypto header in rx data frames
On 2018-05-01 20:30, Greg KH wrote: On Tue, May 01, 2018 at 05:44:19AM +0530, Sriram R wrote: On 2018-05-01 05:14, Sriram R wrote: > On 2018-05-01 00:39, Greg KH wrote: > > On Mon, Apr 30, 2018 at 11:56:27AM +0530, Sriram R wrote: > > > Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and > > > HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done > > > on host (mac80211) rather than firmware. Rebuild cipher header > > > in every received data frames (that are notified through those > > > HTT interfaces) from the rx_hdr_status tlv available in the > > > rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED > > > flag for the packets which requires mac80211 PN/TSC check support > > > and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, > > > and QCA99X0 currently need the rebuilding of cipher header to > > > perform PN/TSC check for replay attack. > > > > > > [Upstream Commit : 7eccb738fce57cbe53ed903ccf43f9ab257b15b3] > > > > > > Signed-off-by: Vasanthakumar Thiagarajan > > > Signed-off-by: Sriram R > > > --- > > > drivers/net/wireless/ath/ath10k/htt_rx.c | 98 > > > ++-- > > > 1 file changed, 82 insertions(+), 16 deletions(-) > > > > This patch breaks the build. Always test build your patches! > > > > thanks, > > > > greg k-h > Hi Greg, > > This patch along with its dependency patches (in the following order) > > f980ebc058c2 : mac80211: allow not sending MIC up from driver for HW > crypto > f631a77ba920 : mac80211: allow same PN for AMSDU sub-frames > cef0acd4d7d4 : mac80211: Add RX flag to indicate ICV stripped > [PATCH 1/2 linux-stable-4.4] ath10k: Add new hw param to identify > alignment for different chipsets > Hi Greg, I feel this breaks since the above mentioned mac80211 commits are not available in this queue. https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-4.4/series?id=8e2985dd801f00640be6998ec831018a688bb221 Could you please check after these commits are queued as well before this patch is applied. Please let me know if i miss something here so i could check from my side as well. Ugh, you are right, I missed that in the cover leter, my fault. I'll blame the jet-lag :) I'll go drop the first patch for now, and then look at all of these again at the end of the week for the next round of releases. thanks, greg k-h Sure, Thanks Greg. Regards, Sriram.R
Re: [PATCH 2/2 - linux-stable-4.4] ath10k: rebuild crypto header in rx data frames
On Tue, May 01, 2018 at 05:44:19AM +0530, Sriram R wrote: > On 2018-05-01 05:14, Sriram R wrote: > > On 2018-05-01 00:39, Greg KH wrote: > > > On Mon, Apr 30, 2018 at 11:56:27AM +0530, Sriram R wrote: > > > > Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and > > > > HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done > > > > on host (mac80211) rather than firmware. Rebuild cipher header > > > > in every received data frames (that are notified through those > > > > HTT interfaces) from the rx_hdr_status tlv available in the > > > > rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED > > > > flag for the packets which requires mac80211 PN/TSC check support > > > > and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, > > > > and QCA99X0 currently need the rebuilding of cipher header to > > > > perform PN/TSC check for replay attack. > > > > > > > > [Upstream Commit : 7eccb738fce57cbe53ed903ccf43f9ab257b15b3] > > > > > > > > Signed-off-by: Vasanthakumar Thiagarajan > > > > Signed-off-by: Sriram R > > > > --- > > > > drivers/net/wireless/ath/ath10k/htt_rx.c | 98 > > > > ++-- > > > > 1 file changed, 82 insertions(+), 16 deletions(-) > > > > > > This patch breaks the build. Always test build your patches! > > > > > > thanks, > > > > > > greg k-h > > Hi Greg, > > > > This patch along with its dependency patches (in the following order) > > > > f980ebc058c2 : mac80211: allow not sending MIC up from driver for HW > > crypto > > f631a77ba920 : mac80211: allow same PN for AMSDU sub-frames > > cef0acd4d7d4 : mac80211: Add RX flag to indicate ICV stripped > > [PATCH 1/2 linux-stable-4.4] ath10k: Add new hw param to identify > > alignment for different chipsets > > > Hi Greg, > > I feel this breaks since the above mentioned mac80211 commits are not > available in this queue. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-4.4/series?id=8e2985dd801f00640be6998ec831018a688bb221 > > Could you please check after these commits are queued as well before this > patch is applied. > > Please let me know if i miss something here so i could check from my side as > well. Ugh, you are right, I missed that in the cover leter, my fault. I'll blame the jet-lag :) I'll go drop the first patch for now, and then look at all of these again at the end of the week for the next round of releases. thanks, greg k-h
Re: [PATCH v7] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
On 04/30/2018 03:14 PM, Sebastian Gottschall wrote:
+/* only 4x4 configuration do support 2x2 for VHT160, everything else must
use 1x1 */
+if (ar->cfg_rx_chainmask == 15)
+nss160 = arg->peer_num_spatial_streams <= 2 ?
arg->peer_num_spatial_streams : 2;
If peer nss == 3, then nss160 must be 1x1. That is why I previously suggested
the code that set nss160 to equal nss / 2
(with special case to bump nss160 to 1x1 if nss == 1.
btw. it doesnt matter if the peer sends with 3x3 or even 4x4, i still can
receive with 2x2. thats no conflict. switching back to 1x1 of the peer sends
vht160 with 3x3 makes no real sense
i dont have to turn off a chain, if i'm able todo 2x2, no matter what the peer
does. i just have to limit the maximum
If the local system is nss 4x4 and the remote is nss 3x3, then the
peer_num_spatial_streams will be 3 and the nss160 should be 1.
At least for ath10k chips, it requires 2 chains to receive a 1x1 signal at
160Mhz, so that is why
a nss 3x3 cannot receive at 2x2 160Mhz.
If you still think this makes no sense, think about it a bit before responding!
Thanks,
Ben
A 9984 peer with chainmask configured to 0x7 would hit this case I think.
Overall this looks better than previous patches though.
Thanks,
Ben
+
+/* in case if peer is connected with vht160 or vht80+80, we need to
properly adjust rxnss parameters otherwise firmware will raise a assert */
+switch(arg->peer_phymode) {
+case MODE_11AC_VHT80_80:
+arg->peer_bw_rxnss_override = BW_NSS_FWCONF_80_80(nss160);
+/* fall through */
+case MODE_11AC_VHT160:
+arg->peer_bw_rxnss_override |= BW_NSS_FWCONF_160(nss160);
+break;
+default:
+break;
}
+
+ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 0x%x
peer_bw_rxnss_override 0x%x\n",
+ sta->addr, arg->peer_max_mpdu, arg->peer_flags,
arg->peer_bw_rxnss_override);
}
static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2700,9 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
-ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..3797dca317ff 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7211,12 +7211,7 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k *ar, void
*buf,
struct wmi_10_4_peer_assoc_complete_cmd *cmd = buf;
ath10k_wmi_peer_assoc_fill_10_2(ar, buf, arg);
-if (arg->peer_bw_rxnss_override)
-cmd->peer_bw_rxnss_override =
-__cpu_to_le32((arg->peer_bw_rxnss_override - 1) |
- BIT(PEER_BW_RXNSS_OVERRIDE_OFFSET));
-else
-cmd->peer_bw_rxnss_override = 0;
+cmd->peer_bw_rxnss_override = __cpu_to_le32(arg->peer_bw_rxnss_override);
}
static int
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 46ae19bb2c92..1fe0aa5523a6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6380,7 +6380,19 @@ struct wmi_10_2_peer_assoc_complete_cmd {
__le32 info0; /* WMI_PEER_ASSOC_INFO0_ */
} __packed;
-#define PEER_BW_RXNSS_OVERRIDE_OFFSET 31
+#define BW_NSS_FWCONF_MAP_ENABLE (1 << 31)
+#define BW_NSS_FWCONF_MAP_160MHZ_S (0)
+#define BW_NSS_FWCONF_MAP_160MHZ_M (0x0007)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_S (3)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_M (0x0038)
+#define BW_NSS_FWCONF_MAP_M (0x003F)
+
+#define GET_BW_NSS_FWCONF_160(x) x) & BW_NSS_FWCONF_MAP_160MHZ_M)
>> BW_NSS_FWCONF_MAP_160MHZ_S) + 1)
+#define GET_BW_NSS_FWCONF_80_80(x) x) & BW_NSS_FWCONF_MAP_80_80MHZ_M)
>> BW_NSS_FWCONF_MAP_80_80MHZ_S) + 1)
+
+/* Values defined to set 160 MHz Bandwidth NSS Mapping into FW*/
+#define BW_NSS_FWCONF_160(x) (BW_NSS_FWCONF_MAP_ENABLE | (((x - 1) <<
BW_NSS_FWCONF_MAP_160MHZ_S) & BW_NSS_FWCONF_MAP_160MHZ_M))
+#define BW_NSS_FWCONF_80_80(x)(BW_NSS_FWCONF_MAP_ENABLE | (((x - 1) <<
BW_NSS_FWCONF_MAP_80_80MHZ_S) & BW_NSS_FWCONF_MAP_80_80MHZ_M))
struct wmi_10_4_peer_assoc_complete_cmd {
struct wmi_10_2_peer_assoc_complete_cmd cmd;
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
Re: [PATCH v4 2/2] drivers: remove force dma flag from buses
On Sat, Apr 28, 2018 at 08:21:59AM +0530, Nipun Gupta wrote: > With each bus implementing its own DMA configuration callback, > there is no need for bus to explicitly have force_dma in its > global structure. This patch modifies of_dma_configure API to > accept an input parameter which specifies if implicit DMA > configuration is required even when it is not described by the > firmware. > > Signed-off-by: Nipun Gupta > Acked-by: Bjorn Helgaas # PCI parts > --- > Changes in v2: > - This is a new change suggested by Robin and Christoph > and is added to the series. > > Changes in v3: > - Rebase and changes corresponding to the changes in patch 1/2 > > Changes in v4: > - Rebased on top of 4.17-rc2 > > drivers/amba/bus.c| 1 - > drivers/base/platform.c | 3 +-- > drivers/bcma/main.c | 2 +- > drivers/dma/qcom/hidma_mgmt.c | 2 +- > drivers/gpu/host1x/bus.c | 5 ++--- > drivers/of/device.c | 6 -- > drivers/of/of_reserved_mem.c | 2 +- > drivers/pci/pci-driver.c | 3 +-- > include/linux/device.h| 4 > include/linux/of_device.h | 8 ++-- > 10 files changed, 17 insertions(+), 19 deletions(-) Reviewed-by: Rob Herring
[PATCH 1/2] wireless-regdb: Add wmm rule for EEA and EFTA countries
The ETSI EN 301 893 v211 (2017-05) standard defines a new channel access mechanism that all devices (WLAN and LAA) need to comply with. In previous versions the device was allowed by ETSI to implement 802.11 channel access mechanism based on a set of priority classes which are taken from 802.11. According to the new standard there might be some exception which require the EEA and the EFTA countries, which adhere ETSI rules, to follow more restrictive rules. In order to comply with the new standard introduced by ETSI, add wmmrule global item with the new ETSI channel mechanism rules. Also add wmmrule flag to EEA and EFTA countries. Signed-off-by: Haim Dreyfuss --- db.txt | 304 ++--- 1 file changed, 157 insertions(+), 147 deletions(-) diff --git a/db.txt b/db.txt index 990abf9..e6cbc35 100644 --- a/db.txt +++ b/db.txt @@ -1,3 +1,13 @@ +wmmrule ETSI: + vo_c: cw_min=3, cw_max=7, aifsn=2, cot=2 + vi_c: cw_min=7, cw_max=15, aifsn=2, cot=4 + be_c: cw_min=15, cw_max=1023, aifsn=3, cot=6 + bk_c: cw_min=15, cw_max=1023, aifsn=7, cot=6 + vo_ap: cw_min=3, cw_max=7, aifsn=1, cot=2 + vi_ap: cw_min=7, cw_max=15, aifsn=1, cot=4 + be_ap: cw_min=15, cw_max=63, aifsn=3, cot=6 + bk_ap: cw_min=15, cw_max=1023, aifsn=7, cot=6 + # This is the world regulatory domain country 00: (2402 - 2472 @ 40), (20) @@ -19,9 +29,9 @@ country 00: country AD: (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20) - (5250 - 5330 @ 80), (20), DFS - (5490 - 5710 @ 80), (27), DFS + (5170 - 5250 @ 80), (20), wmmrule=ETSI + (5250 - 5330 @ 80), (20), DFS, wmmrule=ETSI + (5490 - 5710 @ 80), (27), DFS, wmmrule=ETSI # 60 GHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) @@ -42,9 +52,9 @@ country AF: DFS-ETSI # http://pucanguilla.org/Downloads/January2005-Anguilla%20Table%20of%20Allocations.pdf country AI: DFS-ETSI (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20), AUTO-BW - (5250 - 5330 @ 80), (20), DFS, AUTO-BW - (5490 - 5710 @ 160), (27), DFS + (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI + (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI + (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI country AL: DFS-ETSI (2402 - 2482 @ 40), (20) @@ -79,9 +89,9 @@ country AS: DFS-FCC country AT: DFS-ETSI (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20), AUTO-BW - (5250 - 5330 @ 80), (20), DFS, AUTO-BW - (5490 - 5710 @ 160), (27), DFS + (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI + (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI + (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI # 60 GHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) @@ -113,9 +123,9 @@ country AZ: DFS-ETSI country BA: DFS-ETSI (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20), AUTO-BW - (5250 - 5330 @ 80), (20), DFS, AUTO-BW - (5490 - 5710 @ 160), (27), DFS + (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI + (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI + (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI # 60 GHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) @@ -131,9 +141,9 @@ country BD: DFS-JP country BE: DFS-ETSI (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20), AUTO-BW - (5250 - 5330 @ 80), (20), DFS, AUTO-BW - (5490 - 5710 @ 160), (27), DFS + (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI + (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI + (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI # 60 GHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) @@ -163,10 +173,10 @@ country BG: DFS-ETSI (2402 - 2482 @ 40), (20) # 5 GHz Radio Local Area Networks (RLANs), ref: # II.H01 of the List, BDS EN 301 893 - (5170 - 5250 @ 80), (23), AUTO-BW - (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5170 - 5250 @ 80), (23), AUTO-BW, wmmrule=ETSI + (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI # II.H01 of the List, I.54 from the List, BDS EN 301 893 - (5490 - 5710 @ 160), (27), DFS + (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI # Short range devices (SRDs) in the 5725-5875 MHz frequency range, ref: # I.43 of the List, BDS EN 300 440-2, BDS EN 300 440-1 (5725 - 5875 @ 80), (14) @@ -257,9 +267,9 @@ country CF: DFS-FCC country CH: DFS-ETSI (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20), AUTO-BW - (5250 - 5330 @ 80), (20), DFS, AUTO-BW - (5490 - 5710 @ 160), (27), DFS + (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI + (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI + (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI # 60 GHz band
[PATCH 2/2] wireless-regdb: Parse wmm rule data
Add code to parse wmm rule data.
Also write it to the the regulatory.db fw file
Signed-off-by: Haim Dreyfuss
---
db2fw.py | 31 +++--
dbparse.py | 111 +++--
2 files changed, 136 insertions(+), 6 deletions(-)
diff --git a/db2fw.py b/db2fw.py
index 7b2b141..6d0ae5f 100755
--- a/db2fw.py
+++ b/db2fw.py
@@ -5,6 +5,7 @@ import struct
import hashlib
from dbparse import DBParser
import sys
+from math import log
MAGIC = 0x52474442
VERSION = 20
@@ -26,6 +27,13 @@ def create_collections(countries):
result[(c.permissions, c.dfs_region)] = 1
return result.keys()
+def create_wmms(countries):
+result = {}
+for c in countries.itervalues():
+for rule in c.permissions:
+if rule.wmmrule is not None:
+result[rule.wmmrule] = 1
+return result.keys()
def be32(output, val):
output.write(struct.pack('>I', val))
@@ -63,6 +71,8 @@ rules = create_rules(countries)
rules.sort(cmp=lambda x, y: cmp(x.freqband, y.freqband))
collections = create_collections(countries)
collections.sort(cmp=lambda x, y: cmp(x[0][0].freqband, y[0][0].freqband))
+wmms = create_wmms(countries)
+wmms.sort(cmp=lambda x, y: cmp(x.vo_c, y.vo_c))
output = StringIO()
@@ -79,10 +89,19 @@ for alpha2 in countrynames:
country_ptrs[alpha2] = PTR(output)
output.write('\x00' * 4)
+wmmdb = {}
+for w in wmms:
+assert output.tell() & 3 == 0
+wmmdb[w] = output.tell() >> 2
+for r in w._as_tuple():
+ecw = int(log(r[0] + 1, 2)) << 4 | int(log(r[1] + 1, 2))
+ac = (ecw, r[2],r[3])
+output.write(struct.pack('>BBH', *ac))
+
reg_rules = {}
flags = 0
for reg_rule in rules:
-freq_range, power_rule = reg_rule.freqband, reg_rule.power
+freq_range, power_rule, wmm_rule = reg_rule.freqband, reg_rule.power,
reg_rule.wmmrule
reg_rules[reg_rule] = output.tell()
assert power_rule.max_ant_gain == 0
flags = 0
@@ -102,13 +121,19 @@ for reg_rule in rules:
cac_timeout = 0 # TODO
if not (flags & 1<<2):
cac_timeout = 0
-if cac_timeout:
+if cac_timeout or wmm_rule:
+rule_len += 2
+if wmm_rule is not None:
rule_len += 2
output.write(struct.pack('>BBHIII', rule_len, flags, power_rule.max_eirp *
100,
freq_range.start * 1000, freq_range.end * 1000,
freq_range.maxbw * 1000,
))
-if cac_timeout:
+if rule_len > 16:
output.write(struct.pack('>H', cac_timeout))
+
+if rule_len > 18:
+be16(output, wmmdb[wmm_rule])
+
while rule_len % 4:
output.write('\0')
rule_len += 1
diff --git a/dbparse.py b/dbparse.py
index b735b6a..409fbb8 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -1,6 +1,9 @@
#!/usr/bin/env python
import sys, math
+from math import ceil, log
+from collections import defaultdict, OrderedDict
+import attr
# must match enum nl80211_reg_rule_flags
@@ -25,6 +28,21 @@ dfs_regions = {
'DFS-JP': 3,
}
+@attr.s(frozen=True)
+class WmmRule(object):
+vo_c = attr.ib()
+vi_c = attr.ib()
+be_c = attr.ib()
+bk_c = attr.ib()
+vo_ap = attr.ib()
+vi_ap = attr.ib()
+be_ap = attr.ib()
+bk_ap = attr.ib()
+
+def _as_tuple(self):
+return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
+self.vo_ap, self.vi_ap, self.be_ap, self.bk_ap)
+
class FreqBand(object):
def __init__(self, start, end, bw, comments=None):
self.start = start
@@ -77,11 +95,13 @@ class FlagError(Exception):
self.flag = flag
class Permission(object):
-def __init__(self, freqband, power, flags):
+def __init__(self, freqband, power, flags, wmmrule):
assert isinstance(freqband, FreqBand)
assert isinstance(power, PowerRestriction)
+assert isinstance(wmmrule, WmmRule) or wmmrule is None
self.freqband = freqband
self.power = power
+self.wmmrule = wmmrule
self.flags = 0
for flag in flags:
if not flag in flag_definitions:
@@ -89,8 +109,11 @@ class Permission(object):
self.flags |= flag_definitions[flag]
self.textflags = flags
+def _has_wmmrule(self):
+return self.wmmrule is not None
+
def _as_tuple(self):
-return (self.freqband, self.power, self.flags)
+return (self.freqband, self.power, self.flags, self.wmmrule)
def __cmp__(self, other):
if not isinstance(other, Permission):
@@ -100,6 +123,9 @@ class Permission(object):
def __hash__(self):
return hash(self._as_tuple())
+def __str__(self):
+return str(self.freqband) + str(self.power) + str(self.wmmrule)
+
class Country(object):
def __init__(self, dfs_region, permissions=None, comments=None):
self._permissions = permissions or []
@@ -233,6 +259,61 @@ class DBParser(object):
self._powerrev[p] = pname
s
[PATCH] wireless: ipw2200: fix spelling mistake: "functionalitis" -> "functionalities"
From: Colin Ian King Trivial fix to spelling mistake in module parameter description text Signed-off-by: Colin Ian King --- drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c index 87a5e414c2f7..ba3fb1d2ddb4 100644 --- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c +++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c @@ -12012,7 +12012,7 @@ MODULE_PARM_DESC(rtap_iface, "create the rtap interface (1 - create, default 0)" #ifdef CONFIG_IPW2200_QOS module_param(qos_enable, int, 0444); -MODULE_PARM_DESC(qos_enable, "enable all QoS functionalitis"); +MODULE_PARM_DESC(qos_enable, "enable all QoS functionalities"); module_param(qos_burst_enable, int, 0444); MODULE_PARM_DESC(qos_burst_enable, "enable QoS burst mode"); -- 2.17.0
[PATCH] mt76x2: remove unnecessary break in mt76x2_mac_process_tx_rate()
Remove unnecessary break statement in the default case of bw switch block in mt76x2_mac_process_tx_rate routine Signed-off-by: Lorenzo Bianconi --- drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c b/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c index d18315652583..dab713756004 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c +++ b/drivers/net/wireless/mediatek/mt76/mt76x2_mac.c @@ -410,7 +410,6 @@ mt76x2_mac_process_tx_rate(struct ieee80211_tx_rate *txrate, u16 rate, break; default: return -EINVAL; - break; } if (rate & MT_RXWI_RATE_SGI) -- 2.16.3
