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

[rtlwifi-btcoex] Suspicious code in halbtc8821a1ant driver

[Gustavo A. R. Silva]

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?

What do you think?

Thanks
--
Gustavo

[PATCH] brcm80211: brcmsmac: phy_lcn: remove duplicate code

[Gustavo A. R. Silva]

Remove and refactor some code in order to avoid having identical code
for different branches.

Notice that this piece of code hasn't been modified since 2011.

Addresses-Coverity-ID: 1226756 ("Identical code for different branches")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
index 93d4cde..9d830d2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -3388,13 +3388,8 @@ void wlc_lcnphy_deaf_mode(struct brcms_phy *pi, bool 
mode)
u8 phybw40;
phybw40 = CHSPEC_IS40(pi->radio_chanspec);
 
-   if (LCNREV_LT(pi->pubpi.phy_rev, 2)) {
-   mod_phy_reg(pi, 0x4b0, (0x1 << 5), (mode) << 5);
-   mod_phy_reg(pi, 0x4b1, (0x1 << 9), 0 << 9);
-   } else {
-   mod_phy_reg(pi, 0x4b0, (0x1 << 5), (mode) << 5);
-   mod_phy_reg(pi, 0x4b1, (0x1 << 9), 0 << 9);
-   }
+   mod_phy_reg(pi, 0x4b0, (0x1 << 5), (mode) << 5);
+   mod_phy_reg(pi, 0x4b1, (0x1 << 9), 0 << 9);
 
