Re: [PATCH] ath9k: Add cast to u8 to FREQ2FBIN macro

[Joe Perches]

On Thu, 2017-04-06 at 16:54 -0700, Matthias Kaehlcke wrote:
> Hi Joe,
> 
> El Thu, Apr 06, 2017 at 02:29:20PM -0700 Joe Perches ha dit:
> 
> > On Thu, 2017-04-06 at 14:21 -0700, Matthias Kaehlcke wrote:
> > > The macro results are assigned to u8 variables/fields. Adding the cast
> > > fixes plenty of clang warnings about "implicit conversion from 'int' to
> > > 'u8'".
> > > 
> > > Signed-off-by: Matthias Kaehlcke 
> > > ---
> > >  drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h 
> > > b/drivers/net/wireless/ath/ath9k/eeprom.h
> > > index 30bf722e33ed..31390af6c33e 100644
> > > --- a/drivers/net/wireless/ath/ath9k/eeprom.h
> > > +++ b/drivers/net/wireless/ath/ath9k/eeprom.h
> > > @@ -106,7 +106,7 @@
> > >  #define AR9285_RDEXT_DEFAULT0x1F
> > >  
> > >  #define ATH9K_POW_SM(_r, _s) (((_r) & 0x3f) << (_s))
> > > -#define FREQ2FBIN(x, y)  ((y) ? ((x) - 2300) : (((x) - 4800) / 
> > > 5))
> > > +#define FREQ2FBIN(x, y)  (u8)((y) ? ((x) - 2300) : (((x) - 4800) 
> > > / 5))
> > 
> > Maybe better to use:
> > 
> > static inline u8 FREQ2FBIN(int x, int y)
> > {
> > if (y)
> > return x - 2300;
> > return (x - 4800) / 5;
> > }
> 
> Thanks for your suggestion! Unfortunately in this case an inline
> function is not suitable since FREQ2FBIN() is mostly used for
> structure initialization:
> 
> static const struct ar9300_eeprom ar9300_default = {
> ...
> .calFreqPier2G = {
> FREQ2FBIN(2412, 1),
> FREQ2FBIN(2437, 1),
> FREQ2FBIN(2472, 1)
> },
> ...

Maybe it's better to remove the second argument and write
something like:

#define FREQ2FBIN(x) \
(u8)(((x) >= 2300 && (x) <= 2555) ? (x) - 2300 : \
 ((x) >= 4800 && (x) <= 4800 + (256 * 5) ? ((x) - 4800) / 5) : \
 __builtin_const_p(x) ? BUILD_BUG_ON(1) : 0)

Re: [PATCH] ath9k: Add cast to u8 to FREQ2FBIN macro

[Matthias Kaehlcke]

Hi Joe,

El Thu, Apr 06, 2017 at 02:29:20PM -0700 Joe Perches ha dit:

> On Thu, 2017-04-06 at 14:21 -0700, Matthias Kaehlcke wrote:
> > The macro results are assigned to u8 variables/fields. Adding the cast
> > fixes plenty of clang warnings about "implicit conversion from 'int' to
> > 'u8'".
> > 
> > Signed-off-by: Matthias Kaehlcke 
> > ---
> >  drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h 
> > b/drivers/net/wireless/ath/ath9k/eeprom.h
> > index 30bf722e33ed..31390af6c33e 100644
> > --- a/drivers/net/wireless/ath/ath9k/eeprom.h
> > +++ b/drivers/net/wireless/ath/ath9k/eeprom.h
> > @@ -106,7 +106,7 @@
> >  #define AR9285_RDEXT_DEFAULT0x1F
> >  
> >  #define ATH9K_POW_SM(_r, _s)   (((_r) & 0x3f) << (_s))
> > -#define FREQ2FBIN(x, y)((y) ? ((x) - 2300) : (((x) - 4800) / 
> > 5))
> > +#define FREQ2FBIN(x, y)(u8)((y) ? ((x) - 2300) : (((x) - 4800) 
> > / 5))
> 
> Maybe better to use:
> 
> static inline u8 FREQ2FBIN(int x, int y)
> {
>   if (y)
>   return x - 2300;
>   return (x - 4800) / 5;
> }

Thanks for your suggestion! Unfortunately in this case an inline
function is not suitable since FREQ2FBIN() is mostly used for
structure initialization:

static const struct ar9300_eeprom ar9300_default = {
...
.calFreqPier2G = {
FREQ2FBIN(2412, 1),
FREQ2FBIN(2437, 1),
FREQ2FBIN(2472, 1),
},
...

Cheers

Matthias

[PATCH v2] mac80211: Fix clang warning about constant operand in logical operation

[Matthias Kaehlcke]

When clang detects a non-boolean constant in a logical operation it
generates a 'constant-logical-operand' warning. In
ieee80211_try_rate_control_ops_get() the result of strlen()
is used in a logical operation, clang resolves the expression to an
(integer) constant at compile time when clang's builtin strlen function
is used.

Change the condition to check for strlen() > 0 to make the constant
operand boolean and thus avoid the warning.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v2:
- Changed expression to strlen() > 0 to make constant operand boolean
  instead of splitting up condition
- Updated commit message

 net/mac80211/rate.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 206698bc93f4..694faf6ab574 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -173,9 +173,11 @@ ieee80211_rate_control_ops_get(const char *name)
/* try default if specific alg requested but not found */
ops = 
ieee80211_try_rate_control_ops_get(ieee80211_default_rc_algo);
 
-   /* try built-in one if specific alg requested but not found */
-   if (!ops && strlen(CONFIG_MAC80211_RC_DEFAULT))
+   /* Note: check for > 0 is intentional to avoid clang warning */
+   if (!ops && (strlen(CONFIG_MAC80211_RC_DEFAULT) > 0))
+   /* try built-in one if specific alg requested but not found */
ops = 
ieee80211_try_rate_control_ops_get(CONFIG_MAC80211_RC_DEFAULT);
+
kernel_param_unlock(THIS_MODULE);
 
return ops;
-- 
2.12.2.715.g7642488e1d-goog

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

[Johannes Berg]

On Thu, 2017-04-06 at 15:42 -0700, Matthias Kaehlcke wrote:
> 
> Thanks, it would also require to move the initialization of
> ieee80211_default_rc_algo into an ifdef. If you can live with such a
> solution I'm happy to change it.

I think that'd be something I can live with, yeah.

> > git grep 'IS_ENABLED(' | grep '&&'
> 
> Indeed the warning is not triggered by these constructs. It seems
> clang only emits the warning when the constant operand is not
> boolean.

That points to just adding "> 0" to the condition here as another
alternative solution, I guess? With a comment to make sure it's not
removed again, that'd seem like the best thing to do.

johannes

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

[Matthias Kaehlcke]

El Thu, Apr 06, 2017 at 11:12:25PM +0200 Johannes Berg ha dit:

> On Thu, 2017-04-06 at 12:24 -0700, Matthias Kaehlcke wrote:
> 
> > I agree that the code looks worse :( I hoped to find a fix using a
> > preprocessor condition but wasn't successful.
> 
> It's actually easy - just remove the 'default ""' from Kconfig, and
> then the symbol won't be defined at all if it doesn't get a proper
> value. Then you can ifdef the whole thing.

Thanks, it would also require to move the initialization of
ieee80211_default_rc_algo into an ifdef. If you can live with such a
solution I'm happy to change it.

> > Some projects (like Chrome OS) build their kernel with all warnings
> > being treated as errors. Besides changing the 'offending' code the
> > alternatives are to disable the warning completely or to tell clang
> > not to use the builtin(s). IMO changing the code is the preferable
> > solution, especially since this is so far the only occurrence of the
> > warning that I have encountered.
> > 
> > I used goto instead of nested ifs since other functions in this file
> > use the same pattern. If nested ifs are preferred I can change that.
> 
> I don't really buy either argument. The warning is simply bogus - I'm
> very surprised you don't hit it with more similar macros or cases, like
> for example CONFIG_ENABLED(). Try
> 
>   git grep 'IS_ENABLED(' | grep '&&'
> 
> and you'll find lots of places that seem like they should trigger this
> warning.

Indeed the warning is not triggered by these constructs. It seems
clang only emits the warning when the constant operand is not boolean.

> You're advocating to make the code worse - not very significantly in
> this case, but still - just to quiet a compiler warning.

For Chrome OS we need to quiet the warning in one way or another,
otherwise our builds will fail due to warnings being treated as
errors. I'm reluctant to disable the warning completely since it can
be useful to detect certain errors, e.g. the use of a logical operator
when bitwise was intended.

And yes, in this case I would favor the slight deterioration of a
small section of code over losing a potentially useful check on the
entire kernel code.

I agree that this is a bit of a corner case, the code is definitely
not buggy by itself, ideally clang would detect that the constant is
a result of its own optimization and skip the warning.

Obviously we can always apply a patch locally, but ideally we try to
upstream changes that seem of general use so that others and our
future selves can benefit from it.

I have no intention to insist on this, we can live with a local patch
if you don't think it is useful.

Cheers

Matthias

Re: [PATCH] ath9k: Add cast to u8 to FREQ2FBIN macro

[Joe Perches]

On Thu, 2017-04-06 at 14:21 -0700, Matthias Kaehlcke wrote:
> The macro results are assigned to u8 variables/fields. Adding the cast
> fixes plenty of clang warnings about "implicit conversion from 'int' to
> 'u8'".
> 
> Signed-off-by: Matthias Kaehlcke 
> ---
>  drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h 
> b/drivers/net/wireless/ath/ath9k/eeprom.h
> index 30bf722e33ed..31390af6c33e 100644
> --- a/drivers/net/wireless/ath/ath9k/eeprom.h
> +++ b/drivers/net/wireless/ath/ath9k/eeprom.h
> @@ -106,7 +106,7 @@
>  #define AR9285_RDEXT_DEFAULT0x1F
>  
>  #define ATH9K_POW_SM(_r, _s) (((_r) & 0x3f) << (_s))
> -#define FREQ2FBIN(x, y)  ((y) ? ((x) - 2300) : (((x) - 4800) / 
> 5))
> +#define FREQ2FBIN(x, y)  (u8)((y) ? ((x) - 2300) : (((x) - 4800) 
> / 5))

Maybe better to use:

static inline u8 FREQ2FBIN(int x, int y)
{
if (y)
return x - 2300;
return (x - 4800) / 5;
}

[PATCH] ath9k: Add cast to u8 to FREQ2FBIN macro

[Matthias Kaehlcke]

The macro results are assigned to u8 variables/fields. Adding the cast
fixes plenty of clang warnings about "implicit conversion from 'int' to
'u8'".

Signed-off-by: Matthias Kaehlcke 
---
 drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h 
b/drivers/net/wireless/ath/ath9k/eeprom.h
index 30bf722e33ed..31390af6c33e 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -106,7 +106,7 @@
 #define AR9285_RDEXT_DEFAULT0x1F
 
 #define ATH9K_POW_SM(_r, _s)   (((_r) & 0x3f) << (_s))
