Re: pull-request: mac80211 2017-10-16

[Johannes Berg]

On Tue, 2017-10-17 at 01:30 +0200, Jason A. Donenfeld wrote:
> Mobile phone right now, so not able to write patch, but you probably
> should be using crypto_memneq for comparing those two keys, not
> memcmp.

I know that's a gut instinct, but I really don't see the point.

If you actually get this to evaluate to "equal", you're already being
attacked, and the attacker already knows they're trying to get the same
key to be installed again. If it's not equal, you execute so much code
beneath, going to the driver etc., that I'd think this particular time
is in the noise.

Also, this isn't something that the attacker can directly observe
anyway, and if they can, then surely the fact that we *skip* a large
amount of code when returning 0 is also observable.

Besides, the only thing that can observe the timing is hostapd or
wpa_supplicant, which obviously know the key (and in the fixed versions
will already have done the comparison themselves).

And lastly, if you wanted to use this as an oracle to get the key back
from the kernel, then you already have admin permissions (in your
network namespace), and can just sniff netlink traffic anyway.

johannes

RE: Two rtlwifi drivers?

[Pkshih]

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Monday, October 16, 2017 9:23 PM
> To: Pkshih
> Cc: Larry Finger; Greg Kroah-Hartman; Dan Carpenter; 莊彥宣; Johannes Berg; 
> Souptick Joarder;
> de...@driverdev.osuosl.org; linux-wireless@vger.kernel.org; 
> kernel-janit...@vger.kernel.org
> Subject: Re: Two rtlwifi drivers?
> 
> Hi PK,
> 
> you got good answers already so only short reply from me:
> 
> Pkshih  writes:
> 
> > 3) Coming drivers -- rtl8723de and rtl8821ce
> >We're developing the two drivers, and rtl8723de and rtl8821ce will
> >be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on
> >rtl8822be that in staging now, so the line of code will be fewer.
> >The new files will be a new IC folder and IC supported files of
> >three modules that btcoexist, phydm and halmac. Could I submit
> >them to wirless tree when they're ready?
> 
> My recommendation is to avoid accumulating patches at all cost and start
> submitting them as soon as you can. This way you get patches committed
> much more smoother. So do not wait until _all_ patches are ready,
> instead start submitting patches as soon as you have _some_ patches
> ready. In other words, keep the delta between mainline and your
> not-yet-submitted patches as small as possible.
> 
> And the patches don't need to be bug free as you can always fix bugs
> later. Just mention in the commit logs that this is preparation for some
> new feature and not fully tested yet. We do that all the time, for
> example Intel's iwlwifi has support for hardware which have not reached
> customers yet.
> 

Thanks for your answer. I'll submit patches when the drivers are ready and
stable. I have another question about the rules of new files. If I want to
add some new files, could I send a big patch with all new files? Is there
any limit? 

Thanks
PK

RE: Two rtlwifi drivers?

[Pkshih]

> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Monday, October 16, 2017 3:50 PM
> To: Pkshih
> Cc: Larry Finger; Kalle Valo; Dan Carpenter; 莊彥宣; Johannes Berg; Souptick 
> Joarder;
> de...@driverdev.osuosl.org; linux-wireless@vger.kernel.org; 
> kernel-janit...@vger.kernel.org
> Subject: Re: Two rtlwifi drivers?
> 
> 
> > 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I
> >plan to fix them after rtl8723de and rtl8821ce. Because the drivers
> >are developing, the changes will make us hard to integrate. However,
> >I don't have plan to process the magic numbers in the module phydm,
> >because the most of BB/RF registers contain many functions. And
> >it doesn't have a register name but a bit field name instead.
> >Our BB team guys say the use of enumeration or defined name will
> >be unreadable, and the name is meaningless for most people.
> 
> Don't be so sure that names are "meaningless", there are people here
> that have been doing network drivers and development for longer than
> anyone else in the world.  It's best to at least name values, even if
> they do not seem to make sense, as that way the value can be tracked
> correctly, and possibly be understood later by someone else, or even
> you!
> 

Thanks for your help to resolve our questions.
I'll pass this point to the guys.

PK

[PATCH 17/58] net/cw1200: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Solomon Peachy 
Cc: Kalle Valo 
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/st/cw1200/pm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/st/cw1200/pm.c 
b/drivers/net/wireless/st/cw1200/pm.c
index d2202ae92bdd..ded23df1ac1d 100644
--- a/drivers/net/wireless/st/cw1200/pm.c
+++ b/drivers/net/wireless/st/cw1200/pm.c
@@ -91,7 +91,7 @@ struct cw1200_suspend_state {
u8 prev_ps_mode;
 };
 
-static void cw1200_pm_stay_awake_tmo(unsigned long arg)
+static void cw1200_pm_stay_awake_tmo(struct timer_list *unused)
 {
/* XXX what's the point of this ? */
 }
@@ -101,8 +101,7 @@ int cw1200_pm_init(struct cw1200_pm_state *pm,
 {
spin_lock_init(>lock);
 
-   setup_timer(>stay_awake, cw1200_pm_stay_awake_tmo,
-   (unsigned long)pm);
+   timer_setup(>stay_awake, cw1200_pm_stay_awake_tmo, 0);
 
return 0;
 }
-- 
2.7.4

[PATCH 08/58] net/wireless/ray_cs: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Kalle Valo 
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/ray_cs.c | 53 ---
 1 file changed, 24 insertions(+), 29 deletions(-)

diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
index 170cd504e8ff..d8afcdfca1ed 100644
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -92,7 +92,7 @@ static const struct iw_handler_def ray_handler_def;
 /* Prototypes for raylink functions **/
 static void authenticate(ray_dev_t *local);
 static int build_auth_frame(ray_dev_t *local, UCHAR *dest, int auth_type);
-static void authenticate_timeout(u_long);
+static void authenticate_timeout(struct timer_list *t);
 static int get_free_ccs(ray_dev_t *local);
 static int get_free_tx_ccs(ray_dev_t *local);
 static void init_startup_params(ray_dev_t *local);
@@ -102,7 +102,7 @@ static int ray_init(struct net_device *dev);
 static int interrupt_ecf(ray_dev_t *local, int ccs);
 static void ray_reset(struct net_device *dev);
 static void ray_update_parm(struct net_device *dev, UCHAR objid, UCHAR *value, 
int len);
-static void verify_dl_startup(u_long);
+static void verify_dl_startup(struct timer_list *t);
 
 /* Prototypes for interrpt time functions **/
 static irqreturn_t ray_interrupt(int reg, void *dev_id);
@@ -120,9 +120,8 @@ static void associate(ray_dev_t *local);
 
 /* Card command functions */
 static int dl_startup_params(struct net_device *dev);
-static void join_net(u_long local);
-static void start_net(u_long local);
-/* void start_net(ray_dev_t *local); */
+static void join_net(struct timer_list *t);
+static void start_net(struct timer_list *t);
 
 /*===*/
 /* Parameters that can be set with 'insmod' */
@@ -323,7 +322,7 @@ static int ray_probe(struct pcmcia_device *p_dev)
dev_dbg(_dev->dev, "ray_cs ray_attach calling ether_setup.)\n");
netif_stop_queue(dev);
 
-   init_timer(>timer);
+   timer_setup(>timer, NULL, 0);
 
this_device = p_dev;
return ray_config(p_dev);
@@ -570,8 +569,7 @@ static int dl_startup_params(struct net_device *dev)
local->card_status = CARD_DL_PARAM;
/* Start kernel timer to wait for dl startup to complete. */
local->timer.expires = jiffies + HZ / 2;
-   local->timer.data = (long)local;
-   local->timer.function = verify_dl_startup;
+   local->timer.function = (TIMER_FUNC_TYPE)verify_dl_startup;
add_timer(>timer);
dev_dbg(>dev,
  "ray_cs dl_startup_params started timer for verify_dl_startup\n");
@@ -641,9 +639,9 @@ static void init_startup_params(ray_dev_t *local)
 } /* init_startup_params */
 
 /*===*/
-static void verify_dl_startup(u_long data)
+static void verify_dl_startup(struct timer_list *t)
 {
-   ray_dev_t *local = (ray_dev_t *) data;
+   ray_dev_t *local = from_timer(local, t, timer);
struct ccs __iomem *pccs = ccs_base(local) + local->dl_param_ccs;
UCHAR status;
struct pcmcia_device *link = local->finder;
@@ -676,16 +674,16 @@ static void verify_dl_startup(u_long data)
return;
}
if (local->sparm.b4.a_network_type == ADHOC)
-   start_net((u_long) local);
+   start_net(>timer);
else
-   join_net((u_long) local);
+   join_net(>timer);
 } /* end verify_dl_startup */
 
 /*===*/
 /* Command card to start a network */
-static void start_net(u_long data)
+static void start_net(struct timer_list *t)
 {
-   ray_dev_t *local = (ray_dev_t *) data;
+   ray_dev_t *local = from_timer(local, t, timer);
struct ccs __iomem *pccs;
int ccsindex;
struct pcmcia_device *link = local->finder;
@@ -710,9 +708,9 @@ static void start_net(u_long data)
 
 /*===*/
 /* Command card to join a network */
-static void join_net(u_long data)
+static void join_net(struct timer_list *t)
 {
-   ray_dev_t *local = (ray_dev_t *) data;
+   ray_dev_t *local = from_timer(local, t, timer);
 
struct ccs __iomem *pccs;
int ccsindex;
@@ -1639,13 +1637,13 @@ static int get_free_ccs(ray_dev_t *local)
 } /* get_free_ccs */
 
 /*===*/
-static void authenticate_timeout(u_long data)
+static void authenticate_timeout(struct timer_list *t)
 {
-   

[PATCH] wireless: ath: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Kalle Valo 
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/ath/ar5523/ar5523.c  |  7 +++
 drivers/net/wireless/ath/ath10k/htt_rx.c  |  6 +++---
 drivers/net/wireless/ath/ath10k/pci.c | 17 -
 drivers/net/wireless/ath/ath10k/pci.h |  2 +-
 drivers/net/wireless/ath/ath6kl/cfg80211.c|  6 ++
 drivers/net/wireless/ath/ath6kl/core.h|  2 +-
 drivers/net/wireless/ath/ath6kl/main.c|  5 ++---
 drivers/net/wireless/ath/ath6kl/txrx.c|  6 +++---
 drivers/net/wireless/ath/ath6kl/wmi.c |  4 ++--
 drivers/net/wireless/ath/ath6kl/wmi.h |  2 +-
 drivers/net/wireless/ath/ath9k/ath9k.h|  4 ++--
 drivers/net/wireless/ath/ath9k/channel.c  | 14 ++
 drivers/net/wireless/ath/ath9k/gpio.c | 14 ++
 drivers/net/wireless/ath/ath9k/htc.h  |  2 +-
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |  3 +--
 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c |  4 ++--
 drivers/net/wireless/ath/ath9k/init.c |  4 ++--
 drivers/net/wireless/ath/ath9k/link.c |  6 +++---
 drivers/net/wireless/ath/ath9k/main.c |  4 ++--
 drivers/net/wireless/ath/wil6210/main.c   | 15 +++
 drivers/net/wireless/ath/wil6210/p2p.c|  4 ++--
 drivers/net/wireless/ath/wil6210/wil6210.h|  2 +-
 22 files changed, 61 insertions(+), 72 deletions(-)

diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c 
b/drivers/net/wireless/ath/ar5523/ar5523.c
index 68f0463ed8df..b94759daeacc 100644
--- a/drivers/net/wireless/ath/ar5523/ar5523.c
+++ b/drivers/net/wireless/ath/ar5523/ar5523.c
@@ -889,9 +889,9 @@ static void ar5523_tx_work(struct work_struct *work)
mutex_unlock(>mutex);
 }
 
-static void ar5523_tx_wd_timer(unsigned long arg)
+static void ar5523_tx_wd_timer(struct timer_list *t)
 {
-   struct ar5523 *ar = (struct ar5523 *) arg;
+   struct ar5523 *ar = from_timer(ar, t, tx_wd_timer);
 
ar5523_dbg(ar, "TX watchdog timer triggered\n");
ieee80211_queue_work(ar->hw, >tx_wd_work);
@@ -1599,8 +1599,7 @@ static int ar5523_probe(struct usb_interface *intf,
mutex_init(>mutex);
 
INIT_DELAYED_WORK(>stat_work, ar5523_stat_work);
-   init_timer(>tx_wd_timer);
-   setup_timer(>tx_wd_timer, ar5523_tx_wd_timer, (unsigned long) ar);
+   timer_setup(>tx_wd_timer, ar5523_tx_wd_timer, 0);
INIT_WORK(>tx_wd_work, ar5523_tx_wd_work);
INIT_WORK(>tx_work, ar5523_tx_work);
INIT_LIST_HEAD(>tx_queue_pending);
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index a3f5dc78353f..f068376ec565 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -200,9 +200,9 @@ static void ath10k_htt_rx_msdu_buff_replenish(struct 
ath10k_htt *htt)
spin_unlock_bh(>rx_ring.lock);
 }
 
-static void ath10k_htt_rx_ring_refill_retry(unsigned long arg)
+static void ath10k_htt_rx_ring_refill_retry(struct timer_list *t)
 {
-   struct ath10k_htt *htt = (struct ath10k_htt *)arg;
+   struct ath10k_htt *htt = from_timer(htt, t, rx_ring.refill_retry_timer);
 
ath10k_htt_rx_msdu_buff_replenish(htt);
 }
@@ -507,7 +507,7 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)
*htt->rx_ring.alloc_idx.vaddr = 0;
 
/* Initialize the Rx refill retry timer */
-   setup_timer(timer, ath10k_htt_rx_ring_refill_retry, (unsigned long)htt);
+   timer_setup(timer, ath10k_htt_rx_ring_refill_retry, 0);
 
spin_lock_init(>rx_ring.lock);
 
diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index 195dafb98131..2b975bb3f67e 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -585,10 +585,10 @@ static void ath10k_pci_sleep(struct ath10k *ar)
spin_unlock_irqrestore(_pci->ps_lock, flags);
 }
 