if (phybw40 == 0) {
mod_phy_reg((pi), 0x410,
-- 
2.7.4

Re: [PATCH] mac80211: Fix bad line warning

[David Miller]

From: Masanari Iida 
Date: Wed,  4 Apr 2018 20:53:33 +0900

> After 03fe2debbb2771fb90881e merged during 4.17 marge window,
> I start to see following warning during "make xmldocs"
> 
> ./include/net/mac80211.h:2083: warning: bad line:  >
> 
> Replace ">" with "*" fix the issue.
> 
> Signed-off-by: Masanari Iida 

Adding linux-wireless to CC:

> ---
>  include/net/mac80211.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index d2279b2d61aa..b2f3a0c018e7 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -2080,7 +2080,7 @@ struct ieee80211_txq {
>   *   virtual interface might not be given air time for the transmission of
>   *   the frame, as it is not synced with the AP/P2P GO yet, and thus the
>   *   deauthentication frame might not be transmitted.
> - >
> + *
>   * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
>   *   support QoS NDP for AP probing - that's most likely a driver bug.
>   *
> -- 
> 2.17.0.rc2.3.gc2a499e6c31e
> 

Re: RTL8723BE performance regression

[Steve deRosier]

On Tue, Apr 3, 2018 at 6:51 PM, João Paulo Rechi Vita  wrote:
>
> This are the results (testing with speedtest.net) I got at some key points:
>
> VersionCommitPingDownUp
>
> v4.11a351e9b1225.445.99
> v4.11a351e9b131  17.025.89
>
> v4.13569dbb8174  14.080.00
> v4.13569dbb8261  8.41  0.00
>
> v4.15+revert d8a5b801923.861.41
> v4.15+revert d8a5b80189  18.691.39
>

I recommend doing throughput testing in a closed system using iperf.
speedtest.net is potentially useful for testing your ISP's bandwidth
at some particular point in time, but little else as it exposes you to
too many variables. I wouldn't take those numbers to mean much and the
inconclusive results you're getting could be explained by external
network loading and having little to do with your bisect effort. I can
get that spread in numbers from speedtest.net without making any
changes other than the time of day I do the test.

Here's how to do it. Install iperf2 (you could use iperf3, personal
choice) on two machines, one being your device under test (DUT). Setup
a network configuration that looks similar to this:

server <==hardwire==> AP <--wireless link--> DUT

Be sure your hardwire is more bandwidth than your wireless link is
capable of, or set it up where the server is the AP. What you're
looking for here is environmental consistency, not maximum throughput
numbers.

On the computer hardwired to the network, start the server, we'll
assume it has an ip of 192.168.33.18:

iperf -s

On your DUT:

iperf -c 192.168.33.18

That's the most basic setup, check the man page for more options.

You will get best results if you can exclude other computers from your
test network and other wireless devices from your airspace.

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/

Re: [PATCH] nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS

[Arend van Spriel]

On 4/4/2018 12:36 PM, Johannes Berg wrote:

Hi,


Started working on this and actually the "weird flags thing" is done for
a reason. Maybe the reason was because it is done like that in the
CMD_CONNECT case, but the better reason is that we need to return
-EINVAL for "no-fils-offload-support, any-fils-param" *and*
"fils-offload-support, not-all-fils-param".


Ok, fair enough.


I added a comment for this in the patch.


Also there is a DOC section about FILS shared key authentication
offload" so I suppose that should be extended as well.


So looking at the DOC section I am reading the following:

   * When FILS shared key authentication is completed, driver needs to
provide the
   * below additional parameters to userspace.
   *%NL80211_ATTR_FILS_KEK - used for key renewal
   *%NL80211_ATTR_FILS_ERP_NEXT_SEQ_NUM - used in further EAP-RP exchanges
   *%NL80211_ATTR_PMKID - used to identify the PMKSA used/generated
   *%Nl80211_ATTR_PMK - used to update PMKSA cache in userspace
   * The PMKSA can be maintained in userspace persistently so that it can
be used
   * later after reboots or wifi turn off/on also.

So to me it seems we need these for the ROAM event as well. Agree?


Maybe not all of them, you could be using the same PMKSA, but yes, I
tend to agree.


I would argue that for the scenario where you do CMD_CONNECT(auth=open) 
and CMD_UPDATE_CONNECT_PARAMS(auth=fils-sk) the ROAM event should 
provide all the above. From what I understand from my colleagues this is 
a supported scenario.


Regards,
Arend

Re: [PATCH 1/9] rtlwifi: btcoex: Add 8822b1ant coex files

[Pkshih]

On Wed, 2018-04-04 at 20:41 +0800, Pkshih wrote:
> On Wed, 2018-04-04 at 02:43 +, Larry Finger wrote:
> > On 03/28/2018 02:27 AM, pks...@realtek.com wrote:
> > > From: Ping-Ke Shih 
> > > 
> > > This file supports 8822be WiFi module with two physical antenna that
> > > means one antenna will share with BT.
> > > 
> > > Signed-off-by: Ping-Ke Shih 
> > > ---
> > >   .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5303 
> > >
> > >   .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.h|  413 ++
> > >   2 files changed, 5716 insertions(+)
> > >   create mode 100644 
> > >drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c
> > >   create mode 100644 
> > >drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.h
> > 
> > --snip--
> > 
> > > +/*anttenna control by bb mac bt antdiv pta to write 0x4c 0xcb4,0xcbd*/
> > > +
> > > +static
> > > +void hallbtc882b1ant_set_ant_switch(struct btc_coexist *btcoexist,
> > > + bool force_exec, u8 ctrl_type,
> > > + u8 pos_type)
> > > +{
> > > + struct rtl_priv *rtlpriv = btcoexist->adapter;
> > > + bool switch_polatiry_inverse = false;
> > > + u8 regval_0xcbd = 0, regval_0x64;
> > > + u32 u32tmp1 = 0, u32tmp2 = 0, u32tmp3 = 0;
> > > +
> > > + /* Ext switch buffer mux */
> > > + btcoexist->btc_write_1byte(btcoexist, 0x974, 0xff);
> > > + btcoexist->btc_write_1byte_bitmask(btcoexist, 0x1991, 0x3, 0x0);
> > > + btcoexist->btc_write_1byte_bitmask(btcoexist, 0xcbe, 0x8, 0x0);
> > > +
> > > + if (!rfe_type->ext_ant_switch_exist)
> > > + return;
> > > +
> > > + coex_dm->cur_ext_ant_switch_status = (ctrl_type << 8) + pos_type;
> > > +
> > > + if (!force_exec) {
> > > + if (coex_dm->pre_ext_ant_switch_status ==
> > > + coex_dm->cur_ext_ant_switch_status)
> > > + return;
> > > + }
> > > +
> > > + coex_dm->pre_ext_ant_switch_status = coex_dm->cur_ext_ant_switch_status;
> > > +
> > > + /* swap control polarity if use different switch control polarity*/
> > > + /* Normal switch polarity for SPDT,
> > > +  * 0xcbd[1:0] = 2b'01 => Ant to BTG, WLA
> > > +  * 0xcbd[1:0] = 2b'10 => Ant to WLG
> > > +  */
> > > + switch_polatiry_inverse = (rfe_type->ext_ant_switch_ctrl_polarity == 1 ?
> > > +    ~switch_polatiry_inverse :
> > > +    switch_polatiry_inverse);
> > 
> > gcc 7.3.1 reports the following:
> > 
> >    CC [M]  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.o
> > drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c: In 
> > function 
> > ‘hallbtc882b1ant_set_ant_switch’:
> > drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c:2193:9: 
> > warning: ‘~’ on a boolean expression [-Wbool-operation]
> >   ~switch_polatiry_inverse :
> >   ^
> > drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c:2193:9: 
> > note: 
> > did you mean to use logical not?
> >   ~switch_polatiry_inverse :
> >   ^
> > 
> > For a boolean, you should use !bool, not -bool. In addition, it would be 
> > better 
> > to use switch_polarity_inverse, not switch_polatiry_inverse. The same 
> > "typo" 
> > happens in other places in this file. I suggest
> > 
> > sed -i 's/polatiry_inverse/polarity_inverse/g' \
> > drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c.
> > 
> 
> I'll fix the typo, and declare the variable switch_polarity_inverse without
> initial value, then assign value true or false in the line mentioned in above
> warning. It looks like:
>   bool switch_polatiry_inverse;
>   ...
>   switch_polarity_inverse = (rfe_type->ext_ant_switch_ctrl_polarity == 1 
> ?
>      true : false);
> 

Fix the last expression again:

switch_polarity_inverse = (rfe_type->ext_ant_switch_ctrl_polarity == 1);

Re: [PATCH 1/9] rtlwifi: btcoex: Add 8822b1ant coex files

[Pkshih]

On Wed, 2018-04-04 at 02:43 +, Larry Finger wrote:
> On 03/28/2018 02:27 AM, pks...@realtek.com wrote:
> > From: Ping-Ke Shih 
> > 
> > This file supports 8822be WiFi module with two physical antenna that
> > means one antenna will share with BT.
> > 
> > Signed-off-by: Ping-Ke Shih 
> > ---
> >   .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5303 
> >
> >   .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.h|  413 ++
> >   2 files changed, 5716 insertions(+)
> >   create mode 100644 
> >drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c
> >   create mode 100644 
> >drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.h
> 
> --snip--
> 
> > +/*anttenna control by bb mac bt antdiv pta to write 0x4c 0xcb4,0xcbd*/
> > +
> > +static
> > +void hallbtc882b1ant_set_ant_switch(struct btc_coexist *btcoexist,
> > +   bool force_exec, u8 ctrl_type,
> > +   u8 pos_type)
> > +{
> > +   struct rtl_priv *rtlpriv = btcoexist->adapter;
> > +   bool switch_polatiry_inverse = false;
> > +   u8 regval_0xcbd = 0, regval_0x64;
> > +   u32 u32tmp1 = 0, u32tmp2 = 0, u32tmp3 = 0;
> > +
> > +   /* Ext switch buffer mux */
> > +   btcoexist->btc_write_1byte(btcoexist, 0x974, 0xff);
> > +   btcoexist->btc_write_1byte_bitmask(btcoexist, 0x1991, 0x3, 0x0);
> > +   btcoexist->btc_write_1byte_bitmask(btcoexist, 0xcbe, 0x8, 0x0);
> > +
> > +   if (!rfe_type->ext_ant_switch_exist)
> > +   return;
> > +
> > +   coex_dm->cur_ext_ant_switch_status = (ctrl_type << 8) + pos_type;
> > +
> > +   if (!force_exec) {
> > +   if (coex_dm->pre_ext_ant_switch_status ==
> > +   coex_dm->cur_ext_ant_switch_status)
> > +   return;
> > +   }
> > +
> > +   coex_dm->pre_ext_ant_switch_status = coex_dm->cur_ext_ant_switch_status;
> > +
> > +   /* swap control polarity if use different switch control polarity*/
> > +   /* Normal switch polarity for SPDT,
> > +    * 0xcbd[1:0] = 2b'01 => Ant to BTG, WLA
> > +    * 0xcbd[1:0] = 2b'10 => Ant to WLG
> > +    */
> > +   switch_polatiry_inverse = (rfe_type->ext_ant_switch_ctrl_polarity == 1 ?
> > +      ~switch_polatiry_inverse :
> > +      switch_polatiry_inverse);
> 
> gcc 7.3.1 reports the following:
> 
>    CC [M]  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.o
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c: In function 
> ‘hallbtc882b1ant_set_ant_switch’:
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c:2193:9: 
> warning: ‘~’ on a boolean expression [-Wbool-operation]
>   ~switch_polatiry_inverse :
>   ^
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c:2193:9: 
> note: 
> did you mean to use logical not?
>   ~switch_polatiry_inverse :
>   ^
> 
> For a boolean, you should use !bool, not -bool. In addition, it would be 
> better 
> to use switch_polarity_inverse, not switch_polatiry_inverse. The same "typo" 
> happens in other places in this file. I suggest
> 
> sed -i 's/polatiry_inverse/polarity_inverse/g' \
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c.
> 

I'll fix the typo, and declare the variable switch_polarity_inverse without
initial value, then assign value true or false in the line mentioned in above
warning. It looks like:
bool switch_polatiry_inverse;
...
switch_polarity_inverse = (rfe_type->ext_ant_switch_ctrl_polarity == 1 ?


   true : false);


PK

Re: [PATCH] nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS

[Johannes Berg]

Hi,

> Started working on this and actually the "weird flags thing" is done for 
> a reason. Maybe the reason was because it is done like that in the 
> CMD_CONNECT case, but the better reason is that we need to return 
> -EINVAL for "no-fils-offload-support, any-fils-param" *and* 
> "fils-offload-support, not-all-fils-param".

Ok, fair enough.

> > Also there is a DOC section about FILS shared key authentication
> > offload" so I suppose that should be extended as well.
> 
> So looking at the DOC section I am reading the following:
> 
>   * When FILS shared key authentication is completed, driver needs to 
> provide the
>   * below additional parameters to userspace.
>   *   %NL80211_ATTR_FILS_KEK - used for key renewal
>   *   %NL80211_ATTR_FILS_ERP_NEXT_SEQ_NUM - used in further EAP-RP exchanges
>   *   %NL80211_ATTR_PMKID - used to identify the PMKSA used/generated
>   *   %Nl80211_ATTR_PMK - used to update PMKSA cache in userspace
>   * The PMKSA can be maintained in userspace persistently so that it can 
> be used
>   * later after reboots or wifi turn off/on also.
> 
> So to me it seems we need these for the ROAM event as well. Agree?

Maybe not all of them, you could be using the same PMKSA, but yes, I
tend to agree.

johannes

Re: [PATCH] nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS

[Arend van Spriel]

On 3/29/2018 1:31 PM, Arend van Spriel wrote:

So yeah, I'd argue that what the patch needed was somebody taking a
critical look at my review ;-)

And perhaps fixing the weird flags thing I pointed out.


Yup. That made sense.


Hi Johannes,

Started working on this and actually the "weird flags thing" is done for 
a reason. Maybe the reason was because it is done like that in the 
CMD_CONNECT case, but the better reason is that we need to return 
-EINVAL for "no-fils-offload-support, any-fils-param" *and* 
"fils-offload-support, not-all-fils-param".



Also there is a DOC section about FILS shared key authentication
offload" so I suppose that should be extended as well.


So looking at the DOC section I am reading the following:

 * When FILS shared key authentication is completed, driver needs to 
provide the

 * below additional parameters to userspace.
 *  %NL80211_ATTR_FILS_KEK - used for key renewal
 *  %NL80211_ATTR_FILS_ERP_NEXT_SEQ_NUM - used in further EAP-RP exchanges
 *  %NL80211_ATTR_PMKID - used to identify the PMKSA used/generated
 *  %Nl80211_ATTR_PMK - used to update PMKSA cache in userspace
 * The PMKSA can be maintained in userspace persistently so that it can 
be used

 * later after reboots or wifi turn off/on also.

So to me it seems we need these for the ROAM event as well. Agree?

Regards,
Arend

[PATCH] mt76x2: set default values in TX_ALC_CFG_{1,2} for tempetaure compensation

[Lorenzo Bianconi]

Initialize default values for temperature compensation in TX_ALC_CFG_{1,2}
if tssi has been enabled

Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
index 42414c5fa01e..daecc7ea900a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
@@ -660,6 +660,14 @@ int mt76x2_phy_set_channel(struct mt76x2_dev *dev,
memcpy(dev->cal.agc_gain_cur, dev->cal.agc_gain_init,
   sizeof(dev->cal.agc_gain_cur));
 
+   /* init default values for temp compensation */
+   if (mt76x2_tssi_enabled(dev)) {
+   mt76_rmw_field(dev, MT_TX_ALC_CFG_1, MT_TX_ALC_CFG_1_TEMP_COMP,
+  0x38);
+   mt76_rmw_field(dev, MT_TX_ALC_CFG_2, MT_TX_ALC_CFG_2_TEMP_COMP,
+  0x38);
+   }
+
ieee80211_queue_delayed_work(mt76_hw(dev), >cal_work,
 MT_CALIBRATE_INTERVAL);
 
-- 
2.14.3

[PATCH] mt76x2: fix tx_alc_enabled check

[Lorenzo Bianconi]

Fix mt76x2_temp_tx_alc_enabled routine since in order to enable tx_alc
temperature compensation it necessary to take into account BIT(15) of
MT_EE_TX_POWER_EXT_PA_5G eeprom info

Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e")
Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c | 6 +-
 drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h | 6 ++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c
index 5bb50027c1e8..95d5f7d888f0 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c
@@ -609,17 +609,13 @@ int mt76x2_get_temp_comp(struct mt76x2_dev *dev, struct 
mt76x2_temp_comp *t)
 
memset(t, 0, sizeof(*t));
 
-   val = mt76x2_eeprom_get(dev, MT_EE_NIC_CONF_1);
-   if (!(val & MT_EE_NIC_CONF_1_TEMP_TX_ALC))
+   if (!mt76x2_temp_tx_alc_enabled(dev))
return -EINVAL;
 
if (!mt76x2_ext_pa_enabled(dev, band))
return -EINVAL;
 
val = mt76x2_eeprom_get(dev, MT_EE_TX_POWER_EXT_PA_5G) >> 8;
-   if (!(val & BIT(7)))
-   return -EINVAL;
-
t->temp_25_ref = val & 0x7f;
if (band == NL80211_BAND_5GHZ) {
slope = mt76x2_eeprom_get(dev, MT_EE_RF_TEMP_COMP_SLOPE_5G);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h 
b/drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h
index d79122728dca..aa0b0c040375 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h
@@ -159,6 +159,12 @@ void mt76x2_read_rx_gain(struct mt76x2_dev *dev);
 static inline bool
 mt76x2_temp_tx_alc_enabled(struct mt76x2_dev *dev)
 {
+   u16 val;
+
+   val = mt76x2_eeprom_get(dev, MT_EE_TX_POWER_EXT_PA_5G);
+   if (!(val & BIT(15)))
+   return false;
+
return mt76x2_eeprom_get(dev, MT_EE_NIC_CONF_1) &
   MT_EE_NIC_CONF_1_TEMP_TX_ALC;
 }
-- 
2.14.3

Re: Request for brcmfmac4366c-pcie.bin

[Arend van Spriel]

On 4/4/2018 4:12 AM, Hubert Wiedeke wrote:

On Mon, 19 Feb 2018 12:51:07 +0100
Arend van Spriel  wrote:


On 2/17/2018 9:19 AM, Hubert Wiedeke wrote:

Hi,

I'd like to ask about the current status of 4366c firmware preparation for 
linux-firmware.git . Is it close to finish? What about DFS? Nothing critical, 
just a question.


I have prepared some firmware changes for 4366, but did not manage to
get any test-cycles for it.

Regards,
Arend



Could you please estimate any possible dates for the tested FW to be released?


Not really. Linux open-source work is getting rather low prio when it 
comes to claiming test lab resources. Best I can say is somewhere this year.


Regards,
Arend

Re: [PATCH 3/3] wcn36xx: don't delete invalid bss indices

[Daniel Mack]

On Wednesday, April 04, 2018 07:40 AM, Ramon Fried wrote:
> On 4/3/2018 7:51 PM, Daniel Mack wrote:
>> The firmware code cannot cope with requests to remove BSS indices that have
>> not previously been added. This primarily happens when the device is
>> suspended and then resumed. ieee80211_reconfig() then calls into
>> wcn36xx_bss_info_changed() with an empty bssid and BSS_CHANGED_BSSID set,
>> which subsequently leads to a firmware crash:
>>
>> [   43.647928] qcom-wcnss-pil a204000.wcnss: fatal error received: 
>> halMsg.c:4964:halMsg_DelBss: Invalid BSSIndex 0
>> [   43.647959] remoteproc remoteproc0: crash detected in a204000.wcnss: type 
>> fatal error
>>
>> To fix this, set bss_index to WCN36XX_HAL_BSS_INVALID_IDX for all bss
>> that have not been configured in the firmware, and don't call into the
>> firmware with invalid indices.
>>
>> Signed-off-by: Daniel Mack 

> Interesting. I have never seen this bug before.
> Do you have a way of recreating it so I can test it on my side ?

I tested this by putting the machine to suspend with

  # echo freeze >/sys/power/state

right after boot, without connecting to a network before. Resume will
then fail without this patch. I haven't see it in any other cases either
though.


Thanks,
Daniel

[PATCH] iwlwifi: mvm: query regdb for wmm rule if needed

[Luca Coelho]

From: Haim Dreyfuss 

Since our device is regulatory self managed it maintains its regulatory
rules by its own. However the wmm_rules values can't be set by the
device itself but only the indication about the need to set it.
In case the device set wmm indication, proactively query the regulatory
data base to get these values

Signed-off-by: Haim Dreyfuss 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 111 ++---
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h |   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |   3 +-
 3 files changed, 101 insertions(+), 19 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index 8928613e033e..ca0174680af9 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -76,6 +76,7 @@
 #include "iwl-io.h"
 #include "iwl-csr.h"
 #include "fw/acpi.h"
+#include "fw/api/nvm-reg.h"
 
 /* NVM offsets (in words) definitions */
 enum nvm_offsets {
@@ -146,8 +147,8 @@ static const u8 iwl_ext_nvm_channels[] = {
149, 153, 157, 161, 165, 169, 173, 177, 181
 };
 
-#define IWL_NUM_CHANNELS   ARRAY_SIZE(iwl_nvm_channels)
-#define IWL_NUM_CHANNELS_EXT   ARRAY_SIZE(iwl_ext_nvm_channels)
+#define IWL_NVM_NUM_CHANNELS   ARRAY_SIZE(iwl_nvm_channels)
+#define IWL_NVM_NUM_CHANNELS_EXT   ARRAY_SIZE(iwl_ext_nvm_channels)
 #define NUM_2GHZ_CHANNELS  14
 #define NUM_2GHZ_CHANNELS_EXT  14
 #define FIRST_2GHZ_HT_MINUS5
@@ -301,11 +302,11 @@ static int iwl_init_channel_map(struct device *dev, const 
struct iwl_cfg *cfg,
const u8 *nvm_chan;
 
if (cfg->nvm_type != IWL_NVM_EXT) {
-   num_of_ch = IWL_NUM_CHANNELS;
+   num_of_ch = IWL_NVM_NUM_CHANNELS;
nvm_chan = _nvm_channels[0];
num_2ghz_channels = NUM_2GHZ_CHANNELS;
} else {
-   num_of_ch = IWL_NUM_CHANNELS_EXT;
+   num_of_ch = IWL_NVM_NUM_CHANNELS_EXT;
nvm_chan = _ext_nvm_channels[0];
num_2ghz_channels = NUM_2GHZ_CHANNELS_EXT;
}
@@ -720,12 +721,12 @@ iwl_parse_nvm_data(struct iwl_trans *trans, const struct 
iwl_cfg *cfg,
if (cfg->nvm_type != IWL_NVM_EXT)
data = kzalloc(sizeof(*data) +
   sizeof(struct ieee80211_channel) *
-  IWL_NUM_CHANNELS,
+  IWL_NVM_NUM_CHANNELS,
   GFP_KERNEL);
else
data = kzalloc(sizeof(*data) +
   sizeof(struct ieee80211_channel) *
-  IWL_NUM_CHANNELS_EXT,
+  IWL_NVM_NUM_CHANNELS_EXT,
   GFP_KERNEL);
if (!data)
return NULL;
@@ -842,24 +843,34 @@ static u32 iwl_nvm_get_regdom_bw_flags(const u8 *nvm_chan,
return flags;
 }
 
+struct regdb_ptrs {
+   struct ieee80211_wmm_rule *rule;
+   u32 token;
+};
+
 struct ieee80211_regdomain *
 iwl_parse_nvm_mcc_info(struct device *dev, const struct iwl_cfg *cfg,
-  int num_of_ch, __le32 *channels, u16 fw_mcc)
+  int num_of_ch, __le32 *channels, u16 fw_mcc,
+  u16 geo_info)
 {
int ch_idx;
u16 ch_flags;
u32 reg_rule_flags, prev_reg_rule_flags = 0;
const u8 *nvm_chan = cfg->nvm_type == IWL_NVM_EXT ?
 iwl_ext_nvm_channels : iwl_nvm_channels;
-   struct ieee80211_regdomain *regd;
-   int size_of_regd;
+   struct ieee80211_regdomain *regd, *copy_rd;
+   int size_of_regd, regd_to_copy, wmms_to_copy;
+   int size_of_wmms = 0;
struct ieee80211_reg_rule *rule;
+   struct ieee80211_wmm_rule *wmm_rule, *d_wmm, *s_wmm;
+   struct regdb_ptrs *regdb_ptrs;
enum nl80211_band band;
int center_freq, prev_center_freq = 0;
-   int valid_rules = 0;
+   int valid_rules = 0, n_wmms = 0;
+   int i;
bool new_rule;
int max_num_ch = cfg->nvm_type == IWL_NVM_EXT ?
-IWL_NUM_CHANNELS_EXT : IWL_NUM_CHANNELS;
+IWL_NVM_NUM_CHANNELS_EXT : IWL_NVM_NUM_CHANNELS;
 
if (WARN_ON_ONCE(num_of_ch > NL80211_MAX_SUPP_REG_RULES))
return ERR_PTR(-EINVAL);
@@ -875,10 +886,26 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct 
iwl_cfg *cfg,
sizeof(struct ieee80211_regdomain) +
num_of_ch * sizeof(struct ieee80211_reg_rule);
 
-   regd = kzalloc(size_of_regd, GFP_KERNEL);
+   if (geo_info & GEO_WMM_ETSI_5GHZ_INFO)
+   size_of_wmms =
+   num_of_ch * sizeof(struct ieee80211_wmm_rule);
+
+   regd = 

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Kalle Valo]

Steve deRosier  writes:

> On Tue, Apr 3, 2018 at 5:39 AM, Sunil Dutt Undekari
>  wrote:
>> Hi All ,
>>
>> I would like to discuss on the commit
>> 8125696991194aacb1173b6e8196d19098b44e17 (cfg80211/mac80211:
>> disconnect on suspend) which triggers the STA disconnection on
>> suspend if no wowlan triggers are registered.
>
> This commit went in over five years ago. Sometime around v3.9

Yup, v3.10-rc2 was the first release.

-- 
Kalle Valo