-#define FREQ2FBIN(x, y)((y) ? ((x) - 2300) : (((x) - 4800) / 
5))
+#define FREQ2FBIN(x, y)(u8)((y) ? ((x) - 2300) : (((x) - 4800) 
/ 5))
 #define FBIN2FREQ(x, y)((y) ? (2300 + x) : (4800 + 5 * x))
 #define ath9k_hw_use_flash(_ah)(!(_ah->ah_flags & AH_USE_EEPROM))
 
-- 
2.12.2.715.g7642488e1d-goog

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

[Johannes Berg]

On Thu, 2017-04-06 at 12:24 -0700, Matthias Kaehlcke wrote:

> I agree that the code looks worse :( I hoped to find a fix using a
> preprocessor condition but wasn't successful.

It's actually easy - just remove the 'default ""' from Kconfig, and
then the symbol won't be defined at all if it doesn't get a proper
value. Then you can ifdef the whole thing.

> Some projects (like Chrome OS) build their kernel with all warnings
> being treated as errors. Besides changing the 'offending' code the
> alternatives are to disable the warning completely or to tell clang
> not to use the builtin(s). IMO changing the code is the preferable
> solution, especially since this is so far the only occurrence of the
> warning that I have encountered.
> 
> I used goto instead of nested ifs since other functions in this file
> use the same pattern. If nested ifs are preferred I can change that.

I don't really buy either argument. The warning is simply bogus - I'm
very surprised you don't hit it with more similar macros or cases, like
for example CONFIG_ENABLED(). Try

git grep 'IS_ENABLED(' | grep '&&'

and you'll find lots of places that seem like they should trigger this
warning.

You're advocating to make the code worse - not very significantly in
this case, but still - just to quiet a compiler warning.

johannes

[PATCH 05/11] rtlwifi: btcoex: 23b 2ant: wifi is not actually off in mp mode

[Larry Finger]

From: Yan-Hsuan Chuang 

In mp mode, the wifi will not turn off and still has control of the PTA,
so the driver needs to distinguish whether it is mp mode or not

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 .../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c   | 10 ++
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h  |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 93dbbc507ba1..70f21059ddc3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -3606,6 +3606,7 @@ static void btc8723b2ant_run_coexist_mechanism(struct 
btc_coexist *btcoexist)
 
 static void btc8723b2ant_wifioff_hwcfg(struct btc_coexist *btcoexist)
 {
+   bool is_in_mp_mode = false;
u8 h2c_parameter[2] = {0};
u32 fw_ver = 0;
 
@@ -3623,6 +3624,15 @@ static void btc8723b2ant_wifioff_hwcfg(struct 
btc_coexist *btcoexist)
} else {
btcoexist->btc_write_1byte(btcoexist, 0x765, 0x18);
}
+
+   btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_IS_IN_MP_MODE,
+  _in_mp_mode);
+   if (!is_in_mp_mode)
+   /* BT select s0/s1 is controlled by BT */
+   btcoexist->btc_write_1byte_bitmask(btcoexist, 0x67, 0x20, 0x0);
+   else
+   /* BT select s0/s1 is controlled by WiFi */
+   btcoexist->btc_write_1byte_bitmask(btcoexist, 0x67, 0x20, 0x1);
 }
 
 /*
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 022658cafbca..0b90e7f0b722 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -205,6 +205,7 @@ enum btc_get_type {
BTC_GET_BL_WIFI_ENABLE_ENCRYPTION,
BTC_GET_BL_WIFI_UNDER_B_MODE,
BTC_GET_BL_EXT_SWITCH,
+   BTC_GET_BL_WIFI_IS_IN_MP_MODE,
 
/* type s4Byte */
BTC_GET_S4_WIFI_RSSI,
-- 
2.12.0

[PATCH 04/11] rtlwifi: btcoex: 23b 2ant: need those information when scan

[Larry Finger]

From: Yan-Hsuan Chuang 

For scan notify, we need to supervise some registers to make sure that
coexistence is operating as we expected.

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 .../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c   | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 9c169d094b51..93dbbc507ba1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -3934,6 +3934,12 @@ void ex_btc8723b2ant_lps_notify(struct btc_coexist 
*btcoexist, u8 type)
 void ex_btc8723b2ant_scan_notify(struct btc_coexist *btcoexist, u8 type)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   u32 u32tmp;
+   u8 u8tmpa, u8tmpb;
+
+   u32tmp = btcoexist->btc_read_4byte(btcoexist, 0x948);
+   u8tmpa = btcoexist->btc_read_1byte(btcoexist, 0x765);
+   u8tmpb = btcoexist->btc_read_1byte(btcoexist, 0x76e);
 
if (BTC_SCAN_START == type)
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
@@ -3943,6 +3949,10 @@ void ex_btc8723b2ant_scan_notify(struct btc_coexist 
*btcoexist, u8 type)
 "[BTCoex], SCAN FINISH notify\n");
btcoexist->btc_get(btcoexist, BTC_GET_U1_AP_NUM,
   _sta->scan_ap_num);
+
+   RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
+"# [BTCoex], 0x948=0x%x, 0x765=0x%x, 0x76e=0x%x\n",
+   u32tmp, u8tmpa, u8tmpb);
 }
 
 void ex_btc8723b2ant_connect_notify(struct btc_coexist *btcoexist, u8 type)
-- 
2.12.0

[PATCH 06/11] rtlwifi: btcoex: 23b 2ant: power on settings for coex

[Larry Finger]

From: Yan-Hsuan Chuang 

When power on, the wifi could be initiating, force the antenna to
transmit bt packets to avoid bt unstable problems

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 31 ++
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  1 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 70f21059ddc3..0f3d04529ff2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -3669,6 +3669,37 @@ void ex_btc8723b2ant_init_hwconfig(struct btc_coexist 
*btcoexist)
btcoexist->btc_write_1byte_bitmask(btcoexist, 0x40, 0x20, 0x1);
 }
 