-static void ath10k_pci_ps_timer(unsigned long ptr)
+static void ath10k_pci_ps_timer(struct timer_list *t)
 {
-   struct ath10k *ar = (void *)ptr;
-   struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+   struct ath10k_pci *ar_pci = from_timer(ar_pci, t, ps_timer);
+   struct ath10k *ar = ar_pci->ar;
unsigned long flags;
 
spin_lock_irqsave(_pci->ps_lock, flags);
@@ -838,9 +838,10 @@ void ath10k_pci_rx_post(struct ath10k *ar)
ath10k_pci_rx_post_pipe(_pci->pipe_info[i]);
 }
 
-void ath10k_pci_rx_replenish_retry(unsigned long ptr)
+void ath10k_pci_rx_replenish_retry(struct timer_list *t)
 {
-   struct ath10k *ar = (void *)ptr;
+   struct ath10k_pci *ar_pci = from_timer(ar_pci, t, rx_post_retry);
+   struct ath10k *ar = ar_pci->ar;
 

[PATCH] wireless: iwlegacy: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Stanislaw Gruszka 
Cc: Kalle Valo 
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/intel/iwlegacy/3945-mac.c |  2 +-
 drivers/net/wireless/intel/iwlegacy/3945-rs.c  | 10 +++---
 drivers/net/wireless/intel/iwlegacy/4965-mac.c |  9 -
 drivers/net/wireless/intel/iwlegacy/common.c   |  4 ++--
 drivers/net/wireless/intel/iwlegacy/common.h   |  2 +-
 5 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c 
b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
index 329f3a63dadd..4b53ebf00c7f 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
@@ -3429,7 +3429,7 @@ il3945_setup_deferred_work(struct il_priv *il)
 
il3945_hw_setup_deferred_work(il);
 
-   setup_timer(>watchdog, il_bg_watchdog, (unsigned long)il);
+   timer_setup(>watchdog, il_bg_watchdog, 0);
 
tasklet_init(>irq_tasklet,
 (void (*)(unsigned long))il3945_irq_tasklet,
diff --git a/drivers/net/wireless/intel/iwlegacy/3945-rs.c 
b/drivers/net/wireless/intel/iwlegacy/3945-rs.c
index b2f35dfbc01b..e8983c6a2b7b 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-rs.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-rs.c
@@ -181,9 +181,9 @@ il3945_rate_scale_flush_wins(struct il3945_rs_sta *rs_sta)
 #define IL_AVERAGE_PACKETS 1500
 
 static void
-il3945_bg_rate_scale_flush(unsigned long data)
+il3945_bg_rate_scale_flush(struct timer_list *t)
 {
-   struct il3945_rs_sta *rs_sta = (void *)data;
+   struct il3945_rs_sta *rs_sta = from_timer(rs_sta, t, rate_scale_flush);
struct il_priv *il __maybe_unused = rs_sta->il;
int unflushed = 0;
unsigned long flags;
@@ -360,9 +360,6 @@ il3945_rs_rate_init(struct il_priv *il, struct 
ieee80211_sta *sta, u8 sta_id)
rs_sta->flush_time = RATE_FLUSH;
rs_sta->last_tx_packets = 0;
 
-   rs_sta->rate_scale_flush.data = (unsigned long)rs_sta;
-   rs_sta->rate_scale_flush.function = il3945_bg_rate_scale_flush;
-
for (i = 0; i < RATE_COUNT_3945; i++)
il3945_clear_win(_sta->win[i]);
 
@@ -415,8 +412,7 @@ il3945_rs_alloc_sta(void *il_priv, struct ieee80211_sta 
*sta, gfp_t gfp)
rs_sta = >rs_sta;
 
spin_lock_init(_sta->lock);
-   init_timer(_sta->rate_scale_flush);
-
+   timer_setup(_sta->rate_scale_flush, il3945_bg_rate_scale_flush, 0);
D_RATE("leave\n");
 
return rs_sta;
diff --git a/drivers/net/wireless/intel/iwlegacy/4965-mac.c 
b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
index 65eba2c24292..de63f2518f23 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
@@ -4074,9 +4074,9 @@ il4965_hdl_alive(struct il_priv *il, struct il_rx_buf 
*rxb)
  * used for calibrating the TXPOWER.
  */
 static void
-il4965_bg_stats_periodic(unsigned long data)
+il4965_bg_stats_periodic(struct timer_list *t)
 {
-   struct il_priv *il = (struct il_priv *)data;
+   struct il_priv *il = from_timer(il, t, stats_periodic);
 
if (test_bit(S_EXIT_PENDING, >status))
return;
@@ -6258,10 +6258,9 @@ il4965_setup_deferred_work(struct il_priv *il)
 
INIT_WORK(>txpower_work, il4965_bg_txpower_work);
 
-   setup_timer(>stats_periodic, il4965_bg_stats_periodic,
-   (unsigned long)il);
+   timer_setup(>stats_periodic, il4965_bg_stats_periodic, 0);
 
-   setup_timer(>watchdog, il_bg_watchdog, (unsigned long)il);
+   timer_setup(>watchdog, il_bg_watchdog, 0);
 
tasklet_init(>irq_tasklet,
 (void (*)(unsigned long))il4965_irq_tasklet,
diff --git a/drivers/net/wireless/intel/iwlegacy/common.c 
b/drivers/net/wireless/intel/iwlegacy/common.c
index 8d5acda92a9b..558bb16bfd46 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -4844,9 +4844,9 @@ il_check_stuck_queue(struct il_priv *il, int cnt)
  * we reset the firmware. If everything is fine just rearm the timer.
  */
 void
-il_bg_watchdog(unsigned long data)
+il_bg_watchdog(struct timer_list *t)
 {
-   struct il_priv *il = (struct il_priv *)data;
+   struct il_priv *il = from_timer(il, t, watchdog);
int cnt;
unsigned long timeout;
 
diff --git a/drivers/net/wireless/intel/iwlegacy/common.h 
b/drivers/net/wireless/intel/iwlegacy/common.h
index 18c60c92e3a3..dc6a74a05983 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.h
+++ b/drivers/net/wireless/intel/iwlegacy/common.h
@@ -1832,7 +1832,7 @@ int il_enqueue_hcmd(struct il_priv *il, struct 
il_host_cmd *cmd);
  

[PATCH] rtlwifi: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Larry Finger 
Cc: Chaoming Li 
Cc: Kalle Valo 
Cc: Ping-Ke Shih 
Cc: Arvind Yadav 
Cc: Souptick Joarder 
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/realtek/rtlwifi/base.c | 21 +++--
 drivers/net/wireless/realtek/rtlwifi/base.h |  4 ++--
 drivers/net/wireless/realtek/rtlwifi/core.c |  2 +-
 drivers/net/wireless/realtek/rtlwifi/ps.c   |  2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c |  6 --
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.h |  2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c |  6 --
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.h |  2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 12 
 9 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index ea18aa7afecb..ef97a3c36d51 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -461,10 +461,10 @@ static void _rtl_init_deferred_work(struct ieee80211_hw 
*hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
 
/* <1> timer */
-   setup_timer(>works.watchdog_timer,
-   rtl_watch_dog_timer_callback, (unsigned long)hw);
-   setup_timer(>works.dualmac_easyconcurrent_retrytimer,
-   rtl_easy_concurrent_retrytimer_callback, (unsigned long)hw);
+   timer_setup(>works.watchdog_timer,
+   rtl_watch_dog_timer_callback, 0);
+   timer_setup(>works.dualmac_easyconcurrent_retrytimer,
+   rtl_easy_concurrent_retrytimer_callback, 0);
/* <2> work queue */
rtlpriv->works.hw = hw;
rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
@@ -1975,10 +1975,10 @@ void rtl_watchdog_wq_callback(void *data)
rtl_scan_list_expire(hw);
 }
 
-void rtl_watch_dog_timer_callback(unsigned long data)
+void rtl_watch_dog_timer_callback(struct timer_list *t)
 {
-   struct ieee80211_hw *hw = (struct ieee80211_hw *)data;
-   struct rtl_priv *rtlpriv = rtl_priv(hw);
+   struct rtl_priv *rtlpriv = from_timer(rtlpriv, t, works.watchdog_timer);
+   struct ieee80211_hw *hw = rtlpriv->hw;
 
queue_delayed_work(rtlpriv->works.rtl_wq,
   >works.watchdog_wq, 0);
@@ -2084,10 +2084,11 @@ void rtl_c2hcmd_wq_callback(void *data)
rtl_c2hcmd_launcher(hw, 1);
 }
 
-void rtl_easy_concurrent_retrytimer_callback(unsigned long data)
+void rtl_easy_concurrent_retrytimer_callback(struct timer_list *t)
 {
-   struct ieee80211_hw *hw = (struct ieee80211_hw *)data;
-   struct rtl_priv *rtlpriv = rtl_priv(hw);
+   struct rtl_priv *rtlpriv =
+   from_timer(rtlpriv, t, works.dualmac_easyconcurrent_retrytimer);
+   struct ieee80211_hw *hw = rtlpriv->hw;
struct rtl_priv *buddy_priv = rtlpriv->buddy_priv;
 
if (buddy_priv == NULL)
diff --git a/drivers/net/wireless/realtek/rtlwifi/base.h 
b/drivers/net/wireless/realtek/rtlwifi/base.h
index b56d1b7f5567..23f1564811b8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.h
+++ b/drivers/net/wireless/realtek/rtlwifi/base.h
@@ -120,7 +120,7 @@ void rtl_init_rx_config(struct ieee80211_hw *hw);
 void rtl_init_rfkill(struct ieee80211_hw *hw);
 void rtl_deinit_rfkill(struct ieee80211_hw *hw);
 
-void rtl_watch_dog_timer_callback(unsigned long data);
+void rtl_watch_dog_timer_callback(struct timer_list *t);
 void rtl_deinit_deferred_work(struct ieee80211_hw *hw);
 
 bool rtl_action_proc(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx);
@@ -169,7 +169,7 @@ int rtl_send_smps_action(struct ieee80211_hw *hw,
 u8 *rtl_find_ie(u8 *data, unsigned int len, u8 ie);
 void rtl_recognize_peer(struct ieee80211_hw *hw, u8 *data, unsigned int len);
 u8 rtl_tid_to_ac(u8 tid);
-void rtl_easy_concurrent_retrytimer_callback(unsigned long data);
+void rtl_easy_concurrent_retrytimer_callback(struct timer_list *t);
 extern struct rtl_global_var rtl_global_var;
 void rtl_phy_scan_operation_backup(struct ieee80211_hw *hw, u8 operation);
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c 
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 294a6b43d1bc..e025cb06443d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -160,7 +160,7 @@ static int rtl_op_start(struct ieee80211_hw *hw)
mutex_lock(>locks.conf_mutex);
err = rtlpriv->intf_ops->adapter_start(hw);
if (!err)
-   

[PATCH] wireless: qtnfmac: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Igor Mitsyanko 
Cc: Avinash Patil 
Cc: Sergey Matyukevich 
Cc: Kalle Valo 
Cc: Kamlesh Rath 
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 7 +++
 drivers/net/wireless/quantenna/qtnfmac/core.c | 2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 32bf72c0399f..ac1b9bd5ed90 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -581,9 +581,9 @@ qtnf_del_station(struct wiphy *wiphy, struct net_device 
*dev,
return ret;
 }
 
-static void qtnf_scan_timeout(unsigned long data)
+static void qtnf_scan_timeout(struct timer_list *t)
 {
-   struct qtnf_wmac *mac = (struct qtnf_wmac *)data;
+   struct qtnf_wmac *mac = from_timer(mac, t, scan_timeout);
 
pr_warn("mac%d scan timed out\n", mac->macid);
qtnf_scan_done(mac, true);
@@ -602,8 +602,7 @@ qtnf_scan(struct wiphy *wiphy, struct cfg80211_scan_request 
*request)
return -EFAULT;
}
 
-   mac->scan_timeout.data = (unsigned long)mac;
-   mac->scan_timeout.function = qtnf_scan_timeout;
+   mac->scan_timeout.function = (TIMER_FUNC_TYPE)qtnf_scan_timeout;
mod_timer(>scan_timeout,
  jiffies + QTNF_SCAN_TIMEOUT_SEC * HZ);
 
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.c 
b/drivers/net/wireless/quantenna/qtnfmac/core.c
index 5e60180482d1..aa7f146278a7 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.c
@@ -289,7 +289,7 @@ static struct qtnf_wmac *qtnf_core_mac_alloc(struct 
qtnf_bus *bus,
mac->iflist[i].vifid = i;
qtnf_sta_list_init(>iflist[i].sta_list);
mutex_init(>mac_lock);
-   init_timer(>scan_timeout);
+   setup_timer(>scan_timeout, NULL, 0);
}
 
qtnf_mac_init_primary_intf(mac);
-- 
2.7.4


-- 
Kees Cook
Pixel Security

[PATCH] mac80211: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Johannes Berg 
Cc: "David S. Miller" 
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook 
---
 net/mac80211/ibss.c |  7 +++
 net/mac80211/ieee80211_i.h  |  3 ++-
 net/mac80211/led.c  | 11 ++-
 net/mac80211/main.c |  3 +--
 net/mac80211/mesh.c | 27 ---
 net/mac80211/mesh.h |  2 +-
 net/mac80211/mesh_hwmp.c|  4 ++--
 net/mac80211/mesh_pathtbl.c |  3 +--
 net/mac80211/mlme.c | 32 ++--
 net/mac80211/ocb.c  | 10 +-
 net/mac80211/sta_info.c |  7 +++
 11 files changed, 50 insertions(+), 59 deletions(-)

diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index e9c6aa3ed05b..db07e0de9a03 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1711,10 +1711,10 @@ void ieee80211_ibss_work(struct ieee80211_sub_if_data 
*sdata)
sdata_unlock(sdata);
 }
 
-static void ieee80211_ibss_timer(unsigned long data)
+static void ieee80211_ibss_timer(struct timer_list *t)
 {
struct ieee80211_sub_if_data *sdata =
-   (struct ieee80211_sub_if_data *) data;
+   from_timer(sdata, t, u.ibss.timer);
 
ieee80211_queue_work(>local->hw, >work);
 }
@@ -1723,8 +1723,7 @@ void ieee80211_ibss_setup_sdata(struct 
ieee80211_sub_if_data *sdata)
 {
struct ieee80211_if_ibss *ifibss = >u.ibss;
 
-   setup_timer(>timer, ieee80211_ibss_timer,
-   (unsigned long) sdata);
+   timer_setup(>timer, ieee80211_ibss_timer, 0);
INIT_LIST_HEAD(>incomplete_stations);
spin_lock_init(>incomplete_lock);
INIT_WORK(>csa_connection_drop_work,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 68f874e73561..885d00b41911 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1057,6 +1057,7 @@ struct tpt_led_trigger {
const struct ieee80211_tpt_blink *blink_table;
unsigned int blink_table_len;
struct timer_list timer;
+   struct ieee80211_local *local;
unsigned long prev_traffic;
unsigned long tx_bytes, rx_bytes;
unsigned int active, want;
@@ -1932,7 +1933,7 @@ static inline int ieee80211_ac_from_tid(int tid)
 
 void ieee80211_dynamic_ps_enable_work(struct work_struct *work);
 void ieee80211_dynamic_ps_disable_work(struct work_struct *work);
-void ieee80211_dynamic_ps_timer(unsigned long data);
+void ieee80211_dynamic_ps_timer(struct timer_list *t);
 void ieee80211_send_nullfunc(struct ieee80211_local *local,
 struct ieee80211_sub_if_data *sdata,
 bool powersave);
diff --git a/net/mac80211/led.c b/net/mac80211/led.c
index 0505845b7ab8..ba0b507ea691 100644
--- a/net/mac80211/led.c
+++ b/net/mac80211/led.c
@@ -248,10 +248,10 @@ static unsigned long tpt_trig_traffic(struct 
ieee80211_local *local,
return DIV_ROUND_UP(delta, 1024 / 8);
 }
 
-static void tpt_trig_timer(unsigned long data)
+static void tpt_trig_timer(struct timer_list *t)
 {
-   struct ieee80211_local *local = (void *)data;
-   struct tpt_led_trigger *tpt_trig = local->tpt_led_trigger;
+   struct tpt_led_trigger *tpt_trig = from_timer(tpt_trig, t, timer);
+   struct ieee80211_local *local = tpt_trig->local;
struct led_classdev *led_cdev;
unsigned long on, off, tpt;
int i;
@@ -306,8 +306,9 @@ __ieee80211_create_tpt_led_trigger(struct ieee80211_hw *hw,
tpt_trig->blink_table = blink_table;
tpt_trig->blink_table_len = blink_table_len;
tpt_trig->want = flags;
+   tpt_trig->local = local;
 
-   setup_timer(_trig->timer, tpt_trig_timer, (unsigned long)local);
+   timer_setup(_trig->timer, tpt_trig_timer, 0);
 
local->tpt_led_trigger = tpt_trig;
 
@@ -326,7 +327,7 @@ static void ieee80211_start_tpt_led_trig(struct 
ieee80211_local *local)
tpt_trig_traffic(local, tpt_trig);
tpt_trig->running = true;
 
-   tpt_trig_timer((unsigned long)local);
+   tpt_trig_timer(_trig->timer);
mod_timer(_trig->timer, round_jiffies(jiffies + HZ));
 }
 
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 8aa1f5b6a051..e054a2fd8d38 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -633,8 +633,7 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t 
priv_data_len,
  ieee80211_dynamic_ps_enable_work);
INIT_WORK(>dynamic_ps_disable_work,
  ieee80211_dynamic_ps_disable_work);
-   setup_timer(>dynamic_ps_timer,
-   ieee80211_dynamic_ps_timer, (unsigned long) local);
+   timer_setup(>dynamic_ps_timer, ieee80211_dynamic_ps_timer, 0);
 

Re: pull-request: mac80211 2017-10-16

[Jason A. Donenfeld]

Mobile phone right now, so not able to write patch, but you probably
should be using crypto_memneq for comparing those two keys, not
memcmp.

Jason

[PATCH] staging/wilc1000: Convert timers to use timer_setup()

[Kees Cook]

As part of removing the timer_list.data field, this converts the wilc1000
driver to using from_timer and an explicit per-timer data field, since
there doesn't appear to be a way to sanely resolve vif from hif_drv.

Cc: Aditya Shankar 
Cc: Ganesh Krishna 
Cc: Greg Kroah-Hartman 
Cc: linux-wireless@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Kees Cook 
---
 drivers/staging/wilc1000/host_interface.c | 39 +--
 drivers/staging/wilc1000/host_interface.h |  5 +++
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c |  4 +--
 3 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 7b620658ec38..c16f96308a97 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -238,6 +238,7 @@ static struct completion hif_driver_comp;
 static struct completion hif_wait_response;
 static struct mutex hif_deinit_lock;
 static struct timer_list periodic_rssi;
+static struct wilc_vif *periodic_rssi_vif;
 
 u8 wilc_multicast_mac_addr_list[WILC_MULTICAST_TABLE_SIZE][ETH_ALEN];
 
@@ -2272,7 +2273,7 @@ static int Handle_RemainOnChan(struct wilc_vif *vif,
 ERRORHANDLER:
{
P2P_LISTEN_STATE = 1;
-   hif_drv->remain_on_ch_timer.data = (unsigned long)vif;
+   hif_drv->remain_on_ch_timer_vif = vif;
mod_timer(_drv->remain_on_ch_timer,
  jiffies +
  msecs_to_jiffies(pstrHostIfRemainOnChan->duration));
@@ -2360,11 +2361,13 @@ static u32 Handle_ListenStateExpired(struct wilc_vif 
*vif,
return result;
 }
 
-static void ListenTimerCB(unsigned long arg)
+static void ListenTimerCB(struct timer_list *t)
 {
+   struct host_if_drv *hif_drv = from_timer(hif_drv, t,
+ remain_on_ch_timer);
+   struct wilc_vif *vif = hif_drv->remain_on_ch_timer_vif;
s32 result = 0;
struct host_if_msg msg;
-   struct wilc_vif *vif = (struct wilc_vif *)arg;
 
del_timer(>hif_drv->remain_on_ch_timer);
 
@@ -2643,9 +2646,10 @@ static void host_if_work(struct work_struct *work)
complete(_thread_comp);
 }
 
-static void TimerCB_Scan(unsigned long arg)
+static void TimerCB_Scan(struct timer_list *t)
 {
-   struct wilc_vif *vif = (struct wilc_vif *)arg;
+   struct host_if_drv *hif_drv = from_timer(hif_drv, t, scan_timer);
+   struct wilc_vif *vif = hif_drv->scan_timer_vif;
struct host_if_msg msg;
 
memset(, 0, sizeof(struct host_if_msg));
@@ -2655,9 +2659,11 @@ static void TimerCB_Scan(unsigned long arg)
wilc_enqueue_cmd();
 }
 
-static void TimerCB_Connect(unsigned long arg)
+static void TimerCB_Connect(struct timer_list *t)
 {
-   struct wilc_vif *vif = (struct wilc_vif *)arg;
+   struct host_if_drv *hif_drv = from_timer(hif_drv, t,
+ connect_timer);
+   struct wilc_vif *vif = hif_drv->connect_timer_vif;
struct host_if_msg msg;
 
memset(, 0, sizeof(struct host_if_msg));
@@ -3040,7 +3046,7 @@ int wilc_set_join_req(struct wilc_vif *vif, u8 *bssid, 
const u8 *ssid,
return -EFAULT;
}
 
-   hif_drv->connect_timer.data = (unsigned long)vif;
+   hif_drv->connect_timer_vif = vif;
mod_timer(_drv->connect_timer,
  jiffies + msecs_to_jiffies(HOST_IF_CONNECT_TIMEOUT));
 
@@ -3283,7 +3289,7 @@ int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 
scan_type,
return -EINVAL;
}
 
-   hif_drv->scan_timer.data = (unsigned long)vif;
+   hif_drv->scan_timer_vif = vif;
mod_timer(_drv->scan_timer,
  jiffies + msecs_to_jiffies(HOST_IF_SCAN_TIMEOUT));
 
@@ -3309,9 +3315,9 @@ int wilc_hif_set_cfg(struct wilc_vif *vif,
return wilc_enqueue_cmd();
 }
 
-static void GetPeriodicRSSI(unsigned long arg)
+static void GetPeriodicRSSI(struct timer_list *unused)
 {
-   struct wilc_vif *vif = (struct wilc_vif *)arg;
+   struct wilc_vif *vif = periodic_rssi_vif;
 
if (!vif->hif_drv) {
netdev_err(vif->ndev, "Driver handler is NULL\n");
@@ -3321,7 +3327,6 @@ static void GetPeriodicRSSI(unsigned long arg)
if (vif->hif_drv->hif_state == HOST_IF_CONNECTED)
wilc_get_statistics(vif, >wilc->dummy_statistics);
 
-   periodic_rssi.data = (unsigned long)vif;
mod_timer(_rssi, jiffies + msecs_to_jiffies(5000));
 }
 
@@ -3374,14 +3379,14 @@ int wilc_init(struct net_device *dev, struct 
host_if_drv **hif_drv_handler)
goto _fail_;
}
 
-   setup_timer(_rssi, GetPeriodicRSSI,
-   (unsigned long)vif);
+   periodic_rssi_vif = 

Re: [PATCH] bcma: use bcma_debug and pr_cont in MIPS driver

[Hauke Mehrtens]

On 10/16/2017 02:54 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Using bcma_debug gives a device-specific prefix for messages and pr_cont
> is a common helper for continuing a line.
> 
> Signed-off-by: Rafał Miłecki 

Acked-By: Hauke Mehrtens 

> ---
>  drivers/bcma/driver_mips.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
> index 89af807cf29c..5904ef1aa624 100644
> --- a/drivers/bcma/driver_mips.c
> +++ b/drivers/bcma/driver_mips.c
> @@ -184,10 +184,11 @@ static void bcma_core_mips_print_irq(struct bcma_device 
> *dev, unsigned int irq)
>  {
>   int i;
>   static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
> - printk(KERN_DEBUG KBUILD_MODNAME ": core 0x%04x, irq :", dev->id.id);
> +
> + bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
>   for (i = 0; i <= 6; i++)
> - printk(" %s%s", irq_name[i], i == irq ? "*" : " ");
> - printk("\n");
> + pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
> + pr_cont("\n");
>  }
>  
>  static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> 

Re: [PATCH 0/8] qtnfmac: misc small features and fixes

[Igor Mitsyanko]

On 10/15/2017 01:53 PM, Sergey Matyukevich wrote:

Hello Kalle, Igor, and all

This patch series includes a number of small features and fixes
for qtnfmac driver.

Igor Mitsyanko (1):
  qtnfmac: advertise support of inactivity timeout

Sergey Matyukevich (4):
  qtnfmac: modify full Tx queue error reporting
  qtnfmac: enable registration of more mgmt frames
  qtnfmac: drop nonexistent function declaration
  qtnfmac: modify full Tx queue recovery


  drivers/net/wireless/quantenna/qtnfmac/cfg80211.c|   17 
+++--
  drivers/net/wireless/quantenna/qtnfmac/commands.c|5 +++--
  drivers/net/wireless/quantenna/qtnfmac/core.c|   27 
+++
  drivers/net/wireless/quantenna/qtnfmac/core.h|4 +---
  drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c  |   15 
+--
  drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h |1 +
  drivers/net/wireless/quantenna/qtnfmac/qlink.h   |   11 
++-
  7 files changed, 66 insertions(+), 14 deletions(-)



Reviewed-by: Igor Mitsyanko 

Re: [PATCH] iw: add command to register and capture mgmt frames

[Igor Mitsyanko]

On 10/16/2017 02:24 AM, Johannes Berg wrote:



Right, and I didn't originally see the patch as such, just that the
discussion (and in particular Julian's suggestion) veered off in that
direction.


Nevertheless in certain cases it is handy to dump selected types of
mgmt frames while system is up and running without adding the whole
monitor overhead. The idea was that NL80211_CMD_REGISTER_FRAME and iw
are the right tools for that task. Anyway, iw is something like a
'swiss-army-knife' tool for various tasks related to
mac80211/cfg80211 reporting and troubleshooting.


I'd see this particular feature in iw more as a way to debug the
registrations, but whatever you ultimately want to use it for I neither
can nor want to control :-)



Maybe we could add an additional nl attribute to 
NL80211_CMD_REGISTER_FRAME command to allow applications to advertise 
what is their intention, something like NL80211_ATTR_MGMT_LISTENER_TYPE. 
Only allow to register more then one listener if it explicitly specifies 
that it will not try to answer (TYPE_LISTEN_ONLY or smth like that).

This will preserve behavior for existing userspace.

[PATCH 2/2] mac80211: Add airtime accounting and scheduling to TXQs

[Toke Høiland-Jørgensen]

This adds airtime accounting and scheduling to the mac80211 TXQ scheduler. A new
hardware flag, AIRTIME_ACCOUNTING, is added that drivers can set if they support
reporting airtime usage of transmissions. When this flag is set, mac80211 will
expect the actual airtime usage to be reported in the tx_time and rx_time fields
of the respective status structs.

When airtime information is present, mac80211 will schedule TXQs (through
ieee80211_next_txq()) in a way that enforces airtime fairness between active
stations. This scheduling works the same way as the ath9k in-driver airtime
fairness scheduling, which is then removed.

Only ath9k currently sets the AIRTIME_ACCOUNTING flag.

Signed-off-by: Toke Høiland-Jørgensen 
---
Changes since the RFC:

- Don't try to calculate airtime usage in mac80211; instead, add a field to
  struct ieee80211_rx_status for the driver to fill in.
- Fold ath9k patch into this patch, and remove all the airtime bits from
  ath9k apart from the actual airtime accounting.
- Feature parity with the ath9k scheduler (in particular, the old/new
  station optimisation is retained).
- Add explicit hardware flag for the driver to signal that it supports
  airtime accounting and wants the scheduling.
- This has actually been tested... :)

 drivers/net/wireless/ath/ath9k/ath9k.h |  7 +---
 drivers/net/wireless/ath/ath9k/debug.h |  8 -
 drivers/net/wireless/ath/ath9k/debug_sta.c | 54 --
 drivers/net/wireless/ath/ath9k/init.c  |  4 +--
 drivers/net/wireless/ath/ath9k/recv.c  | 11 ++
 drivers/net/wireless/ath/ath9k/xmit.c  | 21 
 include/net/mac80211.h |  6 
 net/mac80211/debugfs.c |  1 +
 net/mac80211/debugfs_sta.c | 29 
 net/mac80211/ieee80211_i.h |  6 +++-
 net/mac80211/main.c|  3 +-
 net/mac80211/rx.c  |  9 +
 net/mac80211/sta_info.c|  2 ++
 net/mac80211/sta_info.h|  7 
 net/mac80211/status.c  | 15 +
 net/mac80211/tx.c  | 28 +---
 16 files changed, 112 insertions(+), 99 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index f6c53df78856..f6e8f9b1b984 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -112,8 +112,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct 
ath_descdma *dd,
 #define ATH_TXFIFO_DEPTH   8
 #define ATH_TX_ERROR   0x01
 
-#define ATH_AIRTIME_QUANTUM300 /* usec */
-
 /* Stop tx traffic 1ms before the GO goes away */
 #define ATH_P2P_PS_STOP_TIME   1000
 
@@ -215,6 +213,7 @@ struct ath_buf_state {
bool stale;
u16 seqno;
unsigned long bfs_paprd_timestamp;
+   u32 airtime;
 };
 
 struct ath_buf {
@@ -262,12 +261,9 @@ struct ath_node {
 
bool sleeping;
bool no_ps_filter;
-   s64 airtime_deficit[IEEE80211_NUM_ACS];
-   u32 airtime_rx_start;
 
 #ifdef CONFIG_ATH9K_STATION_STATISTICS
struct ath_rx_rate_stats rx_rate_stats;
-   struct ath_airtime_stats airtime_stats;
 #endif
u8 key_idx[4];
 
@@ -986,7 +982,6 @@ void ath_ant_comb_scan(struct ath_softc *sc, struct 
ath_rx_status *rs);
 
 #define AIRTIME_USE_TX BIT(0)
 #define AIRTIME_USE_RX BIT(1)
-#define AIRTIME_USE_NEW_QUEUES BIT(2)
 #define AIRTIME_ACTIVE(flags) (!!(flags & (AIRTIME_USE_TX|AIRTIME_USE_RX)))
 
 struct ath_softc {
diff --git a/drivers/net/wireless/ath/ath9k/debug.h 
b/drivers/net/wireless/ath/ath9k/debug.h
index 249f8141cd00..559d9628f280 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -319,20 +319,12 @@ ath9k_debug_sync_cause(struct ath_softc *sc, u32 
sync_cause)
 void ath_debug_rate_stats(struct ath_softc *sc,
  struct ath_rx_status *rs,
  struct sk_buff *skb);
-void ath_debug_airtime(struct ath_softc *sc,
-  struct ath_node *an,
-  u32 rx, u32 tx);
 #else
 static inline void ath_debug_rate_stats(struct ath_softc *sc,
struct ath_rx_status *rs,
struct sk_buff *skb)
 {
 }
-static inline void ath_debug_airtime(struct ath_softc *sc,
- struct ath_node *an,
- u32 rx, u32 tx)
-{
-}
 #endif /* CONFIG_ATH9K_STATION_STATISTICS */
 
 #endif /* DEBUG_H */
diff --git a/drivers/net/wireless/ath/ath9k/debug_sta.c 
b/drivers/net/wireless/ath/ath9k/debug_sta.c
index efc692ee67d4..89ba95287a8b 100644
--- a/drivers/net/wireless/ath/ath9k/debug_sta.c
+++ b/drivers/net/wireless/ath/ath9k/debug_sta.c
@@ -242,59 +242,6 @@ static const struct file_operations fops_node_recv = {
.llseek = default_llseek,
 

[PATCH 1/2] mac80211: Add TXQ scheduling API

[Toke Høiland-Jørgensen]

This adds an API to mac80211 to handle scheduling of TXQs and changes the
interface between driver and mac80211 for TXQ handling as follows:

- The wake_tx_queue callback interface no longer includes the TXQ. Instead, the
  driver is expected to retrieve that from ieee80211_next_txq()

- Two new mac80211 functions are added: ieee80211_next_txq() and
  ieee80211_schedule_txq(). The former returns the next TXQ that should be
  scheduled, and is how the driver gets a queue to pull packets from. The latter
  is called internally by mac80211 to start scheduling a queue, and the driver
  is supposed to call it to re-schedule the TXQ after it is finished pulling
  packets from it (unless the queue emptied).

The ath9k and ath10k drivers are changed to use the new API.

Signed-off-by: Toke Høiland-Jørgensen 
---
Changes since the RFC:

- Don't call wake_tx_queue() if the TXQ was already scheduled.
- Fold ath9k and ath9k patches into this one.
- Don't mess with the powersave buffering behaviour, but keep the old
  driver behaviour for that (haven't tested with powersave enabled,
  though...).
- A couple of adjustments to ath9k behaviour after testing.

I don't have ath10k hardware handy, so this is untested on ath10k.
However, ath10k required way less surgery to support the new API than
ath9k did

 drivers/net/wireless/ath/ath10k/core.c |   2 -
 drivers/net/wireless/ath/ath10k/core.h |   3 -
 drivers/net/wireless/ath/ath10k/mac.c  |  54 +++--
 drivers/net/wireless/ath/ath9k/ath9k.h |   6 +-
 drivers/net/wireless/ath/ath9k/main.c  |   2 +-
 drivers/net/wireless/ath/ath9k/xmit.c  | 209 -
 include/net/mac80211.h |  35 +-
 net/mac80211/agg-tx.c  |   6 +-
 net/mac80211/driver-ops.h  |  12 +-
 net/mac80211/ieee80211_i.h |   4 +
 net/mac80211/main.c|   3 +
 net/mac80211/sta_info.c|   5 +-
 net/mac80211/trace.h   |  21 +---
 net/mac80211/tx.c  |  48 +++-
 14 files changed, 167 insertions(+), 243 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index a4f635820f35..759df3297d48 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2561,9 +2561,7 @@ struct ath10k *ath10k_core_create(size_t priv_size, 
struct device *dev,
 
mutex_init(>conf_mutex);
spin_lock_init(>data_lock);
-   spin_lock_init(>txqs_lock);
 
-   INIT_LIST_HEAD(>txqs);
INIT_LIST_HEAD(>peers);
init_waitqueue_head(>peer_mapping_wq);
init_waitqueue_head(>htt.empty_tx_wq);
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 949ebb3e967b..e7fc241addf6 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -892,10 +892,7 @@ struct ath10k {
 
/* protects shared structure data */
spinlock_t data_lock;
-   /* protects: ar->txqs, artxq->list */
-   spinlock_t txqs_lock;
 
-   struct list_head txqs;
struct list_head arvifs;
struct list_head peers;
struct ath10k_peer *peer_map[ATH10K_MAX_NUM_PEER_IDS];
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5683f1a5330e..43ea23af8255 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3825,7 +3825,6 @@ static void ath10k_mac_txq_init(struct ieee80211_txq *txq)
 
 static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
 {
-   struct ath10k_txq *artxq;
struct ath10k_skb_cb *cb;
struct sk_buff *msdu;
int msdu_id;
@@ -3833,12 +3832,6 @@ static void ath10k_mac_txq_unref(struct ath10k *ar, 
struct ieee80211_txq *txq)
if (!txq)
return;
 
-   artxq = (void *)txq->drv_priv;
-   spin_lock_bh(>txqs_lock);
-   if (!list_empty(>list))
-   list_del_init(>list);
-   spin_unlock_bh(>txqs_lock);
-
spin_lock_bh(>htt.tx_lock);
idr_for_each_entry(>htt.pending_tx, msdu, msdu_id) {
cb = ATH10K_SKB_CB(msdu);
@@ -3968,23 +3961,17 @@ int ath10k_mac_tx_push_txq(struct ieee80211_hw *hw,
 void ath10k_mac_tx_push_pending(struct ath10k *ar)
 {
struct ieee80211_hw *hw = ar->hw;
-   struct ieee80211_txq *txq;
-   struct ath10k_txq *artxq;
-   struct ath10k_txq *last;
+   struct ieee80211_txq *txq, *first = NULL;
int ret;
int max;
 
if (ar->htt.num_pending_tx >= (ar->htt.max_num_pending_tx / 2))
return;
 
-   spin_lock_bh(>txqs_lock);
rcu_read_lock();
 
-   last = list_last_entry(>txqs, struct ath10k_txq, list);
-   while (!list_empty(>txqs)) {
-   artxq = list_first_entry(>txqs, struct ath10k_txq, list);
-   txq = container_of((void *)artxq, 

[PATCH] netlink: fix netlink_ack() extack race

[Johannes Berg]

From: Johannes Berg 

It seems that it's possible to toggle NETLINK_F_EXT_ACK
through setsockopt() while another thread/CPU is building
a message inside netlink_ack(), which could then trigger
the WARN_ON()s I added since if it goes from being turned
off to being turned on between allocating and filling the
message, the skb could end up being too small.

Avoid this whole situation by storing the value of this
flag in a separate variable and using that throughout the
function instead.

Fixes: 2d4bc93368f5 ("netlink: extended ACK reporting")
Signed-off-by: Johannes Berg 
---
 net/netlink/af_netlink.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 336d9c6dcad9..767c84e10e20 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2307,6 +2307,7 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr 
*nlh, int err,
size_t tlvlen = 0;
struct netlink_sock *nlk = nlk_sk(NETLINK_CB(in_skb).sk);
unsigned int flags = 0;
+   bool nlk_has_extack = nlk->flags & NETLINK_F_EXT_ACK;
 
/* Error messages get the original request appened, unless the user
 * requests to cap the error message, and get extra error data if
@@ -2317,7 +2318,7 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr 
*nlh, int err,
payload += nlmsg_len(nlh);
else
flags |= NLM_F_CAPPED;
-   if (nlk->flags & NETLINK_F_EXT_ACK && extack) {
+   if (nlk_has_extack && extack) {
if (extack->_msg)
tlvlen += nla_total_size(strlen(extack->_msg) + 
1);
if (extack->bad_attr)
@@ -2326,8 +2327,7 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr 
*nlh, int err,
} else {
flags |= NLM_F_CAPPED;
 
-   if (nlk->flags & NETLINK_F_EXT_ACK &&
-   extack && extack->cookie_len)
+   if (nlk_has_extack && extack && extack->cookie_len)
tlvlen += nla_total_size(extack->cookie_len);
}
 
@@ -2347,7 +2347,7 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr 
*nlh, int err,
errmsg->error = err;
memcpy(>msg, nlh, payload > sizeof(*errmsg) ? nlh->nlmsg_len : 
sizeof(*nlh));
 
-   if (nlk->flags & NETLINK_F_EXT_ACK && extack) {
+   if (nlk_has_extack && extack) {
if (err) {
if (extack->_msg)
WARN_ON(nla_put_string(skb, NLMSGERR_ATTR_MSG,
-- 
2.14.2

[PATCH] fq_impl: Properly enforce memory limit

[Toke Høiland-Jørgensen]

The fq structure would fail to properly enforce the memory limit in the case
where the packet being enqueued was bigger than the packet being removed to
bring the memory usage down. So keep dropping packets until the memory usage is
back below the limit. Also, fix the statistics for memory limit violations.

Signed-off-by: Toke Høiland-Jørgensen 
---
 include/net/fq_impl.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/net/fq_impl.h b/include/net/fq_impl.h
index 4e6131cd3f43..ac1a2317941e 100644
--- a/include/net/fq_impl.h
+++ b/include/net/fq_impl.h
@@ -146,6 +146,7 @@ static void fq_tin_enqueue(struct fq *fq,
   fq_flow_get_default_t get_default_func)
 {
struct fq_flow *flow;
+   bool oom;
 
lockdep_assert_held(>lock);
 
@@ -167,8 +168,8 @@ static void fq_tin_enqueue(struct fq *fq,
}
 
__skb_queue_tail(>queue, skb);
-
-   if (fq->backlog > fq->limit || fq->memory_usage > fq->memory_limit) {
+   oom = (fq->memory_usage > fq->memory_limit);
+   while (fq->backlog > fq->limit || oom) {
flow = list_first_entry_or_null(>backlogs,
struct fq_flow,
backlogchain);
@@ -183,8 +184,10 @@ static void fq_tin_enqueue(struct fq *fq,
 
flow->tin->overlimit++;
fq->overlimit++;
-   if (fq->memory_usage > fq->memory_limit)
+   if (oom) {
fq->overmemory++;
+   oom = (fq->memory_usage > fq->memory_limit);
+   }
}
 }
 
-- 
2.14.2

[PATCH] netlink: use NETLINK_CB(in_skb).sk instead of looking it up

[Johannes Berg]

From: Johannes Berg 

When netlink_ack() reports an allocation error to the sending
socket, there's no need to look up the sending socket since
it's available in the SKB's CB. Use that instead of going to
the trouble of looking it up.

Note that the pointer is only available since Eric Biederman's
commit 3fbc290540a1 ("netlink: Make the sending netlink socket availabe in 
NETLINK_CB")
which is far newer than the original lookup code (Oct 2003)
(though the field was called 'ssk' in that commit and only got
renamed to 'sk' later, I'd actually argue 'ssk' was better - or
perhaps it should've been 'source_sk' - since there are so many
different 'sk's involved.)

Signed-off-by: Johannes Berg 
---
 net/netlink/af_netlink.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index f34750691c5c..336d9c6dcad9 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2336,16 +2336,8 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr 
*nlh, int err,
 
skb = nlmsg_new(payload + tlvlen, GFP_KERNEL);
if (!skb) {
-   struct sock *sk;
-
-   sk = netlink_lookup(sock_net(in_skb->sk),
-   in_skb->sk->sk_protocol,
-   NETLINK_CB(in_skb).portid);
-   if (sk) {
-   sk->sk_err = ENOBUFS;
-   sk->sk_error_report(sk);
-   sock_put(sk);
-   }
+   NETLINK_CB(in_skb).sk->sk_err = ENOBUFS;
+   NETLINK_CB(in_skb).sk->sk_error_report(NETLINK_CB(in_skb).sk);
return;
}
 
-- 
2.14.2

pull-request: mac80211 2017-10-16

[Johannes Berg]

Hi Dave,

Here's a fix, for a small part of the "KRACK" announced today
(krackattacks.com).

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit c0576e3975084d4699b7bfef578613fb8e1144f6:

  net: call cgroup_sk_alloc() earlier in sk_clone_lock() (2017-10-10 20:24:29 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2017-10-16

for you to fetch changes up to fdf7cb4185b60c68e1a75e61691c4afdc15dea0e:

  mac80211: accept key reinstall without changing anything (2017-10-16 13:02:03 
+0200)


Just a single fix, for a WoWLAN-related part of CVE-2017-13080.


Johannes Berg (1):
  mac80211: accept key reinstall without changing anything

 net/mac80211/key.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

Re: Two rtlwifi drivers?

[Kalle Valo]

Hi PK,

you got good answers already so only short reply from me:

Pkshih  writes:

> 3) Coming drivers -- rtl8723de and rtl8821ce
>We're developing the two drivers, and rtl8723de and rtl8821ce will
>be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on
>rtl8822be that in staging now, so the line of code will be fewer.
>The new files will be a new IC folder and IC supported files of 
>three modules that btcoexist, phydm and halmac. Could I submit
>them to wirless tree when they're ready?

My recommendation is to avoid accumulating patches at all cost and start
submitting them as soon as you can. This way you get patches committed
much more smoother. So do not wait until _all_ patches are ready,
instead start submitting patches as soon as you have _some_ patches
ready. In other words, keep the delta between mainline and your
not-yet-submitted patches as small as possible.

And the patches don't need to be bug free as you can always fix bugs
later. Just mention in the commit logs that this is preparation for some
new feature and not fully tested yet. We do that all the time, for
example Intel's iwlwifi has support for hardware which have not reached
customers yet.

> On the way, I'll attend netdev workshop in Korea, so we can meet there
> if you attend too.

I'm also attending Netdev 2.2, looking forward to meeting you there.

-- 
Kalle Valo

Re: Two rtlwifi drivers?

[Oleksij Rempel]

Am 16.10.2017 um 15:07 schrieb Kalle Valo:
> Oleksij Rempel  writes:
> 
>>> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I 
>>>plan to fix them after rtl8723de and rtl8821ce. Because the drivers
>>>are developing, the changes will make us hard to integrate. However,
>>>I don't have plan to process the magic numbers in the module phydm,
>>>because the most of BB/RF registers contain many functions. And
>>>it doesn't have a register name but a bit field name instead.
>>>Our BB team guys say the use of enumeration or defined name will
>>>be unreadable, and the name is meaningless for most people.
>>
>> Experience with ath9k driver showed, that development was kind of
>> balanced between two groups, QCA and Community (Other companies,
>> researches, education and so on.). Saying: "you will not understand it
>> any way" is nor really helpful :)
>> Please don't repeat bad experience of Broadcom.
> 
> I agree with Oleksij here, but I want to still point out that there are
> cases when using magic numbers are ok, for example look at
> ar5008_initvals.h from ath9k. So it depends on case by case.

Beside. It is probably offtopic. I assume this initvals related to BB.
Is it possible to force a 802.11n controller to work in 802.11b mode? I
can image, it should be possible by reconfiguring BB. Correct?
-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Two rtlwifi drivers?

[Kalle Valo]

Oleksij Rempel  writes:

>> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I 
>>plan to fix them after rtl8723de and rtl8821ce. Because the drivers
>>are developing, the changes will make us hard to integrate. However,
>>I don't have plan to process the magic numbers in the module phydm,
>>because the most of BB/RF registers contain many functions. And
>>it doesn't have a register name but a bit field name instead.
>>Our BB team guys say the use of enumeration or defined name will
>>be unreadable, and the name is meaningless for most people.
>
> Experience with ath9k driver showed, that development was kind of
> balanced between two groups, QCA and Community (Other companies,
> researches, education and so on.). Saying: "you will not understand it
> any way" is nor really helpful :)
> Please don't repeat bad experience of Broadcom.

I agree with Oleksij here, but I want to still point out that there are
cases when using magic numbers are ok, for example look at
ar5008_initvals.h from ath9k. So it depends on case by case.

-- 
Kalle Valo

Re: Two rtlwifi drivers?

[Kalle Valo]

Dan Carpenter  writes:

> On Mon, Oct 16, 2017 at 02:41:38AM +, Pkshih wrote:
>> 2) The rtlwifi in staging
>>In staging, the module phydm v13 contains bugs, so I want to upgrade
>>to v21 (Realtek internal version number). This upgrade contains a
>>big patch that the difference between v13 and v21, and there are 
>>40+ patches to support this upgrade. I have three options, and
>>I want to know which one is prefer.
>
> We can't discuss patches we haven't seend.  Please just send them right
> away without any delay to both lists, and we can decide from there.
>
> 40 patches is a medium size set, patch that we are used to dealing with
> every day.

I review every patch I commit and 40 patches is just pure pain to dig
through. So when submitting patches to me please keep the size more
reasonable, like 10-12 patches per set. I think Dave also has a similar
rule for net patches.

I wrote a FAQ entry about this:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#too_many_patches

-- 
Kalle Valo

Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi

[Kalle Valo]

icen...@aosc.io writes:

> > > Like I asked already last time, AFAICS there is no upstream xr819
> > > wireless driver in drivers/net/wireless directory. Do we still
 accept
> > > bindings like this for out-of-tree drivers?
> >
> > See esp8089.
> >
> > There's also no in-tree driver for it.
>
> The question is whether we should. The above might be a precedent,
 but it
> may not necessarily be the way to go. The commit message for esp8089
 seems
> to hint that there is intent to have an in-tree driver:
>
> """
> Note that at this point there only is an out of tree driver for
 this
> hardware, there is no clear timeline / path for merging this.
 Still
> I believe it would be good to specify the binding for this in
 tree
> now, so that any future migration to an in tree driver will not
 cause
> compatiblity issues.
>
> Cc: Icenowy Zheng 
> Signed-off-by: Hans de Goede 
> Signed-off-by: Rob Herring 
> """
>
> Regardless the bindings are in principle independent of the kernel
 and just
> describing hardware. I think there have been discussions to move the
> bindings to their own repository, but apparently it was decided
 otherwise.

 Yeah, I guess especially how it could be merged with the cw1200
 driver
 would be very relevant to that commit log.
>>>
>>> The cw1200 driver seems to still have some legacy platform
>>> data. Maybe they should also be convert to DT.
>>> (Or maybe compatible = "allwinner,xr819" is enough, as
>>> xr819 is a specified variant of cw1200 family)
>>
>> Ah, so the upstream cw1200 driver supports xr819? Has anyone tested
>> that? Or does cw1200 more changes than just adding the DT support?
>
> The support of XR819 in CW1200 driver is far more difficult than I
> imagined -- the codedrop used in the mainlined CW1200 driver seems to
> be so old that it's before XR819 (which seems to be based on CW1160),
> and there's a large number of problems to adapt it to a modern CW1200
> variant.
>
> P.S. could you apply this device tree binding patch now?

As I haven't seen any consensus that applying bindings document for
out-of-tree drivers is ok so at least I'm not taking this. Though not
sure what DT maintainers are planning to do.

-- 
Kalle Valo

[PATCH] bcma: use bcma_debug and pr_cont in MIPS driver

[Rafał Miłecki]

From: Rafał Miłecki 

Using bcma_debug gives a device-specific prefix for messages and pr_cont
is a common helper for continuing a line.

Signed-off-by: Rafał Miłecki 
---
 drivers/bcma/driver_mips.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index 89af807cf29c..5904ef1aa624 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -184,10 +184,11 @@ static void bcma_core_mips_print_irq(struct bcma_device 
*dev, unsigned int irq)
 {
int i;
static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
-   printk(KERN_DEBUG KBUILD_MODNAME ": core 0x%04x, irq :", dev->id.id);
+
+   bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
for (i = 0; i <= 6; i++)
-   printk(" %s%s", irq_name[i], i == irq ? "*" : " ");
-   printk("\n");
+   pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
+   pr_cont("\n");
 }
 
 static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
-- 
2.11.0

Re: rc2-next-20170929: wireless down, won't come up

[Stanislaw Gruszka]

On Mon, Oct 16, 2017 at 02:24:56PM +0200, Pavel Machek wrote:
> So far it happened once... so I don't know about reproducibility. And
> I'm not even sure if I'm using iwlegacy driver. Am I?

iwl3945 (and iwl4965) are iwlegacy drivers.

Regards
Stanislaw

Re: rc2-next-20170929: wireless down, won't come up

[Pavel Machek]

On Mon 2017-10-16 12:51:55, Stanislaw Gruszka wrote:
> Hi
> 
> Site note: Intel folks do not support iwlegacy, I removed them from CC.
> 
> On Mon, Oct 16, 2017 at 12:27:45PM +0200, Pavel Machek wrote:
> > > In -next... after few days of usage with suspend and resume cycles,
> > > wifi failed on thinkpad x60. I have not seen this in years...
> 
> > > Any ideas?
> 
> We do not have any recent iwlegacy changes except cosmetic
> ones, so this problem most likely is mac80211, pci or other
> subsystem issue
> 
> > Suspend+resume fixed the problem.
> 
> It is not reproducible? If so, I think it will not be 
> easy to identify the issue.

So far it happened once... so I don't know about reproducibility. And
I'm not even sure if I'm using iwlegacy driver. Am I?

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index

[Dmitry Vyukov]

On Mon, Oct 16, 2017 at 12:27 PM, Kalle Valo  wrote:
> Dmitry Vyukov  writes:
>
>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka  
>> wrote:
>>> Hi
>>>
>>> On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
 I've got the following report while fuzzing the kernel with syzkaller.

 On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).

 I'm not sure whether this is a bug in the driver, or just a way to
 report misbehaving device. In the latter case this shouldn't be a
 WARN() call, since WARN() means bug in the kernel.
>>>
>>> This is about wrong EEPROM, which reported 3 tx streams on
>>> non 3 antenna device. I think WARN() is justified and thanks
>>> to the call trace I was actually able to to understand what
>>> happened.
>>>
>>> In general I do not think WARN() only means a kernel bug, it
>>> can be F/W or H/W bug too.
>>
>> Hi Stanislaw,
>>
>> Printing messages is fine. Printing stacks is fine. Just please make
>> them distinguishable from kernel bugs and don't kill the whole
>> possibility of automated Linux kernel testing. That's an important
>> capability.
>
> Not really following you. Are you saying that using WARN() prevents
> automated Linux kernel testing?


Absence of a way to understand when there is something wrong with
kernel (something to notify kernel developers about) is the problem.

Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index

[Dmitry Vyukov]

On Mon, Oct 16, 2017 at 11:40 AM, Stanislaw Gruszka  wrote:
> Hi Dmitry
>
> On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka  
>> wrote:
>> > Hi
>> >
>> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>> >> I've got the following report while fuzzing the kernel with syzkaller.
>> >>
>> >> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>> >>
>> >> I'm not sure whether this is a bug in the driver, or just a way to
>> >> report misbehaving device. In the latter case this shouldn't be a
>> >> WARN() call, since WARN() means bug in the kernel.
>> >
>> > This is about wrong EEPROM, which reported 3 tx streams on
>> > non 3 antenna device. I think WARN() is justified and thanks
>> > to the call trace I was actually able to to understand what
>> > happened.
>> >
>> > In general I do not think WARN() only means a kernel bug, it
>> > can be F/W or H/W bug too.
>>
>> Hi Stanislaw,
>>
>> Printing messages is fine. Printing stacks is fine. Just please make
>> them distinguishable from kernel bugs and don't kill the whole
>> possibility of automated Linux kernel testing. That's an important
>> capability.
>
> We do not distinguish between bugs and other problems when WARN() is
> used in (wireless) drivers, what I think is correct, taking comment from
> include/asm-generic/bug.h :
>
> /*
>  * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
>  * significant issues that need prompt attention if they should ever
>  * appear at runtime.  Use the versions with printk format strings
>  * to provide better diagnostics.
>  */
>
> Historically we have BUG() to mark the bugs, but usage if it is not
> recommended as it can kill the system, so for anything that can
> be recovered in runtime - WARN() is recommended.
>
> Perhaps we can introduce another helper like PROBLEM() for marking
> situations when something is wrong, but it is not a bug. However I'm
> not even sure at what extent it can be used, since for many cases
> if not the most, driver author can not tell apriori if the problem
> is a bug in the driver or HW/FW misbehaviour (or maybe particular
> issue can happen because of both).

I will write a separate email to LKML.

Thanks

Re: rc2-next-20170929: wireless down, won't come up

[Stanislaw Gruszka]

Hi

Site note: Intel folks do not support iwlegacy, I removed them from CC.

On Mon, Oct 16, 2017 at 12:27:45PM +0200, Pavel Machek wrote:
> > In -next... after few days of usage with suspend and resume cycles,
> > wifi failed on thinkpad x60. I have not seen this in years...

> > Any ideas?

We do not have any recent iwlegacy changes except cosmetic
ones, so this problem most likely is mac80211, pci or other
subsystem issue

> Suspend+resume fixed the problem.

It is not reproducible? If so, I think it will not be 
easy to identify the issue.

Thanks
Stanislaw

Re: rc2-next-20170929: wireless down, won't come up

[Pavel Machek]

Hi!

> In -next... after few days of usage with suspend and resume cycles,
> wifi failed on thinkpad x60. I have not seen this in years...
> 
> [28140.944044] CE: hpet increased min_delta_ns to 20115 nsec
> [28174.048418] iwl3945 :03:00.0: Error sending C_RATE_SCALE: time
> out after 500ms.
> [28174.048430] iwl3945 :03:00.0: Error setting HW rate table:
> FF92
> [28174.186576] iwl3945 :03:00.0: Error: Response NULL in
> 'C_ADD_STA'
> [28174.186593] iwl3945 :03:00.0: Adding station 00:00:00:00:00:01
> failed.
> [28174.206312] iwl3945 :03:00.0: Error: Response NULL in
> 'C_ADD_STA'
> [28174.206326] iwl3945 :03:00.0: Adding station ff:ff:ff:ff:ff:ff
> failed.
> [30306.599241] wlan0: deauthenticating from 00:00:00:00:00:01 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [30306.624302] iwl3945 :03:00.0: Error removing station
> 00:00:00:00:00:01
> [30309.055257] wlan0: authenticate with 00:00:00:00:00:01
> [30309.055631] wlan0: send auth to 00:00:00:00:00:01 (try 1/3)
> [30309.256142] wlan0: send auth to 00:00:00:00:00:01 (try 2/3)
> [30309.460114] wlan0: send auth to 00:00:00:00:00:01 (try 3/3)
> [30309.664117] wlan0: authentication with 00:00:00:00:00:01 timed out
> 
> (Yes, my AP has funny hw address; but its other hw address fails, too).
> 
> Any ideas?

Suspend+resume fixed the problem.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index

[Kalle Valo]

Dmitry Vyukov  writes:

> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka  
> wrote:
>> Hi
>>
>> On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>>> I've got the following report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>>>
>>> I'm not sure whether this is a bug in the driver, or just a way to
>>> report misbehaving device. In the latter case this shouldn't be a
>>> WARN() call, since WARN() means bug in the kernel.
>>
>> This is about wrong EEPROM, which reported 3 tx streams on
>> non 3 antenna device. I think WARN() is justified and thanks
>> to the call trace I was actually able to to understand what
>> happened.
>>
>> In general I do not think WARN() only means a kernel bug, it
>> can be F/W or H/W bug too.
>
> Hi Stanislaw,
>
> Printing messages is fine. Printing stacks is fine. Just please make
> them distinguishable from kernel bugs and don't kill the whole
> possibility of automated Linux kernel testing. That's an important
> capability.

Not really following you. Are you saying that using WARN() prevents
automated Linux kernel testing?

-- 
Kalle Valo

Re: [PATCH] iw: add command to register and capture mgmt frames

[Sergey Matyukevich]

> > Let me know if you have any objections to implementation details :)
> 
> Yeah, I'll need to review it, just need a bit more time for that.
> 
> > Then I will resubmit it addressing all the comments. Besides I am
> > going to change command name from 'capture' to 'dump' to avoid
> > confusion. Finally, I will update commit message adding information
> > about unicast nature of those registrations.
> 
> Sounds good :)
> 
> Do you want to resend before I review it?

No, I will wait for code reviews, then I will resend the updated
patch including changes for all the upcoming comments.

Regards,
Sergey

Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index

[Stanislaw Gruszka]

Hi Dmitry

On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka  
> wrote:
> > Hi
> >
> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
> >> I've got the following report while fuzzing the kernel with syzkaller.
> >>
> >> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
> >>
> >> I'm not sure whether this is a bug in the driver, or just a way to
> >> report misbehaving device. In the latter case this shouldn't be a
> >> WARN() call, since WARN() means bug in the kernel.
> >
> > This is about wrong EEPROM, which reported 3 tx streams on
> > non 3 antenna device. I think WARN() is justified and thanks
> > to the call trace I was actually able to to understand what
> > happened.
> >
> > In general I do not think WARN() only means a kernel bug, it
> > can be F/W or H/W bug too.
> 
> Hi Stanislaw,
> 
> Printing messages is fine. Printing stacks is fine. Just please make
> them distinguishable from kernel bugs and don't kill the whole
> possibility of automated Linux kernel testing. That's an important
> capability.

We do not distinguish between bugs and other problems when WARN() is
used in (wireless) drivers, what I think is correct, taking comment from
include/asm-generic/bug.h :

/*
 * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
 * significant issues that need prompt attention if they should ever
 * appear at runtime.  Use the versions with printk format strings
 * to provide better diagnostics.
 */

Historically we have BUG() to mark the bugs, but usage if it is not
recommended as it can kill the system, so for anything that can
be recovered in runtime - WARN() is recommended.

Perhaps we can introduce another helper like PROBLEM() for marking
situations when something is wrong, but it is not a bug. However I'm
not even sure at what extent it can be used, since for many cases
if not the most, driver author can not tell apriori if the problem
is a bug in the driver or HW/FW misbehaviour (or maybe particular
issue can happen because of both).

Thanks
Stanislaw

Re: [PATCH] iw: add command to register and capture mgmt frames

[Johannes Berg]

On Mon, 2017-10-16 at 11:48 +0300, Sergey Matyukevich wrote:
> 
> Well, monitor mode support in qtnfmac is in our todo list for sure. 

Sure. I'm saying you don't really need full monitor support at all,
just a pure software construct for this.

> Meanwhile the purpose of the patch was not to implement a full-
> fledged mgmt packet capture. We have monitor mode and mature capture
> tools for that.

Right, and I didn't originally see the patch as such, just that the
discussion (and in particular Julian's suggestion) veered off in that
direction.

> Nevertheless in certain cases it is handy to dump selected types of
> mgmt frames while system is up and running without adding the whole
> monitor overhead. The idea was that NL80211_CMD_REGISTER_FRAME and iw
> are the right tools for that task. Anyway, iw is something like a
> 'swiss-army-knife' tool for various tasks related to
> mac80211/cfg80211 reporting and troubleshooting.

I'd see this particular feature in iw more as a way to debug the
registrations, but whatever you ultimately want to use it for I neither
can nor want to control :-)

> Let me know if you have any objections to implementation details :)

Yeah, I'll need to review it, just need a bit more time for that.

> Then I will resubmit it addressing all the comments. Besides I am
> going to change command name from 'capture' to 'dump' to avoid
> confusion. Finally, I will update commit message adding information
> about unicast nature of those registrations.

Sounds good :)

Do you want to resend before I review it?

johannes

rc2-next-20170929: wireless down, won't come up

[Pavel Machek]

Hi!

In -next... after few days of usage with suspend and resume cycles,
wifi failed on thinkpad x60. I have not seen this in years...

[28140.944044] CE: hpet increased min_delta_ns to 20115 nsec
[28174.048418] iwl3945 :03:00.0: Error sending C_RATE_SCALE: time
out after 500ms.
[28174.048430] iwl3945 :03:00.0: Error setting HW rate table:
FF92
[28174.186576] iwl3945 :03:00.0: Error: Response NULL in
'C_ADD_STA'
[28174.186593] iwl3945 :03:00.0: Adding station 00:00:00:00:00:01
failed.
[28174.206312] iwl3945 :03:00.0: Error: Response NULL in
'C_ADD_STA'
[28174.206326] iwl3945 :03:00.0: Adding station ff:ff:ff:ff:ff:ff
failed.
[30306.599241] wlan0: deauthenticating from 00:00:00:00:00:01 by local
choice (Reason: 3=DEAUTH_LEAVING)
[30306.624302] iwl3945 :03:00.0: Error removing station
00:00:00:00:00:01
[30309.055257] wlan0: authenticate with 00:00:00:00:00:01
[30309.055631] wlan0: send auth to 00:00:00:00:00:01 (try 1/3)
[30309.256142] wlan0: send auth to 00:00:00:00:00:01 (try 2/3)
[30309.460114] wlan0: send auth to 00:00:00:00:00:01 (try 3/3)
[30309.664117] wlan0: authentication with 00:00:00:00:00:01 timed out

(Yes, my AP has funny hw address; but its other hw address fails, too).

Any ideas?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] mac80211: accept key reinstall without changing anything

[Johannes Berg]

From: Johannes Berg 

When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".

In particular, CVE-2017-13080 applies to GTK rekeying that
happened in firmware while the host is in D3, with the second
part of the attack being done after the host wakes up. In
this case, the wpa_supplicant mitigation isn't sufficient
since wpa_supplicant doesn't know the GTK material.

In case this happens, simply silently accept the new key
coming from userspace but don't take any action on it since
it's the same key; this keeps the PN counter intact.

Signed-off-by: Johannes Berg 
---
 net/mac80211/key.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index a98fc2b5e0dc..ae995c8480db 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -4,7 +4,7 @@
  * Copyright 2006-2007 Jiri Benc 
  * Copyright 2007-2008 Johannes Berg 
  * Copyright 2013-2014  Intel Mobile Communications GmbH
- * Copyright 2015  Intel Deutschland GmbH
+ * Copyright 2015-2017 Intel Deutschland GmbH
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -620,9 +620,6 @@ int ieee80211_key_link(struct ieee80211_key *key,
 
pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
idx = key->conf.keyidx;
-   key->local = sdata->local;
-   key->sdata = sdata;
-   key->sta = sta;
 
mutex_lock(>local->key_mtx);
 
@@ -633,6 +630,21 @@ int ieee80211_key_link(struct ieee80211_key *key,
else
old_key = key_mtx_dereference(sdata->local, sdata->keys[idx]);
 
+   /*
+* Silently accept key re-installation without really installing the
+* new version of the key to avoid nonce reuse or replay issues.
+*/
+   if (old_key && key->conf.keylen == old_key->conf.keylen &&
+   !memcmp(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+   ieee80211_key_free_unused(key);
+   ret = 0;
+   goto out;
+   }
+
+   key->local = sdata->local;
+   key->sdata = sdata;
+   key->sta = sta;
+
increment_tailroom_need_count(sdata);
 
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
@@ -648,6 +660,7 @@ int ieee80211_key_link(struct ieee80211_key *key,
ret = 0;
}
 
+ out:
mutex_unlock(>local->key_mtx);
 
return ret;
-- 
2.14.2

Re: [PATCH] iw: add command to register and capture mgmt frames

[Sergey Matyukevich]

Hello Johannes and all,

> So first, I'll say that I have no objection in principle to the patch,
> as a debugging aid.
> 
> However, the story is more complicated.
> 
> > IIUC tshark and other specific capture tools need wireless netdevice
> > to be in monitor mode.
> 
> This is correct, but shouldn't be a problem.
> 
> > This particular iw command is based on
> > NL80211_CMD_REGISTER_FRAME
> > and related cfg80211 ops. In fact, this command can be used to
> > subscribe
> > to mgmt frames when wireless device is up and running in AP or STA
> > mode.
> > That can be convenient for monitor and debug purposes. There is a
> > limitation though: currently cfg80211 core allows only one subscriber
> > for each particular frame/pattern.
> 
> If you're looking for a tool to actually do something like sniffer,
> this API isn't the right thing to do.
> 
> That's why I also don't think it should be added to tshark.
> 
> Remember that with the use of this API also come certain obligations.
> For example, if you subscribe to (certain) action frames and then don't
> actually process them as described by the spec, then the subscriber
> MUST generate responses with the 0x80 bit ORed into the action code,
> returning the frame as not understood. Clearly, this isn't something
> that iw does and can implement.
> 
> Additionally, as you noted, and it's for this exact reason because
> otherwise responsibilities wouldn't be clearly defined, there can only
> be a single subscriber to a certain set of frames, as specified by the
> subtype and match prefix, so using it as a type of sniffer or debug
> tool may affect other functional operation.
> 
> 
> In mac80211, it's _always_ possible to add a monitor interface, and
> given no special flags (which may or may not be supported by a given
> driver anyway) this monitor interface is a pure software construct and
> will in no way affect device operation - apart from sending all
> received frames to the monitor interface at the beginning of mac80211's
> operation.
> 
> I see no reason, other than needing a little bit of coding, that this
> couldn't similarly be supported in qtnfmac.

Well, monitor mode support in qtnfmac is in our todo list for sure. Meanwhile
the purpose of the patch was not to implement a full-fledged mgmt packet
capture. We have monitor mode and mature capture tools for that.

Nevertheless in certain cases it is handy to dump selected types of mgmt frames
while system is up and running without adding the whole monitor overhead. The
idea was that NL80211_CMD_REGISTER_FRAME and iw are the right tools for that
task. Anyway, iw is something like a 'swiss-army-knife' tool for various tasks
related to mac80211/cfg80211 reporting and troubleshooting.

Speaking of the patch, you mentioned that you have no objection in principle.
Let me know if you have any objections to implementation details :)
Then I will resubmit it addressing all the comments. Besides I am going
to change command name from 'capture' to 'dump' to avoid confusion.
Finally, I will update commit message adding information about unicast
nature of those registrations.

Regards,
Sergey

Re: Two rtlwifi drivers?

[Greg Kroah-Hartman]

On Mon, Oct 16, 2017 at 02:41:38AM +, Pkshih wrote:
> 
> 
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, October 12, 2017 6:35 PM
> > To: Kalle Valo
> > Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick 
> > Joarder;
> > de...@driverdev.osuosl.org; linux-wireless@vger.kernel.org; 
> > kernel-janit...@vger.kernel.org
> > Subject: Re: Two rtlwifi drivers?
> > 
> > On Thu, Oct 12, 2017 at 11:38:06AM +0300, Kalle Valo wrote:
> > > > So what to do?  Any ideas?  What makes your life easier?  You can just
> > > > ignore the staging tree, as it should not affect your portion of the
> > > > kernel at all, right?
> > >
> > > Yes, I automatically ignore anything staging related. But the problem is
> > > that we now have two drivers with the same name and people don't always
> > > remember to prefix the patch with "staging: ". So on a bad day I might
> > > accidentally apply a patch which was meant for your tree. Of course I
> > > immediately revert it as soon as I, or someone else, catches that but
> > > annoying still.
> > 
> > It doesn't bother me if you apply staging patches, I can handle the
> > merge issues :)
> > 
> > > I think we have two options here:
> > >
> > > 1) We set a deadline (like 12 months or something) for the
> > >drivers/staging/rtlwifi and after that you refuse to take any patches
> > >for it. Hopefully this makes it clear for everyone that this fork is
> > >just temporary. I think Larry is trying to do this, which is great.
> > 
> > Fine with me, if Larry is ok with it.
> > 
> > > 2) We move the whole rtlwifi driver to staging. A very bad option but
> > >still better than forking the drivers.
> > 
> > Ick, I don't want that to have to happen, that would not be good for the
> > users of other devices that the "real" rtlwifi driver supports.
> > 
> 
> Hi Larry, Kalle and Gerg,
> 
> This is Realtek engineer, PK. I appreciate your support to submit, review 
> and merge patch. Since I'm a Linux newbie, I'll describe the situation of 
> rtlwifi and need your suggestions.
> 
> 
> 1) New modules in rtlwifi
>We add two modules named phydm and halmac, when adding rtl8822be in 
>staging. The phydm is BB/RF related module containing the parameters
>and APIs of BB/RF, and a dynamic mechanism to adapt to different
>field environment. The halmac consists of MAC APIs.
>The two modules are used by many OSs, so '#ifdef', CamelCase and
>so on are existing in original files. Hence, we convert them to Linux 
>form by script, but it's not perfect. Do you have suggestion to deal
>with this problem?

Yes, use a script like you are doing, and then just work from the Linux
versions from then on.  Trying to do an OS independant layer almost
never works well over time, the only people that I have seen doing it
successfully is the ACPI core code, and for that, those developers do
have lots of scripts to turn their internal version into Linux-friendly
patches.

It takes a lot more work and time to try to do this, just working
directly on Linux is easier and cheaper over time :)

> 2) The rtlwifi in staging
>In staging, the module phydm v13 contains bugs, so I want to upgrade
>to v21 (Realtek internal version number). This upgrade contains a
>big patch that the difference between v13 and v21, and there are 
>40+ patches to support this upgrade. I have three options, and
>I want to know which one is prefer.
> 
> 2.1) apply 40+ patches to both staging and wireless tree, and apply
>  the big patch to staging only. After reviewing, we move the module
>  to wireless tree.

I don't want a "big patch" for staging.

> 2.2) apply 40+ patches to wireless tree, and apply a single bigger 
>  patch containing 40+ patches and the big patch to staging. I think
>  this can be seen as a new driver in staging. After reviewing, 
>  we move the module to wireless tree.
> 
> 2.3) don't apply anything to staging. Just apply 40+ patches and add
>  phydm v21 to wireless.

This last option seems good to me, then move the driver that is in
staging to use the wireless core version instead?

> 3) Coming drivers -- rtl8723de and rtl8821ce
>We're developing the two drivers, and rtl8723de and rtl8821ce will
>be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on
>rtl8822be that in staging now, so the line of code will be fewer.
>The new files will be a new IC folder and IC supported files of 
>three modules that btcoexist, phydm and halmac. Could I submit
>them to wirless tree when they're ready?

Sure, please submit them when they are ready, as long as they follow the
correct Linux style rules.

> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I 
>plan to fix them after rtl8723de and rtl8821ce. Because the drivers
>are developing, the changes will make us hard to integrate. However,
>I don't have plan to 

using verifier to ensure a BPF program uses certain metadata?

[Johannes Berg]

Hi,

As we discussed in April already (it's really been that long...), I'd
wanted to allow using BPF to filter wireless monitor frames, to enable
new use cases and higher performance in monitoring. I have some code,
at

https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/log/?h=bpf

which implements parts of this. It's still missing the TX status path
and perhaps associated metadata, but that part is easy.

The bigger "problem" is that we're going to be adding support for
devices that have 802.11->Ethernet conversion already in hardware, and
in that case the notion that the filter program will get an 802.11
header to look at is no longer right.

Now, most likely for the actual in-service monitoring we'll actually
have to reconstitute the 802.11 header on the fly (in pure monitoring
where nothing else is active, we can just disable the conversion), but
the filtering shouldn't really be reliant on that, since that's not the
cheapest thing to do.

The obvious idea around this is to add a metadata field (just a bit
really), something like "is_data_ethernet", saying that it was both a
data frame and is already converted to have an Ethernet header.
However, since these devices don't really exist yet for the vast
majority of people, I'm a bit afraid that we'll find later a lot of
code simply ignoring this field and looking at the "802.11" header,
which is then broken if it encounters an Ethernet header instead.

Are there lies my question: If we added a new callback to
bpf_verifier_ops (e.g. "post_verifier_check"), to be called after the
normal verification, and also added a context argument to
"is_valid_access" (*), we could easily track that this new metadata
field is accessed, and reject programs that don't access it at all.

Now, I realize that people could trivially just work around this in
their program if they wanted, but I think most will take the reminder
and just implement

if (ctx->is_data_ethernet)
return DROP_FRAME;

instead, since mostly data frames will not be very relevant to them.

What do you think?

johannes

(*) the context argument could just be a void **, and is_valid_access
can allocate memory if needed - in this case I'd probably just do
something like "return *is_valid_access ?: NULL;" and return something
like "(void *)1" for when the field in question was accessed, and then
just check that in "post_verifier_check".

Re: [PATCH] iw: add command to register and capture mgmt frames

[Johannes Berg]

Hi,

Looks like this played out while I wasn't paying attention :-)

So first, I'll say that I have no objection in principle to the patch,
as a debugging aid.

However, the story is more complicated.

> IIUC tshark and other specific capture tools need wireless netdevice
> to be in monitor mode.

This is correct, but shouldn't be a problem.

> This particular iw command is based on
> NL80211_CMD_REGISTER_FRAME
> and related cfg80211 ops. In fact, this command can be used to
> subscribe
> to mgmt frames when wireless device is up and running in AP or STA
> mode.
> That can be convenient for monitor and debug purposes. There is a
> limitation though: currently cfg80211 core allows only one subscriber
> for each particular frame/pattern.

If you're looking for a tool to actually do something like sniffer,
this API isn't the right thing to do.

That's why I also don't think it should be added to tshark.

Remember that with the use of this API also come certain obligations.
For example, if you subscribe to (certain) action frames and then don't
actually process them as described by the spec, then the subscriber
MUST generate responses with the 0x80 bit ORed into the action code,
returning the frame as not understood. Clearly, this isn't something
that iw does and can implement.

Additionally, as you noted, and it's for this exact reason because
otherwise responsibilities wouldn't be clearly defined, there can only
be a single subscriber to a certain set of frames, as specified by the
subtype and match prefix, so using it as a type of sniffer or debug
tool may affect other functional operation.


In mac80211, it's _always_ possible to add a monitor interface, and
given no special flags (which may or may not be supported by a given
driver anyway) this monitor interface is a pure software construct and
will in no way affect device operation - apart from sending all
received frames to the monitor interface at the beginning of mac80211's
operation.

I see no reason, other than needing a little bit of coding, that this
couldn't similarly be supported in qtnfmac.

Now, there *is* one problem with this - namely that this can
significantly affect performance. The reason is that all frames need to
be sent to the monitor interface, even if they're immediately discarded
using a BPF socket filter. Sending them there means allocating a new
SKB (not necessarily copying the data, but still), as well as
generating radiotap header information for the frames. In many cases
data frames are immediately discarded so all this work is for naught.

What I had worked on a while ago to solve this problem is an eBPF
filter attached just before the "branch point" to the monitor
interface, this filter gets access to the frame (without radiotap data)
and some limited RX status data.

You can find the code for this here (may need rebasing, but I have
merged all the RX path logic changes already):

https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
/log/?h=bpf


Now, there are two problems with this still (afaict):

   1. It doesn't cover the TX status path, which it should, since that
  also goes to the monitor interfaces. This is easily solved, I think
  I just forgot about it :) (This may need an additional field in the
  metadata, but that's not a problem)
   2. It doesn't deal with already decapsulated RX, i.e. devices where the
  802.11->ethernet decapsulation is done in the device already. This
  was the reason I didn't merge this, and the problem I see with this
  is that even if we do add additional metadata, it's hard to ensure
  that eBPF programs won't ignore it.

johannes

Re: Two rtlwifi drivers?

[Oleksij Rempel]

Hi
Just my two cents, :)

Am 16.10.2017 um 04:41 schrieb Pkshih:
> 
> 
>> -Original Message-
>> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
>> Sent: Thursday, October 12, 2017 6:35 PM
>> To: Kalle Valo
>> Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick 
>> Joarder;
>> de...@driverdev.osuosl.org; linux-wireless@vger.kernel.org; 
>> kernel-janit...@vger.kernel.org
>> Subject: Re: Two rtlwifi drivers?
>>
>> On Thu, Oct 12, 2017 at 11:38:06AM +0300, Kalle Valo wrote:
 So what to do?  Any ideas?  What makes your life easier?  You can just
 ignore the staging tree, as it should not affect your portion of the
 kernel at all, right?
>>>
>>> Yes, I automatically ignore anything staging related. But the problem is
>>> that we now have two drivers with the same name and people don't always
>>> remember to prefix the patch with "staging: ". So on a bad day I might
>>> accidentally apply a patch which was meant for your tree. Of course I
>>> immediately revert it as soon as I, or someone else, catches that but
>>> annoying still.
>>
>> It doesn't bother me if you apply staging patches, I can handle the
>> merge issues :)
>>
>>> I think we have two options here:
>>>
>>> 1) We set a deadline (like 12 months or something) for the
>>>drivers/staging/rtlwifi and after that you refuse to take any patches
>>>for it. Hopefully this makes it clear for everyone that this fork is
>>>just temporary. I think Larry is trying to do this, which is great.
>>
>> Fine with me, if Larry is ok with it.
>>
>>> 2) We move the whole rtlwifi driver to staging. A very bad option but
>>>still better than forking the drivers.
>>
>> Ick, I don't want that to have to happen, that would not be good for the
>> users of other devices that the "real" rtlwifi driver supports.
>>
> 
> Hi Larry, Kalle and Gerg,
> 
> This is Realtek engineer, PK. I appreciate your support to submit, review 
> and merge patch. Since I'm a Linux newbie, I'll describe the situation of 
> rtlwifi and need your suggestions.
> 
> 
> 1) New modules in rtlwifi
>We add two modules named phydm and halmac, when adding rtl8822be in 
>staging. The phydm is BB/RF related module containing the parameters
>and APIs of BB/RF, and a dynamic mechanism to adapt to different
>field environment. The halmac consists of MAC APIs.
>The two modules are used by many OSs, so '#ifdef', CamelCase and
>so on are existing in original files. Hence, we convert them to Linux 
>form by script, but it's not perfect. Do you have suggestion to deal
>with this problem?
> 
> 
> 2) The rtlwifi in staging
>In staging, the module phydm v13 contains bugs, so I want to upgrade
>to v21 (Realtek internal version number). This upgrade contains a
>big patch that the difference between v13 and v21, and there are 
>40+ patches to support this upgrade. I have three options, and
>I want to know which one is prefer.
> 
> 2.1) apply 40+ patches to both staging and wireless tree, and apply
>  the big patch to staging only. After reviewing, we move the module
>  to wireless tree.
> 
> 2.2) apply 40+ patches to wireless tree, and apply a single bigger 
>  patch containing 40+ patches and the big patch to staging. I think
>  this can be seen as a new driver in staging. After reviewing, 
>  we move the module to wireless tree.
> 
> 2.3) don't apply anything to staging. Just apply 40+ patches and add
>  phydm v21 to wireless.
> 
> 
> 3) Coming drivers -- rtl8723de and rtl8821ce
>We're developing the two drivers, and rtl8723de and rtl8821ce will
>be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on
>rtl8822be that in staging now, so the line of code will be fewer.
>The new files will be a new IC folder and IC supported files of 
>three modules that btcoexist, phydm and halmac. Could I submit
>them to wirless tree when they're ready?
> 
> 
> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I 
>plan to fix them after rtl8723de and rtl8821ce. Because the drivers
>are developing, the changes will make us hard to integrate. However,
>I don't have plan to process the magic numbers in the module phydm,
>because the most of BB/RF registers contain many functions. And
>it doesn't have a register name but a bit field name instead.
>Our BB team guys say the use of enumeration or defined name will
>be unreadable, and the name is meaningless for most people.

Experience with ath9k driver showed, that development was kind of
balanced between two groups, QCA and Community (Other companies,
researches, education and so on.). Saying: "you will not understand it
any way" is nor really helpful :)
Please don't repeat bad experience of Broadcom.

> Many Linux users ask Larry about the new drivers, and Realtek will
> provide drivers and try to submit them by myself. I hope the Linux
> users can yield the drivers as soon as I 

[PATCH V6 5/5] ath10k: Fix TDLS peer TX data failure issue on encryped AP

[yintang]

From: Yingying Tang 

For WPA encryption, QCA6174 firmware(version: WLAN.RM.4.4) will unblock
data when M4 was sent successfully. For other encryption which didn't need
4-way handshake firmware will unblock the data when peer authorized. Since
TDLS is 3-way handshake host need send authorize cmd to firmware to unblock
data.

Signed-off-by: Yingying Tang 
---
 drivers/net/wireless/ath/ath10k/mac.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a984a72..fe14d3c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5841,6 +5841,10 @@ static int ath10k_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
ath10k_warn(ar, "Peer %pM disappeared!\n", peer_addr);
spin_unlock_bh(>data_lock);
 
+   if (sta && sta->tdls)
+   ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+ WMI_PEER_AUTHORIZE, 1);
+
 exit:
mutex_unlock(>conf_mutex);
return ret;
-- 
1.7.9.5