[PATCH] ath10k: fix the logic of limiting tdls peer counts

[ryanhsu]

From: Ryan Hsu 

The original idea is to limit the maximum TDLS peer link, but the logic
is always false, and never be able to restrict the number of TDLS peer
creation.

Fix the logic here and also move the checking earlier, so that it could
avoid to handle the failure case, e.g disable the tdls peer, delete the
peer and also vdev count cleanup.

Signed-off-by: Ryan Hsu 
---
 drivers/net/wireless/ath/ath10k/mac.c | 49 +++
 1 file changed, 21 insertions(+), 28 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 4674ff3..48418f9 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6073,6 +6073,20 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
   ar->num_stations + 1, ar->max_num_stations,
   ar->num_peers + 1, ar->max_num_peers);
 
+   num_tdls_stations = ath10k_mac_tdls_vif_stations_count(hw, vif);
+   num_tdls_vifs = ath10k_mac_tdls_vifs_count(hw);
+
+   if (sta->tdls) {
+   if (num_tdls_stations >= ar->max_num_tdls_vdevs) {
+   ath10k_warn(ar, "vdev %i exceeded maximum 
number of tdls vdevs %i\n",
+   arvif->vdev_id,
+   ar->max_num_tdls_vdevs);
+   ret = -ELNRNG;
+   goto exit;
+   }
+   peer_type = WMI_PEER_TYPE_TDLS;
+   }
+
ret = ath10k_mac_inc_num_stations(arvif, sta);
if (ret) {
ath10k_warn(ar, "refusing to associate station: too 
many connected already (%d)\n",
@@ -6080,9 +6094,6 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
goto exit;
}
 
-   if (sta->tdls)
-   peer_type = WMI_PEER_TYPE_TDLS;
-
ret = ath10k_peer_create(ar, vif, sta, arvif->vdev_id,
 sta->addr, peer_type);
if (ret) {
@@ -6113,35 +6124,17 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
if (!sta->tdls)
goto exit;
 
-   num_tdls_stations = ath10k_mac_tdls_vif_stations_count(hw, vif);
-   num_tdls_vifs = ath10k_mac_tdls_vifs_count(hw);
-
-   if (num_tdls_vifs >= ar->max_num_tdls_vdevs &&
-   num_tdls_stations == 0) {
-   ath10k_warn(ar, "vdev %i exceeded maximum number of 
tdls vdevs %i\n",
-   arvif->vdev_id, ar->max_num_tdls_vdevs);
-   ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
+   ret = ath10k_wmi_update_fw_tdls_state(ar, arvif->vdev_id,
+ WMI_TDLS_ENABLE_ACTIVE);
+   if (ret) {
+   ath10k_warn(ar, "failed to update fw tdls state on vdev 
%i: %i\n",
+   arvif->vdev_id, ret);
+   ath10k_peer_delete(ar, arvif->vdev_id,
+  sta->addr);
ath10k_mac_dec_num_stations(arvif, sta);
-   ret = -ENOBUFS;
goto exit;
}
 
-   if (num_tdls_stations == 0) {
-   /* This is the first tdls peer in current vif */
-   enum wmi_tdls_state state = WMI_TDLS_ENABLE_ACTIVE;
-
-   ret = ath10k_wmi_update_fw_tdls_state(ar, 
arvif->vdev_id,
- state);
-   if (ret) {
-   ath10k_warn(ar, "failed to update fw tdls state 
on vdev %i: %i\n",
-   arvif->vdev_id, ret);
-   ath10k_peer_delete(ar, arvif->vdev_id,
-  sta->addr);
-   ath10k_mac_dec_num_stations(arvif, sta);
-   goto exit;
-   }
-   }
-
ret = ath10k_mac_tdls_peer_update(ar, arvif->vdev_id, sta,
  WMI_TDLS_PEER_STATE_PEERING);
if (ret) {
-- 
1.9.1

[PATCH] NFC: add NULL checks to avoid potential NULL pointer dereference

[Gustavo A. R. Silva]

NULL checks at line 457: if (!link0 || !link1) {, implies that both
pointers link0 and link1 might be NULL.
Function nfcsim_link_free() dereference pointers link0 and link1.
Add NULL checks before calling nfcsim_link_free() to avoid a
potential NULL pointer dereference.

Addresses-Coverity-ID: 1364857
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/nfc/nfcsim.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/nfc/nfcsim.c b/drivers/nfc/nfcsim.c
index a466e79..6e90b54 100644
--- a/drivers/nfc/nfcsim.c
+++ b/drivers/nfc/nfcsim.c
@@ -482,8 +482,10 @@ static int __init nfcsim_init(void)
 exit_err:
pr_err("Failed to initialize nfcsim driver (%d)\n", rc);
 
-   nfcsim_link_free(link0);
-   nfcsim_link_free(link1);
+   if (link0)
+   nfcsim_link_free(link0);
+   if (link1)
+   nfcsim_link_free(link1);
 
return rc;
 }
-- 
2.5.0

Re: [PATCH] mac80211: manage RX BA session offload without SKB queue

[kbuild test robot]

Hi Johannes,

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

url:
https://github.com/0day-ci/linux/commits/Johannes-Berg/mac80211-manage-RX-BA-session-offload-without-SKB-queue/20170531-041414
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
master
config: i386-randconfig-x079-05301437 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   net/mac80211/ht.c: In function 'ieee80211_ba_session_work':
>> net/mac80211/ht.c:320:38: error: assignment to expression with array type
  sta->ampdu_mlme.tid_rx_manage_offl = 0;
 ^

vim +320 net/mac80211/ht.c

   314   * When this flag is set, new sessions should be
   315   * blocked, and existing sessions will be torn
   316   * down by the code that set the flag, so this
   317   * need not run.
   318   */
   319  if (test_sta_flag(sta, WLAN_STA_BLOCK_BA)) {
 > 320  sta->ampdu_mlme.tid_rx_manage_offl = 0;
   321  goto unlock;
   322  }
   323  

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


.config.gz
Description: application/gzip

[net-wireless-orinoco] question about potential null pointer dereference

[Gustavo A. R. Silva]

Hello everybody,

While looking into Coverity ID 1357460 I ran into the following piece  
of code at drivers/net/wireless/intersil/orinoco/mic.c:48


48int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key,
49u8 *da, u8 *sa, u8 priority,
50u8 *data, size_t data_len, u8 *mic)
51{
52SHASH_DESC_ON_STACK(desc, tfm_michael);
53u8 hdr[ETH_HLEN + 2]; /* size of header + padding */
54int err;
55
56if (tfm_michael == NULL) {
57printk(KERN_WARNING "orinoco_mic: tfm_michael == NULL\n");
58return -1;
59}
60
61/* Copy header into buffer. We need the padding on the end zeroed */
62memcpy([0], da, ETH_ALEN);
63memcpy([ETH_ALEN], sa, ETH_ALEN);
64hdr[ETH_ALEN * 2] = priority;
65hdr[ETH_ALEN * 2 + 1] = 0;
66hdr[ETH_ALEN * 2 + 2] = 0;
67hdr[ETH_ALEN * 2 + 3] = 0;
68
69desc->tfm = tfm_michael;
70desc->flags = 0;
71
72err = crypto_shash_setkey(tfm_michael, key, MIC_KEYLEN);
73if (err)
74return err;
75
76err = crypto_shash_init(desc);
77if (err)
78return err;
79
80err = crypto_shash_update(desc, hdr, sizeof(hdr));
81if (err)
82return err;
83
84err = crypto_shash_update(desc, data, data_len);
85if (err)
86return err;
87
88err = crypto_shash_final(desc, mic);
89shash_desc_zero(desc);
90
91return err;
92}

The issue here is that line 56 implies that pointer tfm_michael might  
be NULL. If this is the case, there is a potential NULL pointer  
dereference at line 52 once pointer tfm_michael is indirectly  
dereferenced inside macro SHASH_DESC_ON_STACK().


My question is if there is any chance that pointer tfm_michael might  
be NULL when calling macro SHASH_DESC_ON_STACK() ?


I'm trying to figure out if this is a false positive or something that  
needs to be fixed somehow.


I'd really appreciate any comment on this.

Thank you!
--
Gustavo A. R. Silva

[PATCH v2] mac80211: manage RX BA session offload without SKB queue

[Johannes Berg]

From: Johannes Berg 

Instead of using the SKB queue with the fake pkt_type for the
offloaded RX BA session management, also handle this with the
normal aggregation state machine worker. This also makes the
use of this more reliable since it gets rid of the allocation
of the fake skb.

Combined with the previous patch, this finally allows us to
get rid of the pkt_type hack entirely, so do that as well.

Signed-off-by: Johannes Berg 
---
 include/net/mac80211.h | 21 +
 net/mac80211/agg-rx.c  | 47 --
 net/mac80211/ht.c  | 12 
 net/mac80211/ieee80211_i.h | 11 ---
 net/mac80211/iface.c   | 25 ++--
 net/mac80211/rx.c  |  4 
 net/mac80211/sta_info.h|  3 +++
 7 files changed, 46 insertions(+), 77 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e01daff1e255..b2b5419467cc 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -5452,6 +5452,9 @@ void ieee80211_mark_rx_ba_filtered_frames(struct 
ieee80211_sta *pubsta, u8 tid,
  */
 void ieee80211_send_bar(struct ieee80211_vif *vif, u8 *ra, u16 tid, u16 ssn);
 
+void ieee80211_manage_rx_ba_offl(struct ieee80211_vif *vif, const u8 *addr,
+unsigned int bit);
+
 /**
  * ieee80211_start_rx_ba_session_offl - start a Rx BA session
  *
@@ -5466,8 +5469,13 @@ void ieee80211_send_bar(struct ieee80211_vif *vif, u8 
*ra, u16 tid, u16 ssn);
  * @addr: station mac address
  * @tid: the rx tid
  */
-void ieee80211_start_rx_ba_session_offl(struct ieee80211_vif *vif,
-   const u8 *addr, u16 tid);
+static inline void ieee80211_start_rx_ba_session_offl(struct ieee80211_vif 
*vif,
+ const u8 *addr, u16 tid)
+{
+   if (WARN_ON(tid >= IEEE80211_NUM_TIDS))
+   return;
+   ieee80211_manage_rx_ba_offl(vif, addr, tid);
+}
 
 /**
  * ieee80211_stop_rx_ba_session_offl - stop a Rx BA session
@@ -5483,8 +5491,13 @@ void ieee80211_start_rx_ba_session_offl(struct 
ieee80211_vif *vif,
  * @addr: station mac address
  * @tid: the rx tid
  */
-void ieee80211_stop_rx_ba_session_offl(struct ieee80211_vif *vif,
-  const u8 *addr, u16 tid);
+static inline void ieee80211_stop_rx_ba_session_offl(struct ieee80211_vif *vif,
+const u8 *addr, u16 tid)
+{
+   if (WARN_ON(tid >= IEEE80211_NUM_TIDS))
+   return;
+   ieee80211_manage_rx_ba_offl(vif, addr, tid + IEEE80211_NUM_TIDS);
+}
 
 /* Rate control API */
 
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 1b7a4daf283c..3a0282188ad6 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -449,44 +449,21 @@ void ieee80211_process_addba_request(struct 
ieee80211_local *local,
buf_size, true, false);
 }
 
-void ieee80211_start_rx_ba_session_offl(struct ieee80211_vif *vif,
-   const u8 *addr, u16 tid)
+void ieee80211_manage_rx_ba_offl(struct ieee80211_vif *vif,
+const u8 *addr, unsigned int bit)
 {
struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
struct ieee80211_local *local = sdata->local;
-   struct ieee80211_rx_agg *rx_agg;
-   struct sk_buff *skb = dev_alloc_skb(0);
-
-   if (unlikely(!skb))
-   return;
-
-   rx_agg = (struct ieee80211_rx_agg *) >cb;
-   memcpy(_agg->addr, addr, ETH_ALEN);
-   rx_agg->tid = tid;
-
-   skb->pkt_type = IEEE80211_SDATA_QUEUE_RX_AGG_START;
-   skb_queue_tail(>skb_queue, skb);
-   ieee80211_queue_work(>hw, >work);
-}
-EXPORT_SYMBOL(ieee80211_start_rx_ba_session_offl);
-
-void ieee80211_stop_rx_ba_session_offl(struct ieee80211_vif *vif,
-  const u8 *addr, u16 tid)
-{
-   struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
-   struct ieee80211_local *local = sdata->local;
-   struct ieee80211_rx_agg *rx_agg;
-   struct sk_buff *skb = dev_alloc_skb(0);
-
-   if (unlikely(!skb))
-   return;
+   struct sta_info *sta;
 
-   rx_agg = (struct ieee80211_rx_agg *) >cb;
-   memcpy(_agg->addr, addr, ETH_ALEN);
-   rx_agg->tid = tid;
+   rcu_read_lock();
+   sta = sta_info_get_bss(sdata, addr);
+   if (!sta)
+   goto unlock;
 
-   skb->pkt_type = IEEE80211_SDATA_QUEUE_RX_AGG_STOP;
-   skb_queue_tail(>skb_queue, skb);
-   ieee80211_queue_work(>hw, >work);
+   set_bit(bit, sta->ampdu_mlme.tid_rx_manage_offl);
+   ieee80211_queue_work(>hw, >ampdu_mlme.work);
+ unlock:
+   rcu_read_unlock();
 }
-EXPORT_SYMBOL(ieee80211_stop_rx_ba_session_offl);
+EXPORT_SYMBOL(ieee80211_manage_rx_ba_offl);
diff --git a/net/mac80211/ht.c 

Re: [PATCH] mac80211: manage RX BA session offload without SKB queue

[Johannes Berg]

On Tue, 2017-05-30 at 16:10 +0200, Johannes Berg wrote:
> From: Johannes Berg 
> 
> Instead of using the SKB queue with the fake pkt_type for the
> offloaded RX BA session management, also handle this with the
> normal aggregation state machine worker. This also makes the
> use of this more reliable since it gets rid of the allocation
> of the fake skb.
> 
> Combined with the previous patch, this finally allows us to
> get rid of the pkt_type hack entirely, so do that as well.

Previous patch is this:

https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git/commit/?id=7a7c0a6438b8e7636d5a22e572892cc234f68297

I can't test this (don't have ath10k easily testable), so testing would
be appreciated.

johannes

[PATCH] mac80211: manage RX BA session offload without SKB queue

[Johannes Berg]

From: Johannes Berg 

Instead of using the SKB queue with the fake pkt_type for the
offloaded RX BA session management, also handle this with the
normal aggregation state machine worker. This also makes the
use of this more reliable since it gets rid of the allocation
of the fake skb.

Combined with the previous patch, this finally allows us to
get rid of the pkt_type hack entirely, so do that as well.

Signed-off-by: Johannes Berg 
---
 include/net/mac80211.h | 21 +
 net/mac80211/agg-rx.c  | 47 --
 net/mac80211/ht.c  | 21 ++---
 net/mac80211/ieee80211_i.h | 11 ---
 net/mac80211/iface.c   | 25 ++--
 net/mac80211/rx.c  |  4 
 net/mac80211/sta_info.h|  3 +++
 7 files changed, 52 insertions(+), 80 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e01daff1e255..b2b5419467cc 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -5452,6 +5452,9 @@ void ieee80211_mark_rx_ba_filtered_frames(struct 
ieee80211_sta *pubsta, u8 tid,
  */
 void ieee80211_send_bar(struct ieee80211_vif *vif, u8 *ra, u16 tid, u16 ssn);
 
+void ieee80211_manage_rx_ba_offl(struct ieee80211_vif *vif, const u8 *addr,
+unsigned int bit);
+
 /**
  * ieee80211_start_rx_ba_session_offl - start a Rx BA session
  *
@@ -5466,8 +5469,13 @@ void ieee80211_send_bar(struct ieee80211_vif *vif, u8 
*ra, u16 tid, u16 ssn);
  * @addr: station mac address
  * @tid: the rx tid
  */
-void ieee80211_start_rx_ba_session_offl(struct ieee80211_vif *vif,
-   const u8 *addr, u16 tid);
+static inline void ieee80211_start_rx_ba_session_offl(struct ieee80211_vif 
*vif,
+ const u8 *addr, u16 tid)
+{
+   if (WARN_ON(tid >= IEEE80211_NUM_TIDS))
+   return;
+   ieee80211_manage_rx_ba_offl(vif, addr, tid);
+}
 
 /**
  * ieee80211_stop_rx_ba_session_offl - stop a Rx BA session
@@ -5483,8 +5491,13 @@ void ieee80211_start_rx_ba_session_offl(struct 
ieee80211_vif *vif,
  * @addr: station mac address
  * @tid: the rx tid
  */
-void ieee80211_stop_rx_ba_session_offl(struct ieee80211_vif *vif,
-  const u8 *addr, u16 tid);
+static inline void ieee80211_stop_rx_ba_session_offl(struct ieee80211_vif *vif,
+const u8 *addr, u16 tid)
+{
+   if (WARN_ON(tid >= IEEE80211_NUM_TIDS))
+   return;
+   ieee80211_manage_rx_ba_offl(vif, addr, tid + IEEE80211_NUM_TIDS);
+}
 
 /* Rate control API */
 
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 1b7a4daf283c..3a0282188ad6 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -449,44 +449,21 @@ void ieee80211_process_addba_request(struct 
ieee80211_local *local,
buf_size, true, false);
 }
 
-void ieee80211_start_rx_ba_session_offl(struct ieee80211_vif *vif,
-   const u8 *addr, u16 tid)
+void ieee80211_manage_rx_ba_offl(struct ieee80211_vif *vif,
+const u8 *addr, unsigned int bit)
 {
struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
struct ieee80211_local *local = sdata->local;
-   struct ieee80211_rx_agg *rx_agg;
-   struct sk_buff *skb = dev_alloc_skb(0);
-
-   if (unlikely(!skb))
-   return;
-
-   rx_agg = (struct ieee80211_rx_agg *) >cb;
-   memcpy(_agg->addr, addr, ETH_ALEN);
-   rx_agg->tid = tid;
-
-   skb->pkt_type = IEEE80211_SDATA_QUEUE_RX_AGG_START;
-   skb_queue_tail(>skb_queue, skb);
-   ieee80211_queue_work(>hw, >work);
-}
-EXPORT_SYMBOL(ieee80211_start_rx_ba_session_offl);
-
-void ieee80211_stop_rx_ba_session_offl(struct ieee80211_vif *vif,
-  const u8 *addr, u16 tid)
-{
-   struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
-   struct ieee80211_local *local = sdata->local;
-   struct ieee80211_rx_agg *rx_agg;
-   struct sk_buff *skb = dev_alloc_skb(0);
-
-   if (unlikely(!skb))
-   return;
+   struct sta_info *sta;
 
-   rx_agg = (struct ieee80211_rx_agg *) >cb;
-   memcpy(_agg->addr, addr, ETH_ALEN);
-   rx_agg->tid = tid;
+   rcu_read_lock();
+   sta = sta_info_get_bss(sdata, addr);
+   if (!sta)
+   goto unlock;
 
-   skb->pkt_type = IEEE80211_SDATA_QUEUE_RX_AGG_STOP;
-   skb_queue_tail(>skb_queue, skb);
-   ieee80211_queue_work(>hw, >work);
+   set_bit(bit, sta->ampdu_mlme.tid_rx_manage_offl);
+   ieee80211_queue_work(>hw, >ampdu_mlme.work);
+ unlock:
+   rcu_read_unlock();
 }
-EXPORT_SYMBOL(ieee80211_stop_rx_ba_session_offl);
+EXPORT_SYMBOL(ieee80211_manage_rx_ba_offl);
diff --git a/net/mac80211/ht.c 

Re: [PATCH] Per chain RSSI reporting

[Matthias May]

On 27/05/17 23:49, Ben Greear wrote:
> On 05/27/2017 02:41 PM, Norik Dzhandzhapanyan wrote:
>> Yes ~6dB
> 
> If a packet is sent on 1 chain with ath10k firmware (9880 hardware, 
> specifically, but probably
> others as well), it will be around 6db higher on that particular chain
> than if the rate-control sends it on all three chains.
> 
> Are you measuring on a single chain, or on all of the chains at once and 
> adding
> the power?
> 
> I think we would need more detailed reporting using a good third-party device 
> before
> smoothing and RSSI.
> 
> Thanks,
> Ben
> 
>>

Also noteworthy is that if you measure in a cabled environment and add the 
signal from multiple chains with a combiner
you will probably measure the power wrong.
The reason for this is that the cyclic shift diversity doesn't work well in a 2 
dimensional environment (cable) compared
to the 3 dimensional environment (air).

BR
Matthias

>>
>> From: Ben Greear
>> Sent: Saturday, May 27, 2:38 PM
>> Subject: Re: [PATCH] Per chain RSSI reporting
>> To: Norik Dzhandzhapanyan, Adrian Chadd
>> Cc: ath...@lists.infradead.org, linux-wireless@vger.kernel.org
>>
>>
>> On 05/27/2017 12:25 PM, Norik Dzhandzhapanyan wrote: > We see this 
>> inconsistent/incorrect reporting in our RF chamber.
>> How different are the values, and did you sniff with a third-party device to 
>> see if it sees the same spikes in RSSI?
>> Thanks, Ben > > Norik > > On 05/27/2017 09:39 AM, Adrian Chadd wrote: >> On 
>> 27 May 2017 at 09:07, Ben Greear wrote:
>> >>> At low encoding rates, especially if it switches to a single-chain 
>> >>> encoding, >>> maybe the on-air signal really is
>> stronger? >>> >>> Have you verified in some other manner than the signals 
>> reported by ath10k >>> are >>> wrong? >>
>> Hiya, >> >> So yeah, multipath, higher TX rates == weaker TX signal, TPC, 
>> etc are >> all interesting to know about at
>> the receiver. it's hard to separate >> that out from the noise sometimes, 
>> but in some controlled deployments >> its
>> really obvious. >> >> >> >> -adrian >> >> > > > The contents of this 
>> transmission are Ethertronics Inc. Confidential
>> and may contain proprietary or legally privileged
>> information which may not be disclosed, copied or distributed without the 
>> express written consent of Ethertronics Inc.
>> The information is intended to be for the use of the individual or entity 
>> named on this transmission. If you are not
>> the intended recipient, be aware that any disclosure, copying, distribution 
>> or use of the contents of this information
>> is prohibited. If you have received this transmission in error, please 
>> notify us by telephone immediately so that we
>> can arrange for the retrieval of the original documents at no cost to you. 
>> Alternatively, notify the sender by
>> replying to this transmission and delete the message without disclosing it. 
>> Thank you > -- Ben Greear Candela
>> Technologies Inc http://www.candelatech.com
>>
> 

Re: [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions"

[Johannes Berg]

On Tue, 2017-04-04 at 10:26 +0300, Jani Nikula wrote:
> 
> > Interesting, TBH I never even considered this. How would I even run
> > it that way? Presumably "make htmldocs" doesn't do this?
> 
> Try 'make SPHINXOPTS=-j8 htmldocs'.

Yep, makes sense.

> > Sphinx documentation (http://www.sphinx-doc.org/en/stable/extdev/) says
> > this:
> > 
> > The setup() function can return a dictionary. This is treated by
> > Sphinx as metadata of the extension. Metadata keys currently
> > recognized are:
> > [...]
> > 'parallel_read_safe': a boolean that specifies if parallel reading
> > of source files can be used when the extension is loaded. It
> > defaults to False, i.e. you have to explicitly specify your
> > extension to be parallel-read-safe after checking that it is.
> > 
> > We do set this right now, so I guess it'd only be guaranteed to work
> > right within a single rst file, and then I should perhaps consider not
> > making this state global but somehow linking it to the rst file being
> > processed?
> 
> Perhaps, but does that defeat the purpose then?

Yeah, it kinda does. For my original use case in cfg80211 we only have
a single file, but even in mac80211 we already use more than one.

Not sure what to do then - I guess we just can't do that, unless we
prevent using this with parallelization, which seems awkward.

johannes

Re: 'iw events' stops receiving events after a while on 4.9 + hacks

[Johannes Berg]

On Wed, 2017-05-17 at 08:22 -0700, Ben Greear wrote:
> 
> I saw it exactly once so far, and it happened overnight,
> but we have not been doing a lot of work with the 4.9 kernel until
> recently.
> 
> I don't think there were many messages on this system, and certainly
> others have run much longer on systems that should be generating many
> more events without trouble.

Ok.

> Is there any way to dump out the socket information if we reproduce
> the problem?

I have no idea, sorry.

If you or Bastian can tell me how to reproduce the problem, I can try
to investigate it.

johannes

[RFT 2/3] brcmfmac: use firmware callback upon failure to load

[Arend van Spriel]

When firmware loading failed the code used to unbind the device provided
by the calling code. However, for the sdio driver two devices are bound
and both need to be released upon failure. The callback has been extended
with parameter to pass error code so add that in this commit upon firmware
loading failure.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/firmware.c | 27 +++---
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index ae61a24..d231042 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -484,39 +484,38 @@ static void brcmf_fw_request_nvram_done(const struct 
firmware *fw, void *ctx)
 fail:
brcmf_dbg(TRACE, "failed: dev=%s\n", dev_name(fwctx->dev));
release_firmware(fwctx->code);
-   device_release_driver(fwctx->dev);
+   fwctx->done(fwctx->dev, -ENOENT, NULL, NULL, 0);
kfree(fwctx);
 }
 
 static void brcmf_fw_request_code_done(const struct firmware *fw, void *ctx)
 {
struct brcmf_fw *fwctx = ctx;
-   int ret;
+   int ret = 0;
 
brcmf_dbg(TRACE, "enter: dev=%s\n", dev_name(fwctx->dev));
-   if (!fw)
+   if (!fw) {
+   ret = -ENOENT;
goto fail;
-
-   /* only requested code so done here */
-   if (!(fwctx->flags & BRCMF_FW_REQUEST_NVRAM)) {
-   fwctx->done(fwctx->dev, 0, fw, NULL, 0);
-   kfree(fwctx);
-   return;
}
+   /* only requested code so done here */
+   if (!(fwctx->flags & BRCMF_FW_REQUEST_NVRAM))
+   goto done;
+
fwctx->code = fw;
ret = request_firmware_nowait(THIS_MODULE, true, fwctx->nvram_name,
  fwctx->dev, GFP_KERNEL, fwctx,
  brcmf_fw_request_nvram_done);
 
-   if (!ret)
-   return;
-
-   brcmf_fw_request_nvram_done(NULL, fwctx);
+   /* pass NULL to nvram callback for bcm47xx fallback */
+   if (ret)
+   brcmf_fw_request_nvram_done(NULL, fwctx);
return;
 
 fail:
brcmf_dbg(TRACE, "failed: dev=%s\n", dev_name(fwctx->dev));
-   device_release_driver(fwctx->dev);
+done:
+   fwctx->done(fwctx->dev, ret, fw, NULL, 0);
kfree(fwctx);
 }
 
-- 
1.9.1

[RFT 3/3] brcmfmac: unbind all devices upon failure in firmware callback

[Arend van Spriel]

In brcmf_sdio_firmware_callback() we need to unbind the driver from
both sdio_func devices.

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

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 270c0ad..a5b27a4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3988,14 +3988,14 @@ static void brcmf_sdio_firmware_callback(struct device 
*dev, int err,
u8 saveclk;
 
brcmf_dbg(TRACE, "Enter: dev=%s, err=%d\n", dev_name(dev), err);
+   bus_if = dev_get_drvdata(dev);
+   sdiodev = bus_if->bus_priv.sdio;
if (err)
goto fail;
 
-   bus_if = dev_get_drvdata(dev);
if (!bus_if->drvr)
return;
 
-   sdiodev = bus_if->bus_priv.sdio;
bus = sdiodev->bus;
 
/* try to download image and nvram to the dongle */
@@ -4084,6 +4084,7 @@ static void brcmf_sdio_firmware_callback(struct device 
*dev, int err,
 fail:
brcmf_dbg(TRACE, "failed: dev=%s, err=%d\n", dev_name(dev), err);
device_release_driver(dev);
+   device_release_driver(>func[1]->dev);
 }
 
 struct brcmf_sdio *brcmf_sdio_probe(struct brcmf_sdio_dev *sdiodev)
-- 
1.9.1

[RFT 1/3] brcmfmac: add parameter to pass error code in firmware callback

[Arend van Spriel]

Extend the parameters in the firmware callback so it can be called
upon success and failure. This allows the caller to properly clear
all resources in the failure path. Right now the error code is
always zero, ie. success.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 10 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.h |  4 ++--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 17 -
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 17 +++--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c  |  6 --
 5 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index c7c1e99..ae61a24 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -442,7 +442,7 @@ struct brcmf_fw {
const char *nvram_name;
u16 domain_nr;
u16 bus_nr;
-   void (*done)(struct device *dev, const struct firmware *fw,
+   void (*done)(struct device *dev, int err, const struct firmware *fw,
 void *nvram_image, u32 nvram_len);
 };
 
@@ -477,7 +477,7 @@ static void brcmf_fw_request_nvram_done(const struct 
firmware *fw, void *ctx)
if (!nvram && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
goto fail;
 
-   fwctx->done(fwctx->dev, fwctx->code, nvram, nvram_length);
+   fwctx->done(fwctx->dev, 0, fwctx->code, nvram, nvram_length);
kfree(fwctx);
return;
 
@@ -499,7 +499,7 @@ static void brcmf_fw_request_code_done(const struct 
firmware *fw, void *ctx)
 
/* only requested code so done here */
if (!(fwctx->flags & BRCMF_FW_REQUEST_NVRAM)) {
-   fwctx->done(fwctx->dev, fw, NULL, 0);
+   fwctx->done(fwctx->dev, 0, fw, NULL, 0);
kfree(fwctx);
return;
}
@@ -522,7 +522,7 @@ static void brcmf_fw_request_code_done(const struct 
firmware *fw, void *ctx)
 
 int brcmf_fw_get_firmwares_pcie(struct device *dev, u16 flags,
const char *code, const char *nvram,
-   void (*fw_cb)(struct device *dev,
+   void (*fw_cb)(struct device *dev, int err,
  const struct firmware *fw,
  void *nvram_image, u32 nvram_len),
u16 domain_nr, u16 bus_nr)
@@ -555,7 +555,7 @@ int brcmf_fw_get_firmwares_pcie(struct device *dev, u16 
flags,
 
 int brcmf_fw_get_firmwares(struct device *dev, u16 flags,
   const char *code, const char *nvram,
-  void (*fw_cb)(struct device *dev,
+  void (*fw_cb)(struct device *dev, int err,
 const struct firmware *fw,
 void *nvram_image, u32 nvram_len))
 {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index d3c9f0d..8fa4b7e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -73,13 +73,13 @@ int brcmf_fw_map_chip_to_name(u32 chip, u32 chiprev,
  */
 int brcmf_fw_get_firmwares_pcie(struct device *dev, u16 flags,
const char *code, const char *nvram,
-   void (*fw_cb)(struct device *dev,
+   void (*fw_cb)(struct device *dev, int err,
  const struct firmware *fw,
  void *nvram_image, u32 nvram_len),
u16 domain_nr, u16 bus_nr);
 int brcmf_fw_get_firmwares(struct device *dev, u16 flags,
   const char *code, const char *nvram,
-  void (*fw_cb)(struct device *dev,
+  void (*fw_cb)(struct device *dev, int err,
 const struct firmware *fw,
 void *nvram_image, u32 nvram_len));
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index f36b96d..f878706 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1650,16 +1650,23 @@ static void brcmf_pcie_buscore_activate(void *ctx, 
struct brcmf_chip *chip,
.write32 

[RFT 0/3] brcmfmac: firmware loading rework

[Arend van Spriel]

Hi Enric,

Could you please try these patches and let me know if they resolve
the issue for you.

Regards,
Arend

Arend van Spriel (3):
  brcmfmac: add parameter to pass error code in firmware callback
  brcmfmac: use firmware callback upon failure to load
  brcmfmac: unbind all devices upon failure in firmware callback

 .../broadcom/brcm80211/brcmfmac/firmware.c | 35 +++---
 .../broadcom/brcm80211/brcmfmac/firmware.h |  4 +--
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c| 17 +++
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 18 +++
 .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c |  6 ++--
 5 files changed, 47 insertions(+), 33 deletions(-)

-- 
1.9.1

Re: [PATCH 4.12 REGRESSION fix] brcmfmac: Use ALIGNMENT rather then hardcoded "4" for bus:txglomalign

[Arend van Spriel]

On 26-05-17 19:11, Arend van Spriel wrote:
> On 26-05-17 16:53, Kalle Valo wrote:
>> Arend van Spriel  writes:
>>
>> Fixes: 6e84ab604bde ("properly align buffers ... with 64 bit DMA")
>> Suggested-by: Arend van Spriel 
>> Signed-off-by: Hans de Goede 
>
> I'll queue this to 4.12.

 Thank you, given that Arend is set as the Author you can add my:

 Tested-by: Hans de Goede 

 And maybe drop the Suggested-by: Arend van Spriel ?
>>
>> Sure, I can add that.
>>
>>> Seems to me you need my Signed-off-by: as I do not see that in this patch.
>>
>> Yes, that is needed if you are the author. If you reply to this message
>> I can add that.
> 
> Ok. Here it is. Please feel free to add Signed-off-by tag for me
> authoring this change. The Signed-off-by tag for Hans can stay as well
> as this patch went through his hands (and he came up with the commit
> message ;-) ).

Hi Kalle,

Here is the commit message I came up with which may explain the issue
better:

"""
brcmfmac: fix alignment configuration on host using 64-bit DMA

For SDIO the alignment requirement for transfers from device to host
is configured in firmware. This configuration is limited to minimum
of 4-byte alignment. However, this is not correct for platforms using
64-bit DMA when the minimum alignment should be 8 bytes. This issue
appeared when the ALIGNMENT definition was set according the DMA
configuration. The configuration in firmware was not using that macro
defintion, but a hardcoded value of 4. Hence the driver reported
alignment failures for data coming from the device and causing
transfers to fail.

Fixes: 6e84ab604bde ("brcmfmac: properly align buffers on certain platforms
Reported-by: Hans de Goede 
Tested-by: Hans de Goede 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
"""

I leave it at your discretion how to deal with this. If needed I can
submit the complete patch.

Regards,
Arend

Re: [PATCH 4.12 REGRESSION fix] brcmfmac: Use ALIGNMENT rather then hardcoded "4" for bus:txglomalign

[Arend van Spriel]

On 26-05-17 19:11, Arend van Spriel wrote:
> On 26-05-17 16:53, Kalle Valo wrote:
>> Arend van Spriel  writes:
>>
>> Fixes: 6e84ab604bde ("properly align buffers ... with 64 bit DMA")
>> Suggested-by: Arend van Spriel 
>> Signed-off-by: Hans de Goede 
>
> I'll queue this to 4.12.

 Thank you, given that Arend is set as the Author you can add my:

 Tested-by: Hans de Goede 

 And maybe drop the Suggested-by: Arend van Spriel ?
>>
>> Sure, I can add that.
>>
>>> Seems to me you need my Signed-off-by: as I do not see that in this patch.
>>
>> Yes, that is needed if you are the author. If you reply to this message
>> I can add that.
> 
> Ok. Here it is. Please feel free to add Signed-off-by tag for me
> authoring this change. The Signed-off-by tag for Hans can stay as well
> as this patch went through his hands (and he came up with the commit
> message ;-) ).

Hi Kalle,

Here is the commit message I came up with which may explain the issue
better:

"""
brcmfmac: fix alignment configuration on host using 64-bit DMA

For SDIO the alignment requirement for transfers from device to host
is configured in firmware. This configuration is limited to minimum
of 4-byte alignment. However, this is not correct for platforms using
64-bit DMA when the minimum alignment should be 8 bytes. This issue
appeared when the ALIGNMENT definition was set according the DMA
configuration. The configuration in firmware was not using that macro
defintion, but a hardcoded value of 4. Hence the driver reported
alignment failures for data coming from the device and causing
transfers to fail.

Fixes: 6e84ab604bde ("brcmfmac: properly align buffers on certain platforms
Reported-by: Hans de Goede 
Tested-by: Hans de Goede 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
"""

I leave it at your discretion how to deal with this. If needed I can
submit the complete patch.

Regards,
Arend

[PATCH] bcm47xx: fix build regression

[Arnd Bergmann]

An unknown change in the kernel headers caused a build regression
in an MTD partition driver:

In file included from drivers/mtd/bcm47xxpart.c:12:0:
include/linux/bcm47xx_nvram.h: In function 'bcm47xx_nvram_init_from_mem':
include/linux/bcm47xx_nvram.h:27:10: error: 'ENOTSUPP' undeclared (first use in 
this function)

Clearly we want to include linux/errno.h here.

Signed-off-by: Arnd Bergmann 
---
 include/linux/bcm47xx_nvram.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/bcm47xx_nvram.h b/include/linux/bcm47xx_nvram.h
index 2793652fbf66..a414a2b53e41 100644
--- a/include/linux/bcm47xx_nvram.h
+++ b/include/linux/bcm47xx_nvram.h
@@ -8,6 +8,7 @@
 #ifndef __BCM47XX_NVRAM_H
 #define __BCM47XX_NVRAM_H
 
+#include 
 #include 
 #include 
 #include 
-- 
2.9.0

heads-up: wireless summit planning

[Johannes Berg]

Hi all,

Netdev 2.2 has been announced for Seoul, South Korea, November 8-10:

http://netdevconf.org/2.2/

We're planning to hold the next wireless workshop there.

Formalities will be as usual - open (discussion) session, you have to
be registered for netdev. The details for that haven't been announced
yet, but I figured everyone could use an early warning for planning
purposes :-)

johannes

Re: [PATCH v2] mac80211: Invoke TX LED in more code paths

[Johannes Berg]

On Sat, 2017-05-27 at 14:59 -0700, Bjorn Andersson wrote:
> ieee80211_tx_status() is only one of the possible ways a driver can
> report a handled packet, some drivers call this for every packet
> while
> others calls it rarely or never.
> 
> In order to invoke the TX LED in the non-status reporting cases this
> patch pushes the call to ieee80211_led_tx() into
> ieee80211_report_used_skb(), which is shared between the various code
> paths.

Applied.

johannes