+void ex_btc8723b2ant_power_on_setting(struct btc_coexist *btcoexist)
+{
+   struct btc_board_info *board_info = >board_info;
+   u16 u16tmp = 0x0;
+   u32 value = 0;
+
+   btcoexist->btc_write_1byte(btcoexist, 0x67, 0x20);
+
+   /* enable BB, REG_SYS_FUNC_EN such that we can write 0x948 correctly */
+   u16tmp = btcoexist->btc_read_2byte(btcoexist, 0x2);
+   btcoexist->btc_write_2byte(btcoexist, 0x2, u16tmp | BIT0 | BIT1);
+
+   btcoexist->btc_write_4byte(btcoexist, 0x948, 0x0);
+
+   if (btcoexist->chip_interface == BTC_INTF_USB) {
+   /* fixed at S0 for USB interface */
+   board_info->btdm_ant_pos = BTC_ANTENNA_AT_AUX_PORT;
+   } else {
+   /* for PCIE and SDIO interface, we check efuse 0xc3[6] */
+   if (board_info->single_ant_path == 0) {
+   /* set to S1 */
+   board_info->btdm_ant_pos = BTC_ANTENNA_AT_MAIN_PORT;
+   } else if (board_info->single_ant_path == 1) {
+   /* set to S0 */
+   board_info->btdm_ant_pos = BTC_ANTENNA_AT_AUX_PORT;
+   }
+   btcoexist->btc_set(btcoexist, BTC_SET_ACT_ANTPOSREGRISTRY_CTRL,
+  );
+   }
+}
+
 void ex_btc8723b2ant_init_coex_dm(struct btc_coexist *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 0b90e7f0b722..5a34cd895e44 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -139,6 +139,7 @@ struct btc_board_info {
u8 pg_ant_num;  /* pg ant number */
u8 btdm_ant_num;/* ant number for btdm */
u8 btdm_ant_pos;
+   u8 single_ant_path; /* current used for 8723b only, 1=>s0,  0=>s1 */
bool bt_exist;
 };
 
-- 
2.12.0

[PATCH 10/11] rtlwifi: btcoex: 23b 2ant: notify more bt information

[Larry Finger]

From: Yan-Hsuan Chuang 

These bt information are displayed in display coex

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c  | 20 
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.h  |  2 ++
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 15 +++
 3 files changed, 37 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 9092de2d2c7c..1c823a71ce9f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -4145,9 +4145,19 @@ void ex_btc8723b2ant_bt_info_notify(struct btc_coexist 
*btcoexist,
coex_sta->bt_retry_cnt =
coex_sta->bt_info_c2h[rsp_source][2] & 0xf;
 
+   if (coex_sta->bt_retry_cnt >= 1)
+   coex_sta->pop_event_cnt++;
+
coex_sta->bt_rssi =
coex_sta->bt_info_c2h[rsp_source][3] * 2 + 10;
 
+   coex_sta->bt_info_ext = coex_sta->bt_info_c2h[rsp_source][4];
+
+   if (coex_sta->bt_info_c2h[rsp_source][2] & 0x20)
+   coex_sta->c2h_bt_remote_name_req = true;
+   else
+   coex_sta->c2h_bt_remote_name_req = false;
+
if (coex_sta->bt_info_c2h[rsp_source][1] == 0x49)
coex_sta->a2dp_bit_pool =
coex_sta->bt_info_c2h[rsp_source][6];
@@ -4222,6 +4232,16 @@ void ex_btc8723b2ant_bt_info_notify(struct btc_coexist 
*btcoexist,
coex_sta->sco_exist = true;
else
coex_sta->sco_exist = false;
+
+   if ((!coex_sta->hid_exist) &&
+   (!coex_sta->c2h_bt_inquiry_page) &&
+   (!coex_sta->sco_exist)) {
+   if (coex_sta->high_priority_tx +
+   coex_sta->high_priority_rx >= 160) {
+   coex_sta->hid_exist = true;
+   bt_info = bt_info | 0x28;
+   }
+   }
}
 
btc8723b2ant_update_bt_link_info(btcoexist);
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h
index 9e29f85304cc..18a35c7faba9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h
@@ -151,12 +151,14 @@ struct coex_sta_8723b_2ant {
u32 low_priority_tx;
u32 low_priority_rx;
u8 bt_rssi;
+   bool bt_tx_rx_mask;
u8 pre_bt_rssi_state;
u8 pre_wifi_rssi_state[4];
bool c2h_bt_info_req_sent;
u8 bt_info_c2h[BT_INFO_SRC_8723B_2ANT_MAX][10];
u32 bt_info_c2h_cnt[BT_INFO_SRC_8723B_2ANT_MAX];
bool c2h_bt_inquiry_page;
+   bool c2h_bt_remote_name_req;
u8 bt_retry_cnt;
u8 bt_info_ext;
u32 pop_event_cnt;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index d31e6df5b1bf..c8271135 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -66,6 +66,15 @@
 #defineBTC_ANT_WIFI_AT_CPL_MAIN0
 #defineBTC_ANT_WIFI_AT_CPL_AUX 1
 
+enum btc_bt_reg_type {
+   BTC_BT_REG_RF   = 0,
+   BTC_BT_REG_MODEM= 1,
+   BTC_BT_REG_BLUEWIZE = 2,
+   BTC_BT_REG_VENDOR   = 3,
+   BTC_BT_REG_LE   = 4,
+   BTC_BT_REG_MAX
+};
+
 enum btc_chip_interface {
BTC_INTF_UNKNOWN= 0,
BTC_INTF_PCI= 1,
@@ -251,6 +260,7 @@ enum btc_set_type {
BTC_SET_BL_TO_REJ_AP_AGG_PKT,
BTC_SET_BL_BT_CTRL_AGG_SIZE,
BTC_SET_BL_INC_SCAN_DEV_NUM,
+   BTC_SET_BL_BT_TX_RX_MASK,
BTC_SET_BL_MIRACAST_PLUS_BT,
 
/* type u1Byte */
@@ -392,6 +402,9 @@ typedef bool (*bfp_btc_get)(void *btcoexist, u8 
get_type, void *out_buf);
 
 typedefbool (*bfp_btc_set)(void *btcoexist, u8 set_type, void *in_buf);
 
+typedef void (*bfp_btc_set_bt_reg)(void *btc_context, u8 reg_type, u32 offset,
+  u32 value);
+
 typedef void (*bfp_btc_disp_dbg_msg)(void *btcoexist, u8 disp_type);
 
 struct btc_bt_info {
@@ -511,6 +524,8 @@ struct btc_coexist {
 
bfp_btc_get btc_get;
bfp_btc_set btc_set;
+
+   

[PATCH 11/11] rtlwifi: btcoex: 23b 2ant: some hi-prio pkt will cause hid_exist

[Larry Finger]

From: Yan-Hsuan Chuang 

Clear the hid_exist flag by monitoring the packet counter.

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 1c823a71ce9f..2f3946be4ce2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -4329,6 +4329,7 @@ void ex_btc8723b2ant_pnp_notify(struct btc_coexist 
*btcoexist, u8 pnp_state)
 void ex_btc8723b2ant_periodical(struct btc_coexist *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct btc_bt_link_info *bt_link_info = >bt_link_info;
 
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
 "[BTCoex], 
==Periodical===\n");
@@ -4352,6 +4353,13 @@ void ex_btc8723b2ant_periodical(struct btc_coexist 
*btcoexist)
btc8723b2ant_monitor_bt_ctr(btcoexist);
btc8723b2ant_monitor_wifi_ctr(btcoexist);
 
+   /* for some BT speakers that High-Priority pkts appear before
+* playing, this will cause HID exist
+*/
+   if ((coex_sta->high_priority_tx + coex_sta->high_priority_rx < 50) &&
+   (bt_link_info->hid_exist))
+   bt_link_info->hid_exist = false;
+
if (btc8723b2ant_is_wifi_status_changed(btcoexist) ||
coex_dm->auto_tdma_adjust)
btc8723b2ant_run_coexist_mechanism(btcoexist);
-- 
2.12.0

[PATCH 07/11] rtlwifi: btcoex: 23b 2ant: before firmware ready settings

[Larry Finger]

From: Yan-Hsuan Chuang 

Before firmware is ready, set GNT_BT to high to let bt transmit

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 38 ++
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  2 ++
 2 files changed, 40 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 0f3d04529ff2..06f70944bdac 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -3700,6 +3700,44 @@ void ex_btc8723b2ant_power_on_setting(struct btc_coexist 
*btcoexist)
}
 }
 
+void ex_btc8723b2ant_pre_load_firmware(struct btc_coexist *btcoexist)
+{
+   struct btc_board_info *board_info = >board_info;
+   u8 u8tmp = 0x4; /* Set BIT2 by default since it's 2ant case */
+
+   /**
+* S0 or S1 setting and Local register setting(By this fw can get
+* ant number, S0/S1, ... info)
+*
+* Local setting bit define
+*  BIT0: "0" : no antenna inverse; "1" : antenna inverse
+*  BIT1: "0" : internal switch; "1" : external switch
+*  BIT2: "0" : one antenna; "1" : two antennas
+*
+* NOTE: here default all internal switch and 1-antenna ==> BIT1=0 and
+* BIT2 = 0
+*/
+   if (btcoexist->chip_interface == BTC_INTF_USB) {
+   /* fixed at S0 for USB interface */
+   u8tmp |= 0x1; /* antenna inverse */
+   btcoexist->btc_write_local_reg_1byte(btcoexist, 0xfe08, u8tmp);
+   } else {
+   /* for PCIE and SDIO interface, we check efuse 0xc3[6] */
+   if (board_info->single_ant_path == 0) {
+   } else if (board_info->single_ant_path == 1) {
+   /* set to S0 */
+   u8tmp |= 0x1; /* antenna inverse */
+   }
+
+   if (btcoexist->chip_interface == BTC_INTF_PCI)
+   btcoexist->btc_write_local_reg_1byte(btcoexist, 0x384,
+u8tmp);
+   else if (btcoexist->chip_interface == BTC_INTF_SDIO)
+   btcoexist->btc_write_local_reg_1byte(btcoexist, 0x60,
+u8tmp);
+   }
+}
+
 void ex_btc8723b2ant_init_coex_dm(struct btc_coexist *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 5a34cd895e44..d31e6df5b1bf 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -369,6 +369,7 @@ typedef void (*bfp_btc_w2)(void *btc_context, u32 reg_addr, 
u16 data);
 
 typedef void (*bfp_btc_w4)(void *btc_context, u32 reg_addr, u32 data);
 
+typedef void (*bfp_btc_local_reg_w1)(void *btc_context, u32 reg_addr, u8 data);
 typedef void (*bfp_btc_wr_1byte_bit_mask)(void *btc_context, u32 reg_addr,
  u8 bit_mask, u8 data);
 
@@ -496,6 +497,7 @@ struct btc_coexist {
bfp_btc_w2 btc_write_2byte;
bfp_btc_r4 btc_read_4byte;
bfp_btc_w4 btc_write_4byte;
+   bfp_btc_local_reg_w1 btc_write_local_reg_1byte;
 
bfp_btc_set_bb_reg btc_set_bb_reg;
bfp_btc_get_bb_reg btc_get_bb_reg;
-- 
2.12.0

[PATCH 08/11] rtlwifi: btcoex: 23b 2ant: fine tune for bt pan_edr_a2dp

[Larry Finger]

From: Yan-Hsuan Chuang 

If we don't limit the rx aggregation size, and set tdma instead, the bt profile 
can
get more stable.

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 06f70944bdac..a76c8d20e093 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -3140,7 +3140,6 @@ static void btc8723b2ant_action_pan_edr_a2dp(struct 
btc_coexist *btcoexist)
 
btcoexist->btc_set_rf_reg(btcoexist, BTC_RF_A, 0x1, 0xf, 0x0);
 
-   btc8723b2ant_limited_rx(btcoexist, NORMAL_EXEC, false, false, 0x8);
btc8723b2ant_fw_dac_swing_lvl(btcoexist, NORMAL_EXEC, 6);
 
if (BTC_RSSI_HIGH(bt_rssi_state))
@@ -3167,7 +3166,7 @@ static void btc8723b2ant_action_pan_edr_a2dp(struct 
btc_coexist *btcoexist)
  false, 3);
} else {
btc8723b2ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 7);
-   btc8723b2ant_tdma_duration_adjust(btcoexist, false, true, 3);
+   btc8723b2ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 3);
}
 
/* sw mechanism */
-- 
2.12.0

[PATCH 03/11] rtlwifi: btcoex: 23b 2ant: remove debugging code for 0x948

[Larry Finger]

From: Yan-Hsuan Chuang 

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 6 --
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h | 2 --
 2 files changed, 8 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 82a5e5357cb7..9c169d094b51 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -3486,12 +3486,6 @@ static void btc8723b2ant_run_coexist_mechanism(struct 
btc_coexist *btcoexist)
 "[BTCoex], BT is under inquiry/page scan !!\n");
btc8723b2ant_action_bt_inquiry(btcoexist);
return;
-   } else {
-   if (coex_dm->need_recover_0x948) {
-   coex_dm->need_recover_0x948 = false;
-   btcoexist->btc_write_2byte(btcoexist, 0x948,
-  coex_dm->backup_0x948);
-   }
}
 
btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_SCAN, );
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h
index 2c2113482481..9e29f85304cc 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.h
@@ -134,8 +134,6 @@ struct coex_dm_8723b_2ant {
 
bool is_switch_to_1dot5_ant;
u8 switch_thres_offset;
-   bool need_recover_0x948;
-   u16 backup_0x948;
 };
 
 struct coex_sta_8723b_2ant {
-- 
2.12.0

[PATCH 09/11] rtlwifi: btcoex: 23b 2ant: fine tune for bt hid_a2dp

[Larry Finger]

From: Yan-Hsuan Chuang 

Let bt control the aggregation size to improve stability.

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index a76c8d20e093..9092de2d2c7c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -3355,7 +3355,7 @@ static void btc8723b2ant_action_hid_a2dp(struct 
btc_coexist *btcoexist)
 
btcoexist->btc_set_rf_reg(btcoexist, BTC_RF_A, 0x1, 0xf, 0x0);
 
-   btc8723b2ant_limited_rx(btcoexist, NORMAL_EXEC, false, false, 0x8);
+   btc8723b2ant_limited_rx(btcoexist, NORMAL_EXEC, false, true, 0x5);
btc8723b2ant_fw_dac_swing_lvl(btcoexist, NORMAL_EXEC, 6);
 
btcoexist->btc_get(btcoexist, BTC_GET_U4_WIFI_BW, _bw);
-- 
2.12.0

[PATCH 00/11] rtlwifi: btcoex: More update to btcoex

[Larry Finger]

This set of patches completes the updates for btcoex for the RTL8723BE
device. These patches follow the 13-patch set previously submitted.

Signed-off-by: Larry Finger 
Cc: Yan-Hsuan Chuang 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 


Yan-Hsuan Chuang (11):
  btcoex: 23b 2ant: set coex table when wifi is idle
  btcoex: 23b 2ant: treat too many low prio packets as retry
  btcoex: 23b 2ant: remove debugging code for 0x948
  btcoex: 23b 2ant: need those information when scan
  btcoex: 23b 2ant: wifi is not actually off in mp mode
  btcoex: 23b 2ant: power on settings for coex
  btcoex: 23b 2ant: before firmware ready settings
  btcoex: 23b 2ant: fine tune for bt pan_edr_a2dp
  btcoex: 23b 2ant: fine tune for bt hid_a2dp
  rtlwifi: btcoex: 23b 2ant: notify more bt information
  rtlwifi: btcoex: 23b 2ant: some hi-prio pkt will cause hid_exist

 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 194 ++---
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.h|   4 +-
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  19 ++
 3 files changed, 189 insertions(+), 28 deletions(-)

-- 
2.12.0

[PATCH 02/11] rtlwifi: btcoex: 23b 2ant: treat too many low prio packets as retry

[Larry Finger]

From: Yan-Hsuan Chuang 

Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Larry Finger 
Cc: Pkshih 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 327609e3a309..82a5e5357cb7 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -1884,6 +1884,11 @@ static void btc8723b2ant_tdma_duration_adjust(struct 
btc_coexist *btcoexist,
} else {
/*accquire the BT TRx retry count from BT_Info byte2*/
retry_count = coex_sta->bt_retry_cnt;
+
+   if ((coex_sta->low_priority_tx) > 1050 ||
+   (coex_sta->low_priority_rx) > 1250)
+   retry_count++;
+
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
 "[BTCoex], retry_count = %d\n", retry_count);
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_LOUD,
-- 
2.12.0

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

[Matthias Kaehlcke]

Hi Johannes,

thanks for your comments

El Thu, Apr 06, 2017 at 09:11:18PM +0200 Johannes Berg ha dit:

> On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote:
> > Clang raises a warning about the expression 'strlen(CONFIG_XXX)'
> > being
> > used in a logical operation. Clangs' builtin strlen function resolves
> > the
> > expression to a constant at compile time, which causes clang to
> > generate
> > a 'constant-logical-operand' warning.
> > 
> > Split the if statement in two to avoid using the const expression in
> > a logical operation.
> > 
> I don't really see all much point in doing this for the warning's
> sake... hopefully it doesn't actually generate worse code, but I think
> the code ends up looking worse and people will forever wonder what the
> goto is really doing there.

I agree that the code looks worse :( I hoped to find a fix using a
preprocessor condition but wasn't successful.

Some projects (like Chrome OS) build their kernel with all warnings
being treated as errors. Besides changing the 'offending' code the
alternatives are to disable the warning completely or to tell clang
not to use the builtin(s). IMO changing the code is the preferable
solution, especially since this is so far the only occurrence of the
warning that I have encountered.

I used goto instead of nested ifs since other functions in this file
use the same pattern. If nested ifs are preferred I can change that.

Cheers

Matthias

Re: [PATCH] mac80211: Fix clang warning about constant operand in logical operation

[Johannes Berg]

On Thu, 2017-04-06 at 11:56 -0700, Matthias Kaehlcke wrote:
> Clang raises a warning about the expression 'strlen(CONFIG_XXX)'
> being
> used in a logical operation. Clangs' builtin strlen function resolves
> the
> expression to a constant at compile time, which causes clang to
> generate
> a 'constant-logical-operand' warning.
> 
> Split the if statement in two to avoid using the const expression in
> a logical operation.
> 
I don't really see all much point in doing this for the warning's
sake... hopefully it doesn't actually generate worse code, but I think
the code ends up looking worse and people will forever wonder what the
goto is really doing there.

johannes

[PATCH] mac80211: Fix clang warning about constant operand in logical operation

[Matthias Kaehlcke]

Clang raises a warning about the expression 'strlen(CONFIG_XXX)' being
used in a logical operation. Clangs' builtin strlen function resolves the
expression to a constant at compile time, which causes clang to generate
a 'constant-logical-operand' warning.

Split the if statement in two to avoid using the const expression in a
logical operation.

Signed-off-by: Matthias Kaehlcke 
---
 net/mac80211/rate.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 206698bc93f4..68ff202d6380 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -173,9 +173,14 @@ ieee80211_rate_control_ops_get(const char *name)
/* try default if specific alg requested but not found */
ops = 
ieee80211_try_rate_control_ops_get(ieee80211_default_rc_algo);
 
+   if (ops)
+   goto unlock;
+
/* try built-in one if specific alg requested but not found */
-   if (!ops && strlen(CONFIG_MAC80211_RC_DEFAULT))
+   if (strlen(CONFIG_MAC80211_RC_DEFAULT))
ops = 
ieee80211_try_rate_control_ops_get(CONFIG_MAC80211_RC_DEFAULT);
+
+unlock:
kernel_param_unlock(THIS_MODULE);
 
return ops;
-- 
2.12.2.715.g7642488e1d-goog

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

[Jes Sorensen]

On 04/06/2017 02:32 PM, Larry Finger wrote:

On 04/06/2017 04:49 AM, Hans de Goede wrote:

Hi,

On 06-04-17 11:04, Bastien Nocera wrote:

On Thu, 2017-04-06 at 08:55 +0200, Hans de Goede wrote:





Good thank you. So what is the plan with the github version ?

Note that my submission contains a few small fixes on top of
the github version, for which I intended to submit a pull-req
but I've not gotten around to that yet, I've done so now:

https://github.com/hadess/rtl8723bs/pull/125

But do we want to keep maintaining the github version (for a while
at least) I wonder, as that does mean double work?


My plan is to remove everything and point to the upstream tree as soon
as the support has landed in Linus' tree.

While there is some use in keeping it around for older kernels, we keep
getting asked to support even older kernels than reasonable, or have
users complaining about non-working machines once they use the driver,
which simply uncovers kernel bugs that were fixed upstream.

I don't think it's a good use of our time to carry on supporting this
out-of-tree. I'll however make sure to try and document the migration
in a way that's helpful to users.


Ok, that works for me.


I agree. I have enough to do.


You could simply break the build, and have it spit out a warning saying 
the git repo is kept there to track the old source.


It might be useful to have a repository of the original code to go look at.

Cheers,
Jes

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

[Larry Finger]

On 04/06/2017 04:49 AM, Hans de Goede wrote:

Hi,

On 06-04-17 11:04, Bastien Nocera wrote:

On Thu, 2017-04-06 at 08:55 +0200, Hans de Goede wrote:





Good thank you. So what is the plan with the github version ?

Note that my submission contains a few small fixes on top of
the github version, for which I intended to submit a pull-req
but I've not gotten around to that yet, I've done so now:

https://github.com/hadess/rtl8723bs/pull/125

But do we want to keep maintaining the github version (for a while
at least) I wonder, as that does mean double work?


My plan is to remove everything and point to the upstream tree as soon
as the support has landed in Linus' tree.

While there is some use in keeping it around for older kernels, we keep
getting asked to support even older kernels than reasonable, or have
users complaining about non-working machines once they use the driver,
which simply uncovers kernel bugs that were fixed upstream.

I don't think it's a good use of our time to carry on supporting this
out-of-tree. I'll however make sure to try and document the migration
in a way that's helpful to users.


Ok, that works for me.


I agree. I have enough to do.

Larry

Re: [PATCH] nfc: fix get_unaligned_...() misuses

[Al Viro]

On Thu, Apr 06, 2017 at 05:48:47PM +0100, Al Viro wrote:
> * use unaligned.h, not unaligned/access_ok.h

... which got misspelled in that patch, sorry...  Fixed variant follows:

commit b3e79ba1708c9b74781079c9f8617448fce36b51
Author: Al Viro 
Date:   Thu Apr 6 12:42:14 2017 -0400

nfc: fix get_unaligned_...() misuses

* use unaligned.h, not unaligned/access_ok.h
* if a local variable of type uint16_t is unaligned, your compiler is FUBAR
* the whole point of get_unaligned_... is to avoid memcpy + ..._to_cpu().
  Using it *after* memcpy() (into aligned object, no less) is pointless.

Signed-off-by: Al Viro 

diff --git a/drivers/nfc/nfcmrvl/fw_dnld.c b/drivers/nfc/nfcmrvl/fw_dnld.c
index f8dcdf4b24f6..ad1f0624ceee 100644
--- a/drivers/nfc/nfcmrvl/fw_dnld.c
+++ b/drivers/nfc/nfcmrvl/fw_dnld.c
@@ -17,11 +17,11 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include "nfcmrvl.h"
 
 #define FW_DNLD_TIMEOUT15000
@@ -281,12 +281,11 @@ static int process_state_fw_dnld(struct nfcmrvl_private 
*priv,
return -EINVAL;
}
skb_pull(skb, 1);
-   memcpy(, skb->data, 2);
+   len = get_unaligned_le16(skb->data);
skb_pull(skb, 2);
+   comp_len = get_unaligned_le16(skb->data);
memcpy(_len, skb->data, 2);
skb_pull(skb, 2);
-   len = get_unaligned_le16();
-   comp_len = get_unaligned_le16(_len);
if (((~len) & 0x) != comp_len) {
nfc_err(priv->dev, "bad len complement: %x %x %x",
len, comp_len, (~len & 0x));
diff --git a/drivers/nfc/nxp-nci/firmware.c b/drivers/nfc/nxp-nci/firmware.c
index 5291797324ba..553011f58339 100644
--- a/drivers/nfc/nxp-nci/firmware.c
+++ b/drivers/nfc/nxp-nci/firmware.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "nxp-nci.h"
 
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 36099e557730..9da35d2898fc 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -127,7 +126,7 @@ static int nxp_nci_i2c_fw_read(struct nxp_nci_i2c_phy *phy,
goto fw_read_exit;
}
 
-   frame_len = (get_unaligned_be16() & NXP_NCI_FW_FRAME_LEN_MASK) +
+   frame_len = (be16_to_cpu(header) & NXP_NCI_FW_FRAME_LEN_MASK) +
NXP_NCI_FW_CRC_LEN;
 
*skb = alloc_skb(NXP_NCI_FW_HDR_LEN + frame_len, GFP_KERNEL);

[PATCH] nfc: fix get_unaligned_...() misuses

[Al Viro]

* use unaligned.h, not unaligned/access_ok.h
* if a local variable of type uint16_t is unaligned, your compiler is FUBAR
* the whole point of get_unaligned_... is to avoid memcpy + ..._to_cpu().
  Using it *after* memcpy() (into aligned object, no less) is pointless.
  
Signed-off-by: Al Viro 

diff --git a/drivers/nfc/nfcmrvl/fw_dnld.c b/drivers/nfc/nfcmrvl/fw_dnld.c
index f8dcdf4b24f6..d3b04da0f16f 100644
--- a/drivers/nfc/nfcmrvl/fw_dnld.c
+++ b/drivers/nfc/nfcmrvl/fw_dnld.c
@@ -17,7 +17,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -281,12 +281,11 @@ static int process_state_fw_dnld(struct nfcmrvl_private 
*priv,
return -EINVAL;
}
skb_pull(skb, 1);
-   memcpy(, skb->data, 2);
+   len = get_unaligned_le16(skb->data);
skb_pull(skb, 2);
+   comp_len = get_unaligned_le16(skb->data);
memcpy(_len, skb->data, 2);
skb_pull(skb, 2);
-   len = get_unaligned_le16();
-   comp_len = get_unaligned_le16(_len);
if (((~len) & 0x) != comp_len) {
nfc_err(priv->dev, "bad len complement: %x %x %x",
len, comp_len, (~len & 0x));
diff --git a/drivers/nfc/nxp-nci/firmware.c b/drivers/nfc/nxp-nci/firmware.c
index 5291797324ba..f27b03e3b5ae 100644
--- a/drivers/nfc/nxp-nci/firmware.c
+++ b/drivers/nfc/nxp-nci/firmware.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "nxp-nci.h"
 
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 36099e557730..9da35d2898fc 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -127,7 +126,7 @@ static int nxp_nci_i2c_fw_read(struct nxp_nci_i2c_phy *phy,
goto fw_read_exit;
}
 
-   frame_len = (get_unaligned_be16() & NXP_NCI_FW_FRAME_LEN_MASK) +
+   frame_len = (be16_to_cpu(header) & NXP_NCI_FW_FRAME_LEN_MASK) +
NXP_NCI_FW_CRC_LEN;
 
*skb = alloc_skb(NXP_NCI_FW_HDR_LEN + frame_len, GFP_KERNEL);

Re: [PATCH] mwifiex: MAC randomization should not be persistent

[Brian Norris]

On Thu, Apr 06, 2017 at 07:02:15AM +0300, Kalle Valo wrote:
> Brian Norris  writes:
> 
> > nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan
> > request that should be randomized; the absence of such a flag means we
> > should not randomize. However, mwifiex was stashing the latest
> > randomization request and *always* using it for future scans, even those
> > that didn't set the flag.
> >
> > Let's zero out the randomization info whenever we get a scan request
> > without NL80211_SCAN_FLAG_RANDOM_ADDR. I'd prefer to remove
> > priv->random_mac entirely (and plumb the randomization MAC properly
> > through the call sequence), but the spaghetti is a little difficult to
> > unravel here for me.
> >
> > Fixes: c2a8f0ff9c6c ("mwifiex: support random MAC address for scanning")
> 
> So the first release with this was v4.9.
> 
> > Signed-off-by: Brian Norris 
> > ---
> > Should this be tagged for -stable?
> 
> IMHO yes.

Sounds fine to me. I suppose you'll do this when applying? Or I can
resend...

Brian

Re: [Make-wifi-fast] [PATCH v3] mac80211: Dynamically set CoDel parameters per station

[Toke Høiland-Jørgensen]

Eric Dumazet  writes:

> On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote:
>
>> +
>> +if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
>> +sta->cparams.target = MS2TIME(50);
>> +sta->cparams.interval = MS2TIME(300);
>> +sta->cparams.ecn = false;
>> +} else {
>> +sta->cparams.target = MS2TIME(20);
>> +sta->cparams.interval = MS2TIME(100);
>> +sta->cparams.ecn = true;
>> +}
>> +}
>
> Why ECN is flipped on/off like that ?

The reasoning is that at really low bandwidths we're better off dropping
the packet and getting potentially latency-sensitive data queued behind
it through (see Dave's various rants with the topic "Packets have
mass").

> ECN really should be an admin choice.

Well, the trouble is that the mac80211 queues don't really have an admin
interface currently. So it'll always use ECN (before this change).

> Also, this change in parameters looks suspect to me, adding a bimodal
> behavior. I would consult Kathleen and Van on this possibility.

Yeah, I agree that it's somewhat of a hack from a theoretical point of
view. I've also been experimenting with Kathy's recommended way of
dealing with bursty MACs (turning off CoDel when there's less than an
MTU's worth of data left), but have not had a lot of success with it.
Guess I can go back and try some variants on that, unless someone else
has better ideas?

-Toke

Re: How to use netlink to determine wifi protection WEP

[Dan Williams]

On Thu, 2017-04-06 at 16:27 +0200, Thomas Thielemann wrote:
> Thanks!
> 
> If the sequence is the following:
> 
>  1. Prepare and execute NL80211_CMD_TRIGGER_SCAN
>  2. Prepare and execute NL80211_CMD_GET_SCAN
>  Together with NL80211_CMD_GET_SCAN a callback is registered. 
>  In the callback the raw data are parsed as BSS. The IE's are parsed
> to.
> 
> When do I have to fetch the beacon to get the right beacon but
> without lost of the scan result?
> After I fetched all scan results or immediately after the receive of
> every scan result?

The scan results are essentially the beacons, so you just need to read
the GET_SCAN.  Then when parsing the "bss info" you get from the scan
results handler that you registered, you look for:

NL80211_BSS_CAPABILITY: the Privacy bit is in here
NL80211_BSS_INFORMATION_ELEMENTS: the IEs are obviously in here

Dan

> Regards,
> Thomas
> 
> 
> > Am 05.04.2017 um 19:24 schrieb Dan Williams :
> > 
> > On Wed, 2017-04-05 at 09:27 +0200, Thomas Thielemann wrote:
> > > Hello!
> > > 
> > > I need a solution to determine whether a WiFi is using WEP. I
> > > know
> > > there is a protection flag within MAC frame but do not know how
> > > to
> > > access.
> > > 
> > > To detect whether a WiFi i protected by WPA2 I found the
> > > following
> > > solution: 
> > > 
> > > Scan with
> > > 
> > > nl_sock* socket = nl_socket_alloc();
> > > genl_connect(socket);
> > > struct nl_msg* msg = nlmsg_alloc();
> > > int driverId = genl_ctrl_resolve(socket, "nl80211"); 
> > > genlmsg_put(msg, 0, 0, driverId, 0, 0, NL80211_CMD_TRIGGER_SCAN,
> > > 0);
> > > 
> > > and fetch with
> > > 
> > > genlmsg_put(msg, 0, 0, driverId, 0, NLM_F_DUMP,
> > > NL80211_CMD_GET_SCAN,
> > > 0);
> > > 
> > > Read the received structure using nl80211_bss::
> > > NL80211_BSS_INFORMATION_ELEMENTS from nl80211.h and
> > > 
> > > examine the field RSN(id=48) (see IEEE802.11-2012.pdf, chapter
> > > 8.4.2
> > > Information elements)
> > > 
> > > Which netlink command gives me the related data? Is it
> > > NL80211_CMD_GET_BEACON?
> > 
> > You want both the beacon (for the Privacy bit) and the information
> > elements.
> > 
> > If the privacy bit is set in beacon and there are no WPA/WPA2/RSN-
> > related information elements, then the AP is using
> > WEP.  Unfortunately
> > you don't know whether it's WEP-40 or WEP-104, but that's another
> > topic.
> > 
> > If the privacy bit is set, and there are WPA/WPA2/RSN information
> > elements, then the AP *might* be using WEP in compatibility
> > mode.  This
> > isn't very common though, so you can probably just ignore this
> > case.
> > 
> > Dan
> > 
> 
> 

Re: How to use netlink to determine wifi protection WEP

[Thomas Thielemann]

Thanks!

If the sequence is the following:

 1. Prepare and execute NL80211_CMD_TRIGGER_SCAN
 2. Prepare and execute NL80211_CMD_GET_SCAN
 Together with NL80211_CMD_GET_SCAN a callback is registered. 
 In the callback the raw data are parsed as BSS. The IE's are parsed to.

When do I have to fetch the beacon to get the right beacon but without lost of 
the scan result?
After I fetched all scan results or immediately after the receive of every scan 
result?

Regards,
Thomas


> Am 05.04.2017 um 19:24 schrieb Dan Williams :
> 
> On Wed, 2017-04-05 at 09:27 +0200, Thomas Thielemann wrote:
>> Hello!
>> 
>> I need a solution to determine whether a WiFi is using WEP. I know
>> there is a protection flag within MAC frame but do not know how to
>> access.
>> 
>> To detect whether a WiFi i protected by WPA2 I found the following
>> solution: 
>> 
>> Scan with
>> 
>> nl_sock* socket = nl_socket_alloc();
>> genl_connect(socket);
>> struct nl_msg* msg = nlmsg_alloc();
>> int driverId = genl_ctrl_resolve(socket, "nl80211"); 
>> genlmsg_put(msg, 0, 0, driverId, 0, 0, NL80211_CMD_TRIGGER_SCAN, 0);
>> 
>> and fetch with
>> 
>> genlmsg_put(msg, 0, 0, driverId, 0, NLM_F_DUMP, NL80211_CMD_GET_SCAN,
>> 0);
>> 
>> Read the received structure using nl80211_bss::
>> NL80211_BSS_INFORMATION_ELEMENTS from nl80211.h and
>> 
>> examine the field RSN(id=48) (see IEEE802.11-2012.pdf, chapter 8.4.2
>> Information elements)
>> 
>> Which netlink command gives me the related data? Is it
>> NL80211_CMD_GET_BEACON?
> 
> You want both the beacon (for the Privacy bit) and the information
> elements.
> 
> If the privacy bit is set in beacon and there are no WPA/WPA2/RSN-
> related information elements, then the AP is using WEP.  Unfortunately
> you don't know whether it's WEP-40 or WEP-104, but that's another
> topic.
> 
> If the privacy bit is set, and there are WPA/WPA2/RSN information
> elements, then the AP *might* be using WEP in compatibility mode.  This
> isn't very common though, so you can probably just ignore this case.
> 
> Dan
> 

[PATCH 3/6] brcmfmac: remove reference to fwsignal data from struct brcmf_pub

[Arend van Spriel]

The fwsignal module is part of the bcdc protocol and as such does
its instance data is not needed in core structure. Moving it into
struct brcmf_bcdc instead.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcdc.c| 35 +++
 .../wireless/broadcom/brcm80211/brcmfmac/bcdc.h|  1 +
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  2 -
 .../broadcom/brcm80211/brcmfmac/fwsignal.c | 51 ++
 .../broadcom/brcm80211/brcmfmac/fwsignal.h |  4 +-
 5 files changed, 54 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 9628084..9f2d0b0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -103,9 +103,17 @@ struct brcmf_bcdc {
u8 bus_header[BUS_HEADER_LEN];
struct brcmf_proto_bcdc_dcmd msg;
unsigned char buf[BRCMF_DCMD_MAXLEN];
+   struct brcmf_fws_info *fws;
 };
 
 
+struct brcmf_fws_info *drvr_to_fws(struct brcmf_pub *drvr)
+{
+   struct brcmf_bcdc *bcdc = drvr->proto->pd;
+
+   return bcdc->fws;
+}
+
 static int
 brcmf_proto_bcdc_msg(struct brcmf_pub *drvr, int ifidx, uint cmd, void *buf,
 uint len, bool set)
@@ -330,8 +338,9 @@ static int brcmf_proto_bcdc_tx_queue_data(struct brcmf_pub 
*drvr, int ifidx,
  struct sk_buff *skb)
 {
struct brcmf_if *ifp = brcmf_get_ifp(drvr, ifidx);
+   struct brcmf_bcdc *bcdc = drvr->proto->pd;
 
-   if (!brcmf_fws_queue_skbs(drvr->fws))
+   if (!brcmf_fws_queue_skbs(bcdc->fws))
return brcmf_proto_txdata(drvr, ifidx, 0, skb);
 
return brcmf_fws_process_skb(ifp, skb);
@@ -360,15 +369,15 @@ void brcmf_proto_bcdc_txflowblock(struct device *dev, 
bool state)
bool success)
 {
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
-   struct brcmf_pub *drvr = bus_if->drvr;
+   struct brcmf_bcdc *bcdc = bus_if->drvr->proto->pd;
struct brcmf_if *ifp;
 
/* await txstatus signal for firmware if active */
-   if (brcmf_fws_fc_active(drvr->fws)) {
+   if (brcmf_fws_fc_active(bcdc->fws)) {
if (!success)
-   brcmf_fws_bustxfail(drvr->fws, txp);
+   brcmf_fws_bustxfail(bcdc->fws, txp);
} else {
-   if (brcmf_proto_bcdc_hdrpull(drvr, false, txp, ))
+   if (brcmf_proto_bcdc_hdrpull(bus_if->drvr, false, txp, ))
brcmu_pkt_buf_free_skb(txp);
else
brcmf_txfinalize(ifp, txp, success);
@@ -420,7 +429,15 @@ static void brcmf_proto_bcdc_rxreorder(struct brcmf_if 
*ifp,
 static int
 brcmf_proto_bcdc_init_done(struct brcmf_pub *drvr)
 {
-   return brcmf_fws_attach(drvr);
+   struct brcmf_bcdc *bcdc = drvr->proto->pd;
+   struct brcmf_fws_info *fws;
+
+   fws = brcmf_fws_attach(drvr);
+   if (IS_ERR(fws))
+   return PTR_ERR(fws);
+
+   bcdc->fws = fws;
+   return 0;
 }
 
 int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
@@ -464,7 +481,9 @@ int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
 
 void brcmf_proto_bcdc_detach(struct brcmf_pub *drvr)
 {
-   brcmf_fws_detach(drvr);
-   kfree(drvr->proto->pd);
+   struct brcmf_bcdc *bcdc = drvr->proto->pd;
+
drvr->proto->pd = NULL;
+   brcmf_fws_detach(bcdc->fws);
+   kfree(bcdc);
 }
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h
index b6fa7a8..3b0e9ef 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h
@@ -22,6 +22,7 @@
 void brcmf_proto_bcdc_txflowblock(struct device *dev, bool state);
 void brcmf_proto_bcdc_txcomplete(struct device *dev, struct sk_buff *txp,
 bool success);
+struct brcmf_fws_info *drvr_to_fws(struct brcmf_pub *drvr);
 #else
 static inline int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr) { return 0; }
 static inline void brcmf_proto_bcdc_detach(struct brcmf_pub *drvr) {}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index 6aecd8d..a4dd313 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -127,8 +127,6 @@ struct brcmf_pub {
 
struct brcmf_fweh_info fweh;
 
-   struct brcmf_fws_info *fws;
-
struct brcmf_ampdu_rx_reorder

[PATCH 5/6] brcmfmac: remove bogus check in scheduled scan result handler

[Arend van Spriel]

Checking whether the address of an array element is null is bogus
so removing it.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 760781f..b687533 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3344,12 +3344,6 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
 
for (i = 0; i < result_count; i++) {
netinfo = _start[i];
-   if (!netinfo) {
-   brcmf_err("Invalid netinfo ptr. index: %d\n",
- i);
-   err = -EINVAL;
-   goto out_err;
-   }
 
if (netinfo->SSID_len > IEEE80211_MAX_SSID_LEN)
netinfo->SSID_len = IEEE80211_MAX_SSID_LEN;
-- 
1.9.1

[PATCH 2/6] brcmfmac: ignore interfaces when fwsignal is disabled

[Arend van Spriel]

When brcmf_fws_add_interface() is called the struct brcmf_if::fws_desc
field is initialized regardless the state of the fwsignal functionality,
ie. the fcmode. This is not needed when fcmode is NONE, which is the
default mode.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index c27a225..23b2b3f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2145,7 +2145,7 @@ void brcmf_fws_add_interface(struct brcmf_if *ifp)
struct brcmf_fws_info *fws = ifp->drvr->fws;
struct brcmf_fws_mac_descriptor *entry;
 
-   if (!ifp->ndev)
+   if (!ifp->ndev || fws->fcmode == BRCMF_FWS_FCMODE_NONE)
return;
 
entry = >desc.iface[ifp->ifidx];
-- 
1.9.1

[PATCH 0/6] brcmfmac: fwsignal and scheduled scan rework

[Arend van Spriel]

This series is intended for 4.12 including:
 * rework for fwsignal module.
 * tighten length checks for scheduled scan result event.
 * fix duplicate entries in scan request for scheduled scan.

The patches apply to the master branch of the wireless-drivers-next
repository.

Arend van Spriel (6):
  brcmfmac: rename brcmf_fws_{de,}init to brcmf_fws{at,de}tach
  brcmfmac: ignore interfaces when fwsignal is disabled
  brcmfmac: remove reference to fwsignal data from struct brcmf_pub
  brcmfmac: add length checks in scheduled scan result handler
  brcmfmac: remove bogus check in scheduled scan result handler
  brcmfmac: only add channels and ssids once in scan request

 .../wireless/broadcom/brcm80211/brcmfmac/bcdc.c| 35 ++
 .../wireless/broadcom/brcm80211/brcmfmac/bcdc.h|  1 +
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 39 +++-
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  2 -
 .../broadcom/brcm80211/brcmfmac/fwsignal.c | 53 ++
 .../broadcom/brcm80211/brcmfmac/fwsignal.h |  4 +-
 6 files changed, 82 insertions(+), 52 deletions(-)

-- 
1.9.1

[PATCH 1/6] brcmfmac: rename brcmf_fws_{de,}init to brcmf_fws{at,de}tach

[Arend van Spriel]

This is a non-functional change to align the fwsignal module to
the naming pattern used throughout the driver.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 4 ++--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 6 +++---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 24da627..9628084 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -420,7 +420,7 @@ static void brcmf_proto_bcdc_rxreorder(struct brcmf_if *ifp,
 static int
 brcmf_proto_bcdc_init_done(struct brcmf_pub *drvr)
 {
-   return brcmf_fws_init(drvr);
+   return brcmf_fws_attach(drvr);
 }
 
 int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
@@ -464,7 +464,7 @@ int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
 
 void brcmf_proto_bcdc_detach(struct brcmf_pub *drvr)
 {
-   brcmf_fws_deinit(drvr);
+   brcmf_fws_detach(drvr);
kfree(drvr->proto->pd);
drvr->proto->pd = NULL;
 }
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index 5f1a592..c27a225 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2308,7 +2308,7 @@ static int brcmf_debugfs_fws_stats_read(struct seq_file 
*seq, void *data)
 }
 #endif
 
-int brcmf_fws_init(struct brcmf_pub *drvr)
+int brcmf_fws_attach(struct brcmf_pub *drvr)
 {
struct brcmf_fws_info *fws;
struct brcmf_if *ifp;
@@ -2408,11 +2408,11 @@ int brcmf_fws_init(struct brcmf_pub *drvr)
return 0;
 
 fail:
-   brcmf_fws_deinit(drvr);
+   brcmf_fws_detach(drvr);
return rc;
 }
 
-void brcmf_fws_deinit(struct brcmf_pub *drvr)
+void brcmf_fws_detach(struct brcmf_pub *drvr)
 {
struct brcmf_fws_info *fws = drvr->fws;
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
index 96df660..d725158 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
@@ -18,8 +18,8 @@
 #ifndef FWSIGNAL_H_
 #define FWSIGNAL_H_
 
-int brcmf_fws_init(struct brcmf_pub *drvr);
-void brcmf_fws_deinit(struct brcmf_pub *drvr);
+int brcmf_fws_attach(struct brcmf_pub *drvr);
+void brcmf_fws_detach(struct brcmf_pub *drvr);
 bool brcmf_fws_queue_skbs(struct brcmf_fws_info *fws);
 bool brcmf_fws_fc_active(struct brcmf_fws_info *fws);
 void brcmf_fws_hdrpull(struct brcmf_if *ifp, s16 siglen, struct sk_buff *skb);
-- 
1.9.1

[PATCH 4/6] brcmfmac: add length checks in scheduled scan result handler

[Arend van Spriel]

Assure the event data buffer is long enough to hold the array
of netinfo items and that SSID length does not exceed the maximum
of 32 characters as per 802.11 spec.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 89ac124..760781f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3300,6 +3300,7 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
struct brcmf_pno_scanresults_le *pfn_result;
u32 result_count;
u32 status;
+   u32 datalen;
 
brcmf_dbg(SCAN, "Enter\n");
 
@@ -3326,6 +3327,14 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
brcmf_err("FALSE PNO Event. (pfn_count == 0)\n");
goto out_err;
}
+
+   netinfo_start = brcmf_get_netinfo_array(pfn_result);
+   datalen = e->datalen - ((void *)netinfo_start - (void *)pfn_result);
+   if (datalen < result_count * sizeof(*netinfo)) {
+   brcmf_err("insufficient event data\n");
+   goto out_err;
+   }
+
request = brcmf_alloc_internal_escan_request(wiphy,
 result_count);
if (!request) {
@@ -,8 +3342,6 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
goto out_err;
}
 
-   netinfo_start = brcmf_get_netinfo_array(pfn_result);
-
for (i = 0; i < result_count; i++) {
netinfo = _start[i];
if (!netinfo) {
@@ -3344,6 +3351,8 @@ static int brcmf_start_internal_escan(struct brcmf_if 
*ifp,
goto out_err;
}
 
+   if (netinfo->SSID_len > IEEE80211_MAX_SSID_LEN)
+   netinfo->SSID_len = IEEE80211_MAX_SSID_LEN;
brcmf_dbg(SCAN, "SSID:%.32s Channel:%d\n",
  netinfo->SSID, netinfo->channel);
err = brcmf_internal_escan_add_info(request,
-- 
1.9.1

[PATCH 6/6] brcmfmac: only add channels and ssids once in scan request

[Arend van Spriel]

When receiving pno results there may be duplicate channels and/or
ssids. Assure each is added only once when preparing the internal
escan request.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/cfg80211.c  | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b687533..0a067e5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3216,7 +3216,7 @@ static int brcmf_internal_escan_add_info(struct 
cfg80211_scan_request *req,
 {
struct ieee80211_channel *chan;
enum nl80211_band band;
-   int freq;
+   int freq, i;
 
if (channel <= CH_MAX_2G_CHANNEL)
band = NL80211_BAND_2GHZ;
@@ -3231,10 +3231,22 @@ static int brcmf_internal_escan_add_info(struct 
cfg80211_scan_request *req,
if (!chan)
return -EINVAL;
 
-   req->channels[req->n_channels++] = chan;
-   memcpy(req->ssids[req->n_ssids].ssid, ssid, ssid_len);
-   req->ssids[req->n_ssids++].ssid_len = ssid_len;
+   for (i = 0; i < req->n_channels; i++) {
+   if (req->channels[i] == chan)
+   break;
+   }
+   if (i == req->n_channels)
+   req->channels[req->n_channels++] = chan;
 
+   for (i = 0; i < req->n_ssids; i++) {
+   if (req->ssids[i].ssid_len == ssid_len &&
+   !memcmp(req->ssids[i].ssid, ssid, ssid_len))
+   break;
+   }
+   if (i == req->n_ssids) {
+   memcpy(req->ssids[req->n_ssids].ssid, ssid, ssid_len);
+   req->ssids[req->n_ssids++].ssid_len = ssid_len;
+   }
return 0;
 }
 
-- 
1.9.1

Re: brcmfmac: don't warn user if requested nvram fails

[Hans de Goede]

Hi,

I noticed your patch-series on the lwn.net kernel page,
and I took a peek :)

I don't think that this patch:

https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170329-driver-data-v2-try3=3968dd3031d1ff7e7be4acfb810948c70c2d4490

Is a good idea, specifically the "do not warn" part,
although the brcmfmac driver will indeed try to continue
without a nvram file, in my experience it almost all
the time will not work properly without the nvram file.

Arend, should we maybe just make the missing nvram file
a fatal error ?

###

While on the subject of nvram file loading, I want to make
some changes to how brcmfmac does this, for pcie
devices I want it to first try:

brcmfmac-4xxx-sdio--.txt
and only if that is not present fallback to
brcmfmac-4xxx-sdio.txt, so that we can include the
brcmfmac-4xxx-sdio--.txt
in the linux-firmware repo and have things just work.

Likewise for sdio devices on devicetree platforms
first try brcmfmac-4xxx-sdio-.txt.

And for sdio devices on ACPI/x86 systems I want to
do something similar too.

Luis, do you think it would be a good idea to add
.optional_postfix member to driver_data_req_params
for this? I believe other sdio based wifi devices
may want to do the same, or should this be handled
in the driver by doing 2 driver_data_request_async
calls (the 2nd when the 1st fails) ?

Regards,

Hans

[PATCH] ath9k: Add Dell Wireless 1601 with wowlan capability

[Damien Thébault]

Add the Dell Wireless 1601 card as an AR9462 in the ath9k pci list.
Note that the wowlan feature is supported and has been tested
successfully.

Signed-off-by: Damien Thébault 
---
 drivers/net/wireless/ath/ath9k/pci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/pci.c 
b/drivers/net/wireless/ath/ath9k/pci.c
index aff473dfa10d..7b7627f85d3a 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -383,6 +383,11 @@ static const struct pci_device_id ath_pci_id_table[] = {
 0x10CF, /* Fujitsu */
 0x1783),
  .driver_data = ATH9K_PCI_WOW },
+   { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+0x0034,
+PCI_VENDOR_ID_DELL,
+0x020B),
+ .driver_data = ATH9K_PCI_WOW },
 
/* Killer Wireless (2x2) */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
-- 
2.12.2

Re: [Make-wifi-fast] [PATCH v3] mac80211: Dynamically set CoDel parameters per station

[Eric Dumazet]

On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote:

> +
> + if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
> + sta->cparams.target = MS2TIME(50);
> + sta->cparams.interval = MS2TIME(300);
> + sta->cparams.ecn = false;
> + } else {
> + sta->cparams.target = MS2TIME(20);
> + sta->cparams.interval = MS2TIME(100);
> + sta->cparams.ecn = true;
> + }
> +}

Why ECN is flipped on/off like that ? ECN really should be an admin
choice.

Also, this change in parameters looks suspect to me, adding a bimodal
behavior. I would consult Kathleen and Van on this possibility.

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

[Hans de Goede]

Hi,

On 06-04-17 11:04, Bastien Nocera wrote:

On Thu, 2017-04-06 at 08:55 +0200, Hans de Goede wrote:





Good thank you. So what is the plan with the github version ?

Note that my submission contains a few small fixes on top of
the github version, for which I intended to submit a pull-req
but I've not gotten around to that yet, I've done so now:

https://github.com/hadess/rtl8723bs/pull/125

But do we want to keep maintaining the github version (for a while
at least) I wonder, as that does mean double work?


My plan is to remove everything and point to the upstream tree as soon
as the support has landed in Linus' tree.

While there is some use in keeping it around for older kernels, we keep
getting asked to support even older kernels than reasonable, or have
users complaining about non-working machines once they use the driver,
which simply uncovers kernel bugs that were fixed upstream.

I don't think it's a good use of our time to carry on supporting this
out-of-tree. I'll however make sure to try and document the migration
in a way that's helpful to users.


Ok, that works for me.

Regards,

Hans

[PATCH v3] mac80211: Dynamically set CoDel parameters per station

[Toke Høiland-Jørgensen]

CoDel can be too aggressive if a station sends at a very low rate,
leading reduced throughput. This gets worse the more stations are
present, as each station gets more bursty the longer the round-robin
scheduling between stations takes.

This adds dynamic adjustment of CoDel parameters per station. It uses
the rate selection information to estimate throughput and sets more
lenient CoDel parameters if the estimated throughput is below a
threshold (modified by the number of active stations).

A new callback is added that drivers can use to notify mac80211 about
changes in expected throughput, so the same adjustment can be made for
cards that implement rate control in firmware. Drivers that don't use
this will just get the default parameters.

Signed-off-by: Toke Høiland-Jørgensen 
---
Changes since v2:
 - Messed up the rebase and squash in v2; this one actually compiles...
 
 include/net/mac80211.h | 17 +
 net/mac80211/debugfs_sta.c |  6 ++
 net/mac80211/rate.c|  3 ++-
 net/mac80211/sta_info.c| 31 +++
 net/mac80211/sta_info.h| 11 +++
 net/mac80211/tx.c  |  9 -
 6 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a3bab3c5ecfb..8cd546cbcabc 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4181,6 +4181,23 @@ void ieee80211_get_tx_rates(struct ieee80211_vif *vif,
int max_rates);
 
 /**
+ * ieee80211_sta_set_expected_throughput - set the expected throughput for a
+ * station
+ *
+ * Call this function to notify mac80211 about a change in expected throughput
+ * to a station. A driver for a device that does rate control in firmware can
+ * call this function when the expected throughput estimate towards a station
+ * changes. The information is used to tune the CoDel AQM applied to traffic
+ * going towards that station (which can otherwise be too aggressive and cause
+ * slow stations to starve).
+ *
+ * @pubsta: the station to set throughput for.
+ * @thr: the current expected throughput in kbps.
+ */
+void ieee80211_sta_set_expected_throughput(struct ieee80211_sta *pubsta,
+  u32 thr);
+
+/**
  * ieee80211_tx_status - transmit status callback
  *
  * Call this function for all transmitted frames after they have been
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 42601820db20..b15412c21ac9 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -154,6 +154,12 @@ static ssize_t sta_aqm_read(struct file *file, char __user 
*userbuf,
 
p += scnprintf(p,
   bufsz+buf-p,
+  "target %uus interval %uus ecn %s\n",
+  codel_time_to_us(sta->cparams.target),
+  codel_time_to_us(sta->cparams.interval),
+  sta->cparams.ecn ? "yes" : "no");
+   p += scnprintf(p,
+  bufsz+buf-p,
   "tid ac backlog-bytes backlog-packets new-flows drops 
marks overlimit collisions tx-bytes tx-packets\n");
 
for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 206698bc93f4..233c23ba2b98 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -890,6 +890,8 @@ int rate_control_set_rates(struct ieee80211_hw *hw,
 
drv_sta_rate_tbl_update(hw_to_local(hw), sta->sdata, pubsta);
 
+   ieee80211_sta_set_expected_throughput(pubsta, 
sta_get_expected_throughput(sta));
+
return 0;
 }
 EXPORT_SYMBOL(rate_control_set_rates);
@@ -938,4 +940,3 @@ void rate_control_deinitialize(struct ieee80211_local 
*local)
local->rate_ctrl = NULL;
rate_control_free(ref);
 }
-
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 3323a2fb289b..d5d54e84620f 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include "ieee80211_i.h"
 #include "driver-ops.h"
@@ -420,6 +421,11 @@ struct sta_info *sta_info_alloc(struct 
ieee80211_sub_if_data *sdata,
 
sta->sta.max_rc_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_BA;
 
+   sta->cparams.ce_threshold = CODEL_DISABLED_THRESHOLD;
+   sta->cparams.target = MS2TIME(20);
+   sta->cparams.interval = MS2TIME(100);
+   sta->cparams.ecn = true;
+
sta_dbg(sdata, "Allocated STA %pM\n", sta->sta.addr);
 
return sta;
@@ -2298,3 +2304,28 @@ unsigned long ieee80211_sta_last_active(struct sta_info 
*sta)
return stats->last_rx;
return sta->status_stats.last_ack;
 }
+
+static inline void sta_update_codel_params(struct sta_info *sta, u32 thr)
+{
+   if (!sta->sdata->local->ops->wake_tx_queue)
+   return;
+
+   if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
+   sta->cparams.target = MS2TIME(50);
+ 

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

[Bastien Nocera]

On Thu, 2017-04-06 at 08:55 +0200, Hans de Goede wrote:
> 

> Good thank you. So what is the plan with the github version ?
> 
> Note that my submission contains a few small fixes on top of
> the github version, for which I intended to submit a pull-req
> but I've not gotten around to that yet, I've done so now:
> 
> https://github.com/hadess/rtl8723bs/pull/125
> 
> But do we want to keep maintaining the github version (for a while
> at least) I wonder, as that does mean double work?

My plan is to remove everything and point to the upstream tree as soon
as the support has landed in Linus' tree.

While there is some use in keeping it around for older kernels, we keep
getting asked to support even older kernels than reasonable, or have
users complaining about non-working machines once they use the driver,
which simply uncovers kernel bugs that were fixed upstream.

I don't think it's a good use of our time to carry on supporting this
out-of-tree. I'll however make sure to try and document the migration
in a way that's helpful to users.

Cheers

Re: [PATCH v2] mac80211: Dynamically set CoDel parameters per station

[kbuild test robot]

Hi Toke,

[auto build test WARNING on mac80211/master]
[also build test WARNING on v4.11-rc5 next-20170406]
[cannot apply to mac80211-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/mac80211-Dynamically-set-CoDel-parameters-per-station/20170406-152423
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
master
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4198: warning: No description found for parameter 
>> 'pubsta'
>> include/net/mac80211.h:4198: warning: Excess function parameter 'sta' 
>> description in 'ieee80211_sta_set_expected_throughput'

vim +/pubsta +4198 include/net/mac80211.h

  4182  
  4183  /**
  4184   * ieee80211_sta_set_expected_throughput - set the expected throughput 
for a
  4185   * station
  4186   *
  4187   * Call this function to notify mac80211 about a change in expected 
throughput
  4188   * to a station. A driver for a device that does rate control in 
firmware can
  4189   * call this function when the expected throughput estimate towards a 
station
  4190   * changes. The information is used to tune the CoDel AQM applied to 
traffic
  4191   * going towards that station (which can otherwise be too aggressive 
and cause
  4192   * slow stations to starve).
  4193   *
  4194   * @sta: the station to set throughput for.
  4195   * @thr: the current expected throughput in kbps.
  4196   */
  4197  void ieee80211_sta_set_expected_throughput(struct ieee80211_sta *pubsta,
> 4198 u32 thr);
  4199  
  4200  /**
  4201   * ieee80211_tx_status - transmit status callback
  4202   *
  4203   * Call this function for all transmitted frames after they have been
  4204   * transmitted. It is permissible to not call this function for
  4205   * multicast frames but this can affect statistics.
  4206   *

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

RE:] Re: [3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name

[Xinming Hu]

Hi Kalle,

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: 2017年4月5日 18:47
> To: Xinming Hu
> Cc: Linux Wireless; Kalle Valo; Brian Norris; Dmitry Torokhov;
> raja...@google.com; Amitkumar Karwar; Cathy Luo; Xinming Hu
> Subject: [EXT] Re: [3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name
> 
> External Email
> 
> --
> Xinming Hu  wrote:
> > From: Xinming Hu 
> >
> > Wifi-only firmware name should be chipset specific.
> >
> > Signed-off-by: Xinming Hu 
> > Signed-off-by: Amitkumar Karwar 
> 
> The commit log is not telling anything. Why are you changing this? And how
> does the functionality change from user space point of view?
> 

Thanks for the review, we have implemented a new way to extract wifi-only part 
from combo firmware, will add more description in v2

Thanks,
Simon
> --
> https://patchwork.kernel.org/patch/9653387/
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpat
> ches

RE: [EXT] Re: [PATCH 3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name

[Xinming Hu]

Hi Brain,

> -Original Message-
> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: 2017年4月4日 2:49
> To: Dmitry Torokhov
> Cc: Xinming Hu; Linux Wireless; Kalle Valo; Rajat Jain; Amitkumar Karwar; 
> Cathy
> Luo; Xinming Hu
> Subject: [EXT] Re: [PATCH 3/3] mwifiex: pcie: avoid hardcode wifi-only
> firmware name
> 
> External Email
> 
> --
> On Fri, Mar 31, 2017 at 03:50:27PM -0700, Dmitry Torokhov wrote:
> > That said, I consider the whole wifi-only firmware business is quite
> > fragile. Can we have unified firmware and have driver figure out what
> > part shoudl be [re]loaded?
> 
> +1. I think we should really give a stab at this first, and *then* see
> how we want to patch up the flagging of support on a per-chipset basis.
> As-is, you're wasting filesystem space on a duplicate firmware blob, that we
> have to make sure gets updated in sync with the combined firmware every
> time there's an update.
> 
> Proof of the duplicate blob -- the latter portion of the combined FW is 
> identical
> to the WLAN-only:
> 
>   $ cmp mrvl/pcie{usb8997_combo,8997_wlan}_v4.bin $((0x2919c)); echo $?
>   0

Thanks for the review, we have a new solution for extracting wifi-only part 
from combo firmware, will send it in v2.

Thanks
Simon
> 
> Brian

RE: Re: [PATCH 3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name

[Xinming Hu]

Hi Dmitry,

> -Original Message-
> From: Dmitry Torokhov [mailto:d...@google.com]
> Sent: 2017年4月1日 6:50
> To: Xinming Hu
> Cc: Linux Wireless; Kalle Valo; Brian Norris; Rajat Jain; Amitkumar Karwar;
> Cathy Luo; Xinming Hu
> Subject: [EXT] Re: [PATCH 3/3] mwifiex: pcie: avoid hardcode wifi-only
> firmware name
> 
> External Email
> 
> --
> On Thu, Mar 30, 2017 at 2:19 AM, Xinming Hu 
> wrote:
> > From: Xinming Hu 
> >
> > Wifi-only firmware name should be chipset specific.
> >
> > Signed-off-by: Xinming Hu 
> > Signed-off-by: Amitkumar Karwar 
> > ---
> >  drivers/net/wireless/marvell/mwifiex/pcie.c | 8 +++-
> > drivers/net/wireless/marvell/mwifiex/pcie.h | 6 ++
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> > b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > index 59cb01a..282aa9a 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > @@ -351,6 +351,12 @@ static void mwifiex_pcie_reset_notify(struct pci_dev
> *pdev, bool prepare)
> > struct pcie_service_card *card = pci_get_drvdata(pdev);
> > struct mwifiex_adapter *adapter = card->adapter;
> >
> > +   if (!card->pcie.flr_support) {
> > +   pr_err("%s: FLR disabled in current chipset\n", __func__);
> > +   return;
> > +   }
> > +
> > +   adapter = card->adapter;
> > if (!adapter) {
> > dev_err(>dev, "%s: adapter structure is not
> valid\n",
> > __func__);
> > @@ -3047,7 +3053,7 @@ static void mwifiex_pcie_up_dev(struct
> mwifiex_adapter *adapter)
> >  * during pcie FLR, so that bluetooth part of firmware which is
> >  * already running doesn't get affected.
> >  */
> > -   strcpy(adapter->fw_name, PCIE8997_DEFAULT_WIFIFW_NAME);
> > +   strcpy(adapter->fw_name, card->pcie.wifi_fw_name);
> >
> > /* tx_buf_size might be changed to 3584 by firmware during
> >  * data transfer, we should reset it to default size.
> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > index 00e8ee5..d6c8526 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > @@ -285,6 +285,8 @@ struct mwifiex_pcie_device {
> > struct memory_type_mapping *mem_type_mapping_tbl;
> > u8 num_mem_types;
> > bool can_ext_scan;
> > +   u8 flr_support;
> 
> This sounds like a boolean, but given that you can key off wifi_fw_name being
> NULL I am not sure it is needed.
> 
> > +   char *wifi_fw_name;
> 
> const char *.
> 
> That said, I consider the whole wifi-only firmware business is quite fragile. 
> Can
> we have unified firmware and have driver figure out what part shoudl be
> [re]loaded?
> 

Thanks for the review, we have tried to extract wifi-only part from combo 
firmware.
The new solution will be send in V2, in this way, we do not need separate 
wifi_fw_name any more.

Thanks
Simon

> >  };
> >
> >  static const struct mwifiex_pcie_device mwifiex_pcie8766 = { @@
> > -293,6 +295,7 @@ struct mwifiex_pcie_device {
> > .tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K,
> > .can_dump_fw = false,
> > .can_ext_scan = true,
> > +   .flr_support = 0,
> >  };
> >
> >  static const struct mwifiex_pcie_device mwifiex_pcie8897 = { @@
> > -303,6 +306,7 @@ struct mwifiex_pcie_device {
> > .mem_type_mapping_tbl = mem_type_mapping_tbl_w8897,
> > .num_mem_types = ARRAY_SIZE(mem_type_mapping_tbl_w8897),
> > .can_ext_scan = true,
> > +   .flr_support = 0,
> >  };
> >
> >  static const struct mwifiex_pcie_device mwifiex_pcie8997 = { @@
> > -313,6 +317,8 @@ struct mwifiex_pcie_device {
> > .mem_type_mapping_tbl = mem_type_mapping_tbl_w8997,
> > .num_mem_types = ARRAY_SIZE(mem_type_mapping_tbl_w8997),
> > .can_ext_scan = true,
> > +   .flr_support = 1,
> > +   .wifi_fw_name = "mrvl/pcie8997_wlan_v4.bin",
> >  };
> >
> >  struct mwifiex_evt_buf_desc {
> > --
> > 1.8.1.4
> >
> 
> Thanks.
> 
> --
> Dmitry

Re: [PATCH v2] mac80211: Dynamically set CoDel parameters per station

[kbuild test robot]

Hi Toke,

[auto build test ERROR on mac80211/master]
[also build test ERROR on v4.11-rc5 next-20170406]
[cannot apply to mac80211-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/mac80211-Dynamically-set-CoDel-parameters-per-station/20170406-152423
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
master
config: i386-randconfig-x019-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> net//mac80211/sta_info.c:2308:20: error: static declaration of 
>> 'sta_update_codel_params' follows non-static declaration
static inline void sta_update_codel_params(struct sta_info *sta, u32 thr)
   ^~~
   In file included from net//mac80211/ieee80211_i.h:35:0,
from net//mac80211/sta_info.c:25:
   net//mac80211/sta_info.h:727:6: note: previous declaration of 
'sta_update_codel_params' was here
void sta_update_codel_params(struct sta_info *sta, u32 thr);
 ^~~
--
   net//mac80211/tx.c: In function 'fq_tin_dequeue_func':
>> net//mac80211/tx.c:1352:26: error: 'struct codel_params' has no member named 
>> 'params'
  cparams = >cparams.params;
 ^

vim +/sta_update_codel_params +2308 net//mac80211/sta_info.c

  2302  
  2303  if (time_after(stats->last_rx, sta->status_stats.last_ack))
  2304  return stats->last_rx;
  2305  return sta->status_stats.last_ack;
  2306  }
  2307  
> 2308  static inline void sta_update_codel_params(struct sta_info *sta, u32 
> thr)
  2309  {
  2310  if (!sta->sdata->local->ops->wake_tx_queue)
  2311  return;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] staging: Add rtl8723bs sdio wifi driver

[Hans de Goede]

Hi,

On 05-04-17 18:32, Larry Finger wrote:

On 04/05/2017 04:36 AM, Hans de Goede wrote:

Hi,

On 05-04-17 01:41, Larry Finger wrote:

On 04/04/2017 04:53 PM, Hans de Goede wrote:

Hi,

On 04/04/2017 11:38 PM, Arend Van Spriel wrote:



On 4-4-2017 20:53, Hans de Goede wrote:

Hi,

On 04/04/2017 08:31 PM, Larry Finger wrote:

On 03/29/2017 12:47 PM, Hans de Goede wrote:

The rtl8723bs is found on quite a few systems used by Linux users,
such as on Atom systems (Intel Computestick and various other
Atom based devices) and on many (budget) ARM boards such as
the CHIP.

The plan moving forward with this is for the new clean,
written from scratch, rtl8xxxu driver to eventually gain
support for sdio devices. But there is no clear timeline
for that, so lets add this driver included in staging for now.


Hans,

I started looking at the Smatch errors. This one may be the result of
a serious problem:

  CHECK   drivers/staging/rtl8723bs/core/rtw_debug.c
drivers/staging/rtl8723bs/core/rtw_debug.c:454 proc_get_survey_info()
error: we previously assumed 'phead' could be null (see line 453)
drivers/staging/rtl8723bs/core/rtw_debug.c:455 proc_get_survey_info()
warn: variable dereferenced before check 'phead' (see line 454)

A snippet of the code in question is as follows:

spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
phead = get_list_head(queue);
plist = phead ? get_next(phead) : NULL;
plist = get_next(phead);
if ((!phead) || (!plist)) {
spin_unlock_bh(&(pmlmepriv->scanned_queue.lock));
return 0;
}

This code comes directly from the hadess repo, but I am suspicious of
the double call to get_next(phead). I cannot imagine any valid reason
to skip every other entry on that list.


If you look closer and simplify the first getnext line what is written is:

 plist = get_next(phead);
 plist = get_next(phead);

Which indeed looks like it could use improvement, but I don't
think it is seriously broken.


So get_list_head(queue) can never return NULL?


I don't know.


Otherwise I don't know
how close I need to get for a simplified look ;-)


I simplified things so as to make clear that Larry's worry was
not really a problem, I do agree the smatch complaint is valid.


I think the following fixes the problem:

diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c
b/drivers/staging/rtl8723bs/core/rtw_debug.c
index d34747b29309..51cef55d3f76 100644
--- a/drivers/staging/rtl8723bs/core/rtw_debug.c
+++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
@@ -451,7 +451,6 @@ int proc_get_survey_info(struct seq_file *m, void *v)
spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
phead = get_list_head(queue);
plist = phead ? get_next(phead) : NULL;
-   plist = get_next(phead);
if ((!phead) || (!plist)) {
spin_unlock_bh(&(pmlmepriv->scanned_queue.lock));
return 0;

Pointer plist is set in the 3rd line, thus the second set of it can be removed.


Agreed, when I've some time I plan to do a follow-up patch
to my initial submission fixing all the Smatch errors. But feel
free to beat me to it.

Greg, if I understood you correctly you plan to merge my initial
submission as is and then we can fix this (and other things) with
follow up patches, right ?


Hans,

I took GregKH out of the Cc list when I started the discussion of the Smatch 
errors/warnings, and he probably has not seen the recent E-mails in this thread.


Ah I missed that (clearly I did).


It it was my understanding that he planned to apply your submission in the form 
you sent.


That is my understanding too.


I have several patches nearly ready to fix most of the Smatch warnings and 
errors. I will send them as soon as the original submission is applied.


Good thank you. So what is the plan with the github version ?

Note that my submission contains a few small fixes on top of
the github version, for which I intended to submit a pull-req
but I've not gotten around to that yet, I've done so now:

https://github.com/hadess/rtl8723bs/pull/125

But do we want to keep maintaining the github version (for a while
at least) I wonder, as that does mean double work?

Regards,

Hans