Re: [PATCH] [linux-next] rtlwifi: Fix typo in printk

[Larry Finger]

On 06/28/2016 10:37 PM, Masanari Iida wrote:

This patch fix spelling typos found in drivers/net/wireless/realtek.

Signed-off-by: Masanari Iida 


Acked--by: Larry Finger 

Thanks,

Larry


---
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c| 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c   | 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 2 +-
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c   | 2 +-
  7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
index 416a9ba6382e..422c7813f5ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1239,7 +1239,7 @@ u8 rtl88e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl88e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current channel 
%d\n",
+"sw_chnl_inprogress false schedule workitem current channel 
%d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 77e61b19bf36..9301583ce768 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -757,7 +757,7 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92c_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index 459f3d0efa2f..0a5c9fcfe73b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -496,7 +496,7 @@ static void rtl92ee_dm_find_minimum_rssi(struct 
ieee80211_hw *hw)
rtl_dm_dig->min_undec_pwdb_for_dm =
rtlpriv->dm.entry_min_undec_sm_pwdb;
RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"AP Ext Port or disconnet PWDB = 0x%x\n",
+"AP Ext Port or disconnect PWDB = 0x%x\n",
 rtl_dm_dig->min_undec_pwdb_for_dm);
}
RT_TRACE(rtlpriv, COMP_DIG, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index c2bf8d1a7af3..97d9a8e209f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -1819,7 +1819,7 @@ u8 rtl92ee_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92ee_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current channel 
%d\n",
+"sw_chnl_inprogress false schedule workitem current channel 
%d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index d367097f490b..e9a9bbf44966 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -893,7 +893,7 @@ u8 rtl8723e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl8723e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 08288ac9020a..97ae14d48840 100644
--- 

Re: [PATCH 0/4] Mesh mpm fixes and enhancements

[Julian Calaby]

Hi Yaniv,

On Tue, Jun 28, 2016 at 9:13 PM, Yaniv Machani  wrote:
> This patch set is addressing some issues found in the current 802.11s 
> implementation,
> specifically when using hostap mpm.
> It's aligning the beacon format and handling some corner cases.
>
> Maital Hahn (2):
>   mac80211: mesh: flush stations before beacons are stopped
>   mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting
>
> Meirav Kama (2):
>   mac80211: mesh: fixed HT ies in beacon template
>   mac80211: sta_info: max_peers reached falsely

Patches that you send must be signed off by you, not ack'd by you.

I.e.

From: Random Developer 

.

Signed-off-by: Random Developer 
Signed-off-by: Patch Sender 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [linux-next] rtlwifi: Fix typo in printk

[Julian Calaby]

Hi All,

On Wed, Jun 29, 2016 at 1:37 PM, Masanari Iida  wrote:
> This patch fix spelling typos found in drivers/net/wireless/realtek.
>
> Signed-off-by: Masanari Iida 

Looks right to me.

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [linux-next] rtlwifi: Fix typo in printk

[Masanari Iida]

This patch fix spelling typos found in drivers/net/wireless/realtek.

Signed-off-by: Masanari Iida 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c| 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
index 416a9ba6382e..422c7813f5ee 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1239,7 +1239,7 @@ u8 rtl88e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl88e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current 
channel %d\n",
+"sw_chnl_inprogress false schedule workitem current 
channel %d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index 77e61b19bf36..9301583ce768 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -757,7 +757,7 @@ u8 rtl92c_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92c_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
index 459f3d0efa2f..0a5c9fcfe73b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/dm.c
@@ -496,7 +496,7 @@ static void rtl92ee_dm_find_minimum_rssi(struct 
ieee80211_hw *hw)
rtl_dm_dig->min_undec_pwdb_for_dm =
rtlpriv->dm.entry_min_undec_sm_pwdb;
RT_TRACE(rtlpriv, COMP_BB_POWERSAVING, DBG_LOUD,
-"AP Ext Port or disconnet PWDB = 0x%x\n",
+"AP Ext Port or disconnect PWDB = 0x%x\n",
 rtl_dm_dig->min_undec_pwdb_for_dm);
}
RT_TRACE(rtlpriv, COMP_DIG, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index c2bf8d1a7af3..97d9a8e209f1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -1819,7 +1819,7 @@ u8 rtl92ee_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl92ee_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem current 
channel %d\n",
+"sw_chnl_inprogress false schedule workitem current 
channel %d\n",
 rtlphy->current_channel);
rtlphy->sw_chnl_inprogress = false;
} else {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index d367097f490b..e9a9bbf44966 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -893,7 +893,7 @@ u8 rtl8723e_phy_sw_chnl(struct ieee80211_hw *hw)
if (!(is_hal_stop(rtlhal)) && !(RT_CANNOT_IO(hw))) {
rtl8723e_phy_sw_chnl_callback(hw);
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
-"sw_chnl_inprogress false schdule workitem\n");
+"sw_chnl_inprogress false schedule workitem\n");
rtlphy->sw_chnl_inprogress = false;
} else {
RT_TRACE(rtlpriv, COMP_CHAN, DBG_LOUD,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 08288ac9020a..97ae14d48840 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1474,7 +1474,7 @@ static enum version_8723e 

Re: [PATCH] mac80211: ensure info->control.vif is set for queued pkts.

[Ben Greear]

On 06/28/2016 01:03 PM, Johannes Berg wrote:

On Tue, 2016-06-28 at 07:50 -0700, Ben Greear wrote:


So, maybe a WARN_ON would be appropriate at the place frames are
enqueued in the backlog queue?  Since this patch did fix my problem,
maybe that WARN_ON would show the path that allow frames with bad
control.vif to be inserted?


Yeah that might make sense, if you're willing to test that.


I had also found another problem with pktgen using the headroom
wrong, so possibly that would have also fixed my problem..I'm not
sure which patch I put in first.



That seems very unlikely to be related.


Well, it was very easy to reproduce:  Just over-drive tx on a station
using pktgen.  My pktgen is modified, but nothing that should affect
this bug as far as I know.

I can retest with a WARN_ON, but will be a week or two before I'm back in the 
office.

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] wlcore: spi: add wl18xx support

[Rob Herring]

On Sun, Jun 26, 2016 at 10:10:54AM +, Reizer, Eyal wrote:
> Add support for using with both wl12xx and wl18xx.
> 
> - all wilink family needs special init command for entering wspi mode.
>   extra clock cycles should be sent after the spi init command while the
>   cs pin is high.
> - Use inverted chip select for sending a dummy 4 bytes command that
>   completes the init stage.
> 
> Signed-off-by: Eyal Reizer 
> ---
> v1->v2:update device tree bindings configuration
> v2->v3:revert from manual gpio manipulation. use inverted chip select instead
> for sending the extra init cycle which, achieves the same hardware purpose.
> update device tree bindings docucmentation accordingly
> v3->v4: Remove redundant data form binding documentation and fix chip select
> number mismatch in wl1271 example
> 
>  .../bindings/net/wireless/ti,wlcore,spi.txt|  41 +--

Acked-by: Rob Herring 

>  drivers/net/wireless/ti/wlcore/spi.c   | 124 
> +
>  2 files changed, 137 insertions(+), 28 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: ensure info->control.vif is set for queued pkts.

[Johannes Berg]

On Tue, 2016-06-28 at 07:50 -0700, Ben Greear wrote:

> So, maybe a WARN_ON would be appropriate at the place frames are
> enqueued in the backlog queue?  Since this patch did fix my problem,
> maybe that WARN_ON would show the path that allow frames with bad
> control.vif to be inserted?

Yeah that might make sense, if you're willing to test that.

> I had also found another problem with pktgen using the headroom
> wrong, so possibly that would have also fixed my problem..I'm not
> sure which patch I put in first.
> 

That seems very unlikely to be related.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libertas_tf: Remove create_workqueue

[Kalle Valo]

Bhaktipriya Shridhar  writes:

> Ping!

I'm lagging behind, the patch is still on my queue:

https://patchwork.kernel.org/patch/9162447/

Please don't top most, it's annoying.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libertas_tf: Remove create_workqueue

[Bhaktipriya Shridhar]

Ping!
Thanks,
Bhaktipriya


On Sun, Jun 12, 2016 at 4:17 AM, Tejun Heo  wrote:
> On Wed, Jun 08, 2016 at 01:38:53AM +0530, Bhaktipriya Shridhar wrote:
>> alloc_workqueue replaces deprecated create_workqueue().
>>
>> A dedicated workqueue has been used since the workitem (viz
>> >cmd_work per priv, which maps to lbtf_cmd_work) is involved in
>> actual command processing and may be used on a memory reclaim path.
>> The workitems require forward progress under memory pressure and hence,
>> WQ_MEM_RECLAIM has been set. Since there are only a fixed number of work
>> items, explicit concurrency limit is unnecessary here.
>>
>> Signed-off-by: Bhaktipriya Shridhar 
>
> Acked-by: Tejun Heo 
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: ensure info->control.vif is set for queued pkts.

[Krishna Chaitanya]

On Tue, Jun 28, 2016 at 8:20 PM, Ben Greear  wrote:
> On 06/28/2016 07:00 AM, Johannes Berg wrote:
>>
>> On Wed, 2016-06-15 at 11:24 -0700, gree...@candelatech.com wrote:
>>>
>>> From: Ben Greear 
>>>
>>> When driving ath10k with a modified pktgen, we see excessive amounts
>>> of these warnings:
>>>
>>> Jun  6 13:47:53 localhost kernel: WARNING: CPU: 1 PID: 1186 at
>>> /home/greearb/git/linux-4.4.dev.y/net/mac80211/tx.c:3
>>> 125 ieee80211_tx_pending+0x9d/0x19e [mac80211]()
>>> Jun  6 13:47:53 localhost kernel: Modules linked in:
>>> nf_conntrack_netlink nfnetlink nf_conntrack_ipv4 iptable_raw xt
>>> _CT nf_conntrack nf_defrag_ipv4 8021q garp mrp stp llc bnep bluetooth
>>> fuse macvlan wanlink(O) pktgen ip6table_filter
>>>   ip6_tables ebtable_nat ebtables snd_hda_codec_hdmi
>>> snd_hda_codec_realtek snd_hda_codec_generic ath10k_pci ath10k_co
>>> re snd_hda_intel snd_hda_codec coretemp hwmon intel_rapl iosf_mbi
>>> x86_pkg_temp_thermal intel_powerclamp kvm_intel sn
>>> d_hda_core ath iTCO_wdt iTCO_vendor_support mac80211 kvm cfg80211
>>> snd_hwdep e1000e snd_seq cdc_acm snd_seq_device sn
>>> d_pcm irqbypass serio_raw pcspkr ptp i2c_i801 pps_core snd_timer snd
>>> soundcore 8250_fintek shpchp fjes lpc_ich tpm_t
>>> is tpm uinput ipv6 i915 i2c_algo_bit drm_kms_helper drm i2c_core
>>> video [last unloaded: nfnetlink]
>>> Jun  6 13:47:53 localhost kernel: CPU: 1 PID: 1186 Comm: kpktgend_1
>>> Tainted: GW  O4.4.11+ #50
>>> Jun  6 13:47:53 localhost kernel: Hardware name: To be filled by
>>> O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.
>>> 5 06/07/2013
>>> Jun  6 13:47:53 localhost kernel:  88021e243e68
>>> 81340d35 
>>> Jun  6 13:47:53 localhost kernel: 0009 88021e243ea0
>>> 810e
>>> a46e a0b1cb0e
>>> Jun  6 13:47:53 localhost kernel: 880213a41600 880213a406e0
>>> 8800c8ac1700 88021e243ed8
>>> Jun  6 13:47:53 localhost kernel: Call Trace:
>>> Jun  6 13:47:53 localhost kernel:  []
>>> dump_stack+0x63/0x7f
>>> Jun  6 13:47:53 localhost kernel: []
>>> warn_slowpath_common+0x94/0xad
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> ieee80211_tx_pending+0x9d/0x19e [mac80211]
>>> Jun  6 13:47:53 localhost kernel: []
>>> warn_slowpath_null+0x15/0x17
>>> Jun  6 13:47:53 localhost kernel: []
>>> ieee80211_tx_pending+0x9d/0x19e [mac80211]
>>> Jun  6 13:47:53 localhost kernel: []
>>> tasklet_action+0xae/0xbf
>>> Jun  6 13:47:53 localhost kernel: []
>>> __do_softirq+0x109/0x26d
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> rcu_irq_exit+0x3d/0x40
>>> Jun  6 13:47:53 localhost kernel: []
>>> do_softirq_own_stack+0x1c/0x30
>>> Jun  6 13:47:53 localhost kernel:  []
>>> do_softirq+0x30/0x3b
>>> Jun  6 13:47:53 localhost kernel: []
>>> __local_bh_enable_ip+0x69/0x83
>>> Jun  6 13:47:53 localhost kernel: []
>>> pktgen_thread_worker+0x1399/0x1f26 [pktgen]
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> __schedule+0x3c1/0x585
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> finish_wait+0x5d/0x5d
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> pktgen_rem_all_ifs+0x6a/0x6a [pktgen]
>>> Jun  6 13:47:53 localhost kernel: []
>>> kthread+0xa0/0xa8
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> kthread_parkme+0x1f/0x1f
>>> Jun  6 13:47:53 localhost kernel: []
>>> ret_from_fork+0x3f/0x70
>>> Jun  6 13:47:53 localhost kernel: [] ?
>>> kthread_parkme+0x1f/0x1f
>>> Jun  6 13:47:53 localhost kernel: ---[ end trace a5fa4429cf1b918b ]
>>> ---
>>> Jun  6 13:47:53 localhost kernel: [ cut here ]---
>>> -
>>>
>>> I think the problem is that the logic that inserts the packet into
>>> the pending
>>> queue is not setting the vif in the skb info struct.  This patch
>>> appears to
>>> fix the problem.
>>>
>>> Signed-off-by: Ben Greear 
>>> ---
>>>
>>> Please review this well, looks like this code has been this way for a
>>> long time,
>>> and this was reproduced and tested on a kernel with a lot of wifi,
>>> pktgen, and ath10k
>>> patches.
>>
>>
>> I'm not convinced this patch is correct. control.vif is always set,
>> already since ieee80211_tx_prepare_skb(). It's *changed* to the looked-
>> up interface in case of monitor/VLAN within __ieee80211_tx()
>> and ieee80211_tx_frags(), but otherwise __ieee80211_tx() will leave it
>> completely identical:
>>
>> sdata = vif_to_sdata(info->control.vif);
>> [...]
>> switch (iftype) {
>> [...]
>> default:
>> vif = >vif;
>> }
>>
>> so the control.vif assignment is a no-op in almost all cases.
>
>
> So, maybe a WARN_ON would be appropriate at the place frames are enqueued
> in the backlog queue?  Since this patch did fix my problem, maybe that
> WARN_ON
> would show the path that allow frames with bad control.vif to be inserted?
>
> I had also found another problem with pktgen using the headroom wrong, so
> possibly
> that would have also fixed my problem..I'm not sure which patch I put in
> first.
>
 A while 

Re: [PATCH] mac80211: ensure info->control.vif is set for queued pkts.

[Ben Greear]

On 06/28/2016 07:00 AM, Johannes Berg wrote:

On Wed, 2016-06-15 at 11:24 -0700, gree...@candelatech.com wrote:

From: Ben Greear 

When driving ath10k with a modified pktgen, we see excessive amounts
of these warnings:

Jun  6 13:47:53 localhost kernel: WARNING: CPU: 1 PID: 1186 at
/home/greearb/git/linux-4.4.dev.y/net/mac80211/tx.c:3
125 ieee80211_tx_pending+0x9d/0x19e [mac80211]()
Jun  6 13:47:53 localhost kernel: Modules linked in:
nf_conntrack_netlink nfnetlink nf_conntrack_ipv4 iptable_raw xt
_CT nf_conntrack nf_defrag_ipv4 8021q garp mrp stp llc bnep bluetooth
fuse macvlan wanlink(O) pktgen ip6table_filter
  ip6_tables ebtable_nat ebtables snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic ath10k_pci ath10k_co
re snd_hda_intel snd_hda_codec coretemp hwmon intel_rapl iosf_mbi
x86_pkg_temp_thermal intel_powerclamp kvm_intel sn
d_hda_core ath iTCO_wdt iTCO_vendor_support mac80211 kvm cfg80211
snd_hwdep e1000e snd_seq cdc_acm snd_seq_device sn
d_pcm irqbypass serio_raw pcspkr ptp i2c_i801 pps_core snd_timer snd
soundcore 8250_fintek shpchp fjes lpc_ich tpm_t
is tpm uinput ipv6 i915 i2c_algo_bit drm_kms_helper drm i2c_core
video [last unloaded: nfnetlink]
Jun  6 13:47:53 localhost kernel: CPU: 1 PID: 1186 Comm: kpktgend_1
Tainted: GW  O4.4.11+ #50
Jun  6 13:47:53 localhost kernel: Hardware name: To be filled by
O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.
5 06/07/2013
Jun  6 13:47:53 localhost kernel:  88021e243e68
81340d35 
Jun  6 13:47:53 localhost kernel: 0009 88021e243ea0
810e
a46e a0b1cb0e
Jun  6 13:47:53 localhost kernel: 880213a41600 880213a406e0
8800c8ac1700 88021e243ed8
Jun  6 13:47:53 localhost kernel: Call Trace:
Jun  6 13:47:53 localhost kernel:  []
dump_stack+0x63/0x7f
Jun  6 13:47:53 localhost kernel: []
warn_slowpath_common+0x94/0xad
Jun  6 13:47:53 localhost kernel: [] ?
ieee80211_tx_pending+0x9d/0x19e [mac80211]
Jun  6 13:47:53 localhost kernel: []
warn_slowpath_null+0x15/0x17
Jun  6 13:47:53 localhost kernel: []
ieee80211_tx_pending+0x9d/0x19e [mac80211]
Jun  6 13:47:53 localhost kernel: []
tasklet_action+0xae/0xbf
Jun  6 13:47:53 localhost kernel: []
__do_softirq+0x109/0x26d
Jun  6 13:47:53 localhost kernel: [] ?
rcu_irq_exit+0x3d/0x40
Jun  6 13:47:53 localhost kernel: []
do_softirq_own_stack+0x1c/0x30
Jun  6 13:47:53 localhost kernel:  []
do_softirq+0x30/0x3b
Jun  6 13:47:53 localhost kernel: []
__local_bh_enable_ip+0x69/0x83
Jun  6 13:47:53 localhost kernel: []
pktgen_thread_worker+0x1399/0x1f26 [pktgen]
Jun  6 13:47:53 localhost kernel: [] ?
__schedule+0x3c1/0x585
Jun  6 13:47:53 localhost kernel: [] ?
finish_wait+0x5d/0x5d
Jun  6 13:47:53 localhost kernel: [] ?
pktgen_rem_all_ifs+0x6a/0x6a [pktgen]
Jun  6 13:47:53 localhost kernel: []
kthread+0xa0/0xa8
Jun  6 13:47:53 localhost kernel: [] ?
kthread_parkme+0x1f/0x1f
Jun  6 13:47:53 localhost kernel: []
ret_from_fork+0x3f/0x70
Jun  6 13:47:53 localhost kernel: [] ?
kthread_parkme+0x1f/0x1f
Jun  6 13:47:53 localhost kernel: ---[ end trace a5fa4429cf1b918b ]
---
Jun  6 13:47:53 localhost kernel: [ cut here ]---
-

I think the problem is that the logic that inserts the packet into
the pending
queue is not setting the vif in the skb info struct.  This patch
appears to
fix the problem.

Signed-off-by: Ben Greear 
---

Please review this well, looks like this code has been this way for a
long time,
and this was reproduced and tested on a kernel with a lot of wifi,
pktgen, and ath10k
patches.


I'm not convinced this patch is correct. control.vif is always set,
already since ieee80211_tx_prepare_skb(). It's *changed* to the looked-
up interface in case of monitor/VLAN within __ieee80211_tx()
and ieee80211_tx_frags(), but otherwise __ieee80211_tx() will leave it
completely identical:

sdata = vif_to_sdata(info->control.vif);
[...]
switch (iftype) {
[...]
default:
vif = >vif;
}

so the control.vif assignment is a no-op in almost all cases.


So, maybe a WARN_ON would be appropriate at the place frames are enqueued
in the backlog queue?  Since this patch did fix my problem, maybe that WARN_ON
would show the path that allow frames with bad control.vif to be inserted?

I had also found another problem with pktgen using the headroom wrong, so 
possibly
that would have also fixed my problem..I'm not sure which patch I put in first.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/4] mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting

[Machani, Yaniv]

On Tue, Jun 28, 2016 at 15:27:47, Bob Copeland wrote:
> linux- wirel...@vger.kernel.org; net...@vger.kernel.org; Hahn, Maital
> Subject: Re: [PATCH 2/4] mac80211/cfg: mesh: fix healing time when a 
> mesh peer is disconnecting
> 
> On Tue, Jun 28, 2016 at 02:13:05PM +0300, Yaniv Machani wrote:
> > From: Maital Hahn 
> >
> > Once receiving a CLOSE action frame from the disconnecting peer, 
> > flush all entries in the path table which has this peer as the next hop.
> 
> Please address the user-visible behavior in your commit messages.
> Does it crash?  Does it send frames to an invalid peer?  Do frames get 
> dropped?
> 

Hi Bob,
It was a crash, apparently already fixed by your patches some time ago.
I'll remove that part and resend the 2nd part (with some more 'why', and less 
typos..)

> > In addition, upon receiving a packet, if next hop is not found, 
> > trigger PERQ immidiatly, instead of just putting it in the queue.
> 
> "PREQ"
> 
> Please split this into a separate patch that we can review separately 
> (and also give the "why" in the commit log).
> 
> > @@ -1011,6 +1011,7 @@ static void sta_apply_mesh_params(struct
> ieee80211_local *local,
> > if (sta->mesh->plink_state == NL80211_PLINK_ESTAB)
> > changed =
> mesh_plink_dec_estab_count(sdata);
> > sta->mesh->plink_state = params->plink_state;
> > +   mesh_path_flush_by_nexthop(sta);
> 
> This isn't necessary, caller should already be doing
> mesh_path_flush_by_nexthop() in every case I could see.  Besides it 
> cannot be done under plink lock.
> 

I believe this was fixed in your patch "mac80211: mesh: flush paths outside of 
plink lock"
There is probably no need in that on the latest as well.

Thanks,
Yaniv
 


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size

[Larry Finger]

On 06/27/2016 10:55 PM, Joe Perches wrote:

On Mon, 2016-06-27 at 19:53 -0500, Larry Finger wrote:

On 06/25/2016 05:46 PM, Joe Perches wrote:


This debugging macro can expand to a lot of code.
Make it a function to reduce code size.

(x86-64 defconfig w/ all rtlwifi drivers and allyesconfig)
$ size drivers/net/wireless/realtek/rtlwifi/built-in.o*
 text  data bss dec hex filename
   9000832004991907 1102489  10d299 
drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.new
1113597  2004991907 1316003  1414a3 
drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.old
1746879  4535038512 2208894  21b47e 
drivers/net/wireless/realtek/rtlwifi/built-in.o.new
2051965  5033118512 2563788  271ecc 
drivers/net/wireless/realtek/rtlwifi/built-in.o.old

Signed-off-by: Joe Perches 

I acked this before; however there is a bug that breaks the build if
CONFIG_RTLWIFI_DEBUG is not defined. The rest of the code calls
_rtl_dbg_trace(), but that symbol is never defined. The problem can be fixed in
debug.c or debug.h.


Confused a bit.  What breaks again?


Nothing breaks and your patch is OK. I had ported it to a GitHub repo of these 
drivers, which had a different debug.h. That led to the missing global when 
CONFIG_RTLWIFI_DEBUG was not defined. That has now been fixed.


Sorry for the confusion.

Larry


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template

[Bob Copeland]

On Tue, Jun 28, 2016 at 02:13:06PM +0300, Yaniv Machani wrote:
> From: Meirav Kama 
> 
> There are several values in HT info elements of mesh beacon (built by the
> mac80211) that are incorrect.

Would be good to enumerate the problems here.

> To fix them:
> 1. mac80211 will check configuration from cfg and will build accordingly.
> 2. changes made in mesh default values.

What is wrong with the defaults?

>   sband = local->hw.wiphy->bands[band];
>   if (!sband->ht_cap.ht_supported ||
> @@ -431,11 +433,40 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data 
> *sdata,
>   sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
>   return 0;
>  
> +/* determine capability flags */
> + cap = sband->ht_cap.cap;

There is some weird whitespace here (space instead of tabs for the
comment).

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: ensure info->control.vif is set for queued pkts.

[Johannes Berg]

On Wed, 2016-06-15 at 11:24 -0700, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> When driving ath10k with a modified pktgen, we see excessive amounts
> of these warnings:
> 
> Jun  6 13:47:53 localhost kernel: WARNING: CPU: 1 PID: 1186 at
> /home/greearb/git/linux-4.4.dev.y/net/mac80211/tx.c:3
> 125 ieee80211_tx_pending+0x9d/0x19e [mac80211]()
> Jun  6 13:47:53 localhost kernel: Modules linked in:
> nf_conntrack_netlink nfnetlink nf_conntrack_ipv4 iptable_raw xt
> _CT nf_conntrack nf_defrag_ipv4 8021q garp mrp stp llc bnep bluetooth
> fuse macvlan wanlink(O) pktgen ip6table_filter
>  ip6_tables ebtable_nat ebtables snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_codec_generic ath10k_pci ath10k_co
> re snd_hda_intel snd_hda_codec coretemp hwmon intel_rapl iosf_mbi
> x86_pkg_temp_thermal intel_powerclamp kvm_intel sn
> d_hda_core ath iTCO_wdt iTCO_vendor_support mac80211 kvm cfg80211
> snd_hwdep e1000e snd_seq cdc_acm snd_seq_device sn
> d_pcm irqbypass serio_raw pcspkr ptp i2c_i801 pps_core snd_timer snd
> soundcore 8250_fintek shpchp fjes lpc_ich tpm_t
> is tpm uinput ipv6 i915 i2c_algo_bit drm_kms_helper drm i2c_core
> video [last unloaded: nfnetlink]
> Jun  6 13:47:53 localhost kernel: CPU: 1 PID: 1186 Comm: kpktgend_1
> Tainted: GW  O4.4.11+ #50
> Jun  6 13:47:53 localhost kernel: Hardware name: To be filled by
> O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.
> 5 06/07/2013
> Jun  6 13:47:53 localhost kernel:  88021e243e68
> 81340d35 
> Jun  6 13:47:53 localhost kernel: 0009 88021e243ea0
> 810e
> a46e a0b1cb0e
> Jun  6 13:47:53 localhost kernel: 880213a41600 880213a406e0
> 8800c8ac1700 88021e243ed8
> Jun  6 13:47:53 localhost kernel: Call Trace:
> Jun  6 13:47:53 localhost kernel:  []
> dump_stack+0x63/0x7f
> Jun  6 13:47:53 localhost kernel: []
> warn_slowpath_common+0x94/0xad
> Jun  6 13:47:53 localhost kernel: [] ?
> ieee80211_tx_pending+0x9d/0x19e [mac80211]
> Jun  6 13:47:53 localhost kernel: []
> warn_slowpath_null+0x15/0x17
> Jun  6 13:47:53 localhost kernel: []
> ieee80211_tx_pending+0x9d/0x19e [mac80211]
> Jun  6 13:47:53 localhost kernel: []
> tasklet_action+0xae/0xbf
> Jun  6 13:47:53 localhost kernel: []
> __do_softirq+0x109/0x26d
> Jun  6 13:47:53 localhost kernel: [] ?
> rcu_irq_exit+0x3d/0x40
> Jun  6 13:47:53 localhost kernel: []
> do_softirq_own_stack+0x1c/0x30
> Jun  6 13:47:53 localhost kernel:  []
> do_softirq+0x30/0x3b
> Jun  6 13:47:53 localhost kernel: []
> __local_bh_enable_ip+0x69/0x83
> Jun  6 13:47:53 localhost kernel: []
> pktgen_thread_worker+0x1399/0x1f26 [pktgen]
> Jun  6 13:47:53 localhost kernel: [] ?
> __schedule+0x3c1/0x585
> Jun  6 13:47:53 localhost kernel: [] ?
> finish_wait+0x5d/0x5d
> Jun  6 13:47:53 localhost kernel: [] ?
> pktgen_rem_all_ifs+0x6a/0x6a [pktgen]
> Jun  6 13:47:53 localhost kernel: []
> kthread+0xa0/0xa8
> Jun  6 13:47:53 localhost kernel: [] ?
> kthread_parkme+0x1f/0x1f
> Jun  6 13:47:53 localhost kernel: []
> ret_from_fork+0x3f/0x70
> Jun  6 13:47:53 localhost kernel: [] ?
> kthread_parkme+0x1f/0x1f
> Jun  6 13:47:53 localhost kernel: ---[ end trace a5fa4429cf1b918b ]
> ---
> Jun  6 13:47:53 localhost kernel: [ cut here ]---
> -
> 
> I think the problem is that the logic that inserts the packet into
> the pending
> queue is not setting the vif in the skb info struct.  This patch
> appears to
> fix the problem.
> 
> Signed-off-by: Ben Greear 
> ---
> 
> Please review this well, looks like this code has been this way for a
> long time,
> and this was reproduced and tested on a kernel with a lot of wifi,
> pktgen, and ath10k
> patches.

I'm not convinced this patch is correct. control.vif is always set,
already since ieee80211_tx_prepare_skb(). It's *changed* to the looked-
up interface in case of monitor/VLAN within __ieee80211_tx()
and ieee80211_tx_frags(), but otherwise __ieee80211_tx() will leave it
completely identical:

sdata = vif_to_sdata(info->control.vif);
[...]
switch (iftype) {
[...]
default:
vif = >vif;
}

so the control.vif assignment is a no-op in almost all cases.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 4/4] mac80211: sta_info: max_peers reached falsely

[Machani, Yaniv]

On Tue, Jun 28, 2016 at 15:56:21, Bob Copeland wrote:
> linux- wirel...@vger.kernel.org; net...@vger.kernel.org; Kama, Meirav
> Subject: Re: [PATCH 4/4] mac80211: sta_info: max_peers reached falsely
> 
> On Tue, Jun 28, 2016 at 02:13:07PM +0300, Yaniv Machani wrote:
> > From: Meirav Kama 
> >
> > Issue happened when receiving delete_sta command without changing 
> > plink_state from ESTAB to HOLDING before.
> > When receiving delete_sta command for mesh interface verify 
> > plink_state is not ESTAB and if so, decrease plink count and update 
> > beacon.
> 
> This should be fixed already (and properly) by the patch
> "mac80211: Fix mesh estab links counting" -- please let us know if you 
> have a case that's still broken with that fix.
> 

Thanks Bob,
Will be dropped.

Yaniv
> --
> Bob Copeland %% http://bobcopeland.com/


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] mac80211: sta_info: max_peers reached falsely

[Bob Copeland]

On Tue, Jun 28, 2016 at 02:13:07PM +0300, Yaniv Machani wrote:
> From: Meirav Kama 
> 
> Issue happened when receiving delete_sta command without
> changing plink_state from ESTAB to HOLDING before.
> When receiving delete_sta command for mesh interface
> verify plink_state is not ESTAB and if so, decrease
> plink count and update beacon.

This should be fixed already (and properly) by the patch
"mac80211: Fix mesh estab links counting" -- please let us
know if you have a case that's still broken with that fix.

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting

[Bob Copeland]

On Tue, Jun 28, 2016 at 02:13:05PM +0300, Yaniv Machani wrote:
> From: Maital Hahn 
> 
> Once receiving a CLOSE action frame from the disconnecting peer,
> flush all entries in the path table which has this peer as the
> next hop.

Please address the user-visible behavior in your commit messages.
Does it crash?  Does it send frames to an invalid peer?  Do
frames get dropped?

> In addition, upon receiving a packet, if next hop is not found,
> trigger PERQ immidiatly, instead of just putting it in the queue.

"PREQ"

Please split this into a separate patch that we can review
separately (and also give the "why" in the commit log).

> Signed-off-by: Maital Hahn 
> Acked-by: Yaniv Machani 
> ---
>  net/mac80211/cfg.c   |  1 +
>  net/mac80211/mesh.c  |  3 ++-
>  net/mac80211/mesh_hwmp.c | 42 +-
>  3 files changed, 28 insertions(+), 18 deletions(-)
> 
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 0c12e40..f876ef7 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1011,6 +1011,7 @@ static void sta_apply_mesh_params(struct 
> ieee80211_local *local,
>   if (sta->mesh->plink_state == NL80211_PLINK_ESTAB)
>   changed = mesh_plink_dec_estab_count(sdata);
>   sta->mesh->plink_state = params->plink_state;
> + mesh_path_flush_by_nexthop(sta);

This isn't necessary, caller should already be doing
mesh_path_flush_by_nexthop() in every case I could see.  Besides it
cannot be done under plink lock.

> +++ b/net/mac80211/mesh.c
> @@ -159,7 +159,8 @@ void mesh_sta_cleanup(struct sta_info *sta)
>   if (!sdata->u.mesh.user_mpm) {
>   changed |= mesh_plink_deactivate(sta);
>   del_timer_sync(>mesh->plink_timer);
> - }
> + } else
> + mesh_path_flush_by_nexthop(sta);

And this is already fixed in mac80211-next.

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Use macro instead of number

[Johannes Berg]

On Wed, 2016-06-22 at 20:23 +0900, Masashi Honma wrote:
> Use IEEE80211_MIN_ACTION_SIZE macro for robust management frame
> check.
> 
Applied.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] mac80211: silence an uninitialize variable warning

[Johannes Berg]

On Mon, 2016-06-27 at 17:31 +0300, Dan Carpenter wrote:
> We normally return an unitialized value, but no one checks it so it
> doesn't matter.  Anyway, let's silence the static checker warning.
> 

Applied.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: rx: frames received out of order

[Yaniv Machani]

From: Meirav Kama 

MP received data frames from another MP. Frames are forwarded
from Rx to Tx to be transmitted to a third MP.
Upon cloning the skb, the tx_info was zeroed, and the
hw_queue wasn't set correctly, causing frames to be
inserted to queue 0 (VOICE). If re-queue occurred for some
reason, frame will be inserted to correct queue 2 (BE).
In this case frames are now dequeued from 2 different queues and
sent out of order.

Signed-off-by: Meirav Kama 
Acked-by: Yaniv Machani 
---
 net/mac80211/rx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9a1eb70..88dc744 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2392,6 +2392,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = >sdata->vif;
info->control.jiffies = jiffies;
+   info->hw_queue = q;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, fwded_mcast);
memcpy(fwd_hdr->addr2, sdata->vif.addr, ETH_ALEN);
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: util: mesh is not connected properly after recovery

[Yaniv Machani]

From: Maital Hahn 

In the reconfigure process for mesh interface, moved the reconfiguration
of the mesh peers to be done only after restarting the beacons,
the same as it is done for AP.

Signed-off-by: Maital Hahn 
Acked-by: Yaniv Machani 
---
 net/mac80211/util.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 5375a82..2431684 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1910,6 +1910,7 @@ int ieee80211_reconfig(struct ieee80211_local *local)
ieee80211_reconfig_stations(sdata);
/* fall through */
case NL80211_IFTYPE_AP: /* AP stations are handled later */
+   case NL80211_IFTYPE_MESH_POINT: /* MP peers are handled later */
for (i = 0; i < IEEE80211_NUM_ACS; i++)
drv_conf_tx(local, sdata, i,
>tx_conf[i]);
@@ -2013,7 +2014,8 @@ int ieee80211_reconfig(struct ieee80211_local *local)
if (!sta->uploaded)
continue;
 
-   if (sta->sdata->vif.type != NL80211_IFTYPE_AP)
+   if ((sta->sdata->vif.type != NL80211_IFTYPE_AP) &&
+   (sta->sdata->vif.type != NL80211_IFTYPE_MESH_POINT))
continue;
 
for (state = IEEE80211_STA_NOTEXIST;
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped

[Yaniv Machani]

From: Maital Hahn 

Some drivers (e.g. wl18xx) expect that the last stage in the
de-initialization process will be stopping the beacons, similar to ap.
Update ieee80211_stop_mesh() flow accordingly.

Signed-off-by: Maital Hahn 
Acked-by: Yaniv Machani 
---
 net/mac80211/mesh.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 21b1fdf..9214bc1 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -896,20 +896,22 @@ void ieee80211_stop_mesh(struct ieee80211_sub_if_data 
*sdata)
 
netif_carrier_off(sdata->dev);
 
+   /* flush STAs and mpaths on this iface */
+   sta_info_flush(sdata);
+   mesh_path_flush_by_iface(sdata);
+
/* stop the beacon */
ifmsh->mesh_id_len = 0;
sdata->vif.bss_conf.enable_beacon = false;
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, >state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
+
+   /* remove beacon */
bcn = rcu_dereference_protected(ifmsh->beacon,
lockdep_is_held(>wdev.mtx));
RCU_INIT_POINTER(ifmsh->beacon, NULL);
kfree_rcu(bcn, rcu_head);
 
-   /* flush STAs and mpaths on this iface */
-   sta_info_flush(sdata);
-   mesh_path_flush_by_iface(sdata);
-
/* free all potentially still buffered group-addressed frames */
local->total_ps_buffered -= skb_queue_len(>ps.bc_buf);
skb_queue_purge(>ps.bc_buf);
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] Mesh mpm fixes and enhancements

[Yaniv Machani]

This patch set is addressing some issues found in the current 802.11s 
implementation,
specifically when using hostap mpm. 
It's aligning the beacon format and handling some corner cases.

Maital Hahn (2):
  mac80211: mesh: flush stations before beacons are stopped
  mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting

Meirav Kama (2):
  mac80211: mesh: fixed HT ies in beacon template
  mac80211: sta_info: max_peers reached falsely

 net/mac80211/cfg.c   |  1 +
 net/mac80211/mesh.c  | 46 --
 net/mac80211/mesh_hwmp.c | 42 +-
 net/mac80211/sta_info.c  | 14 ++
 net/mac80211/util.c  |  3 ---
 net/wireless/mesh.c  |  2 +-
 6 files changed, 81 insertions(+), 27 deletions(-)

-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template

[Yaniv Machani]

From: Meirav Kama 

There are several values in HT info elements of mesh beacon (built by the
mac80211) that are incorrect.
To fix them:
1. mac80211 will check configuration from cfg and will build accordingly.
2. changes made in mesh default values.

Signed-off-by: Meirav Kama 
Acked-by: Yaniv Machani 
---
 net/mac80211/mesh.c | 33 -
 net/mac80211/util.c |  3 ---
 net/wireless/mesh.c |  2 +-
 3 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 1f5be54..1b63b11 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -423,6 +423,8 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data *sdata,
enum nl80211_band band = ieee80211_get_sdata_band(sdata);
struct ieee80211_supported_band *sband;
u8 *pos;
+   u16 cap;
+
 
sband = local->hw.wiphy->bands[band];
if (!sband->ht_cap.ht_supported ||
@@ -431,11 +433,40 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data 
*sdata,
sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
return 0;
 
+/* determine capability flags */
+   cap = sband->ht_cap.cap;
+
+/* if channel width is 20MHz - configure HT capab accordingly*/
+   if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
+   cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+   cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
+   }
+
+   /* set SM PS mode properly */
+   cap &= ~IEEE80211_HT_CAP_SM_PS;
+   switch (sdata->smps_mode) {
+   case IEEE80211_SMPS_AUTOMATIC:
+   case IEEE80211_SMPS_NUM_MODES:
+   WARN_ON(1);
+   case IEEE80211_SMPS_OFF:
+   cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   case IEEE80211_SMPS_STATIC:
+   cap |= WLAN_HT_CAP_SM_PS_STATIC <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   case IEEE80211_SMPS_DYNAMIC:
+   cap |= WLAN_HT_CAP_SM_PS_DYNAMIC <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   }
+
if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
return -ENOMEM;
 
pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_cap));
-   ieee80211_ie_build_ht_cap(pos, >ht_cap, sband->ht_cap.cap);
+   ieee80211_ie_build_ht_cap(pos, >ht_cap, cap);
 
return 0;
 }
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 42bf0b6..5375a82 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2349,10 +2349,7 @@ u8 *ieee80211_ie_build_ht_oper(u8 *pos, struct 
ieee80211_sta_ht_cap *ht_cap,
ht_oper->operation_mode = cpu_to_le16(prot_mode);
ht_oper->stbc_param = 0x;
 
-   /* It seems that Basic MCS set and Supported MCS set
-  are identical for the first 10 bytes */
memset(_oper->basic_set, 0, 16);
-   memcpy(_oper->basic_set, _cap->mcs, 10);
 
return pos + sizeof(struct ieee80211_ht_operation);
 }
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index fa2066b..ac19a19 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -70,7 +70,7 @@ const struct mesh_config default_mesh_config = {
.dot11MeshGateAnnouncementProtocol = false,
.dot11MeshForwarding = true,
.rssi_threshold = MESH_RSSI_THRESHOLD,
-   .ht_opmode = IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED,
+   .ht_opmode = IEEE80211_HT_OP_MODE_PROTECTION_NONE,
.dot11MeshHWMPactivePathToRootTimeout = MESH_PATH_TO_ROOT_TIMEOUT,
.dot11MeshHWMProotInterval = MESH_ROOT_INTERVAL,
.dot11MeshHWMPconfirmationInterval = MESH_ROOT_CONFIRMATION_INTERVAL,
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] mac80211: sta_info: max_peers reached falsely

[Yaniv Machani]

From: Meirav Kama 

Issue happened when receiving delete_sta command without
changing plink_state from ESTAB to HOLDING before.
When receiving delete_sta command for mesh interface
verify plink_state is not ESTAB and if so, decrease
plink count and update beacon.

Signed-off-by: Meirav Kama 
Acked-by: Yaniv Machani 
---
 net/mac80211/sta_info.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 76b737d..1ce6320 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1009,11 +1009,25 @@ int sta_info_destroy_addr_bss(struct 
ieee80211_sub_if_data *sdata,
 {
struct sta_info *sta;
int ret;
+#ifdef CONFIG_MAC80211_MESH
+   bool dec_links = false;
+#endif
 
mutex_lock(>local->sta_mtx);
sta = sta_info_get_bss(sdata, addr);
+#ifdef CONFIG_MAC80211_MESH
+   if (sdata->vif.type == NL80211_IFTYPE_MESH_POINT &&
+   sta->mesh->plink_state == NL80211_PLINK_ESTAB)
+   dec_links = true;
+#endif
ret = __sta_info_destroy(sta);
mutex_unlock(>local->sta_mtx);
+#ifdef CONFIG_MAC80211_MESH
+   if (dec_links) {
+   mesh_plink_dec_estab_count(sdata);
+   ieee80211_mbss_info_change_notify(sdata, BSS_CHANGED_BEACON);
+   }
+#endif
 
return ret;
 }
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting

[Yaniv Machani]

From: Maital Hahn 

Once receiving a CLOSE action frame from the disconnecting peer,
flush all entries in the path table which has this peer as the
next hop.

In addition, upon receiving a packet, if next hop is not found,
trigger PERQ immidiatly, instead of just putting it in the queue.

Signed-off-by: Maital Hahn 
Acked-by: Yaniv Machani 
---
 net/mac80211/cfg.c   |  1 +
 net/mac80211/mesh.c  |  3 ++-
 net/mac80211/mesh_hwmp.c | 42 +-
 3 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 0c12e40..f876ef7 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1011,6 +1011,7 @@ static void sta_apply_mesh_params(struct ieee80211_local 
*local,
if (sta->mesh->plink_state == NL80211_PLINK_ESTAB)
changed = mesh_plink_dec_estab_count(sdata);
sta->mesh->plink_state = params->plink_state;
+   mesh_path_flush_by_nexthop(sta);
 
ieee80211_mps_sta_status_update(sta);
changed |= ieee80211_mps_set_sta_local_pm(sta,
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 9214bc1..1f5be54 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -159,7 +159,8 @@ void mesh_sta_cleanup(struct sta_info *sta)
if (!sdata->u.mesh.user_mpm) {
changed |= mesh_plink_deactivate(sta);
del_timer_sync(>mesh->plink_timer);
-   }
+   } else
+   mesh_path_flush_by_nexthop(sta);
 
/* make sure no readers can access nexthop sta from here on */
mesh_path_flush_by_nexthop(sta);
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 8f9c3bd..9783d49 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -19,7 +19,7 @@
 
 #define MAX_PREQ_QUEUE_LEN 64
 
-static void mesh_queue_preq(struct mesh_path *, u8);
+static void mesh_queue_preq(struct mesh_path *, u8, bool);
 
 static inline u32 u32_field_get(const u8 *preq_elem, int offset, bool ae)
 {
@@ -830,7 +830,8 @@ static void hwmp_rann_frame_process(struct 
ieee80211_sub_if_data *sdata,
mhwmp_dbg(sdata,
  "time to refresh root mpath %pM\n",
  orig_addr);
-   mesh_queue_preq(mpath, PREQ_Q_F_START | PREQ_Q_F_REFRESH);
+   mesh_queue_preq(mpath, PREQ_Q_F_START | PREQ_Q_F_REFRESH,
+   false);
mpath->last_preq_to_root = jiffies;
}
 
@@ -925,7 +926,7 @@ void mesh_rx_path_sel_frame(struct ieee80211_sub_if_data 
*sdata,
  * Locking: the function must be called from within a rcu read lock block.
  *
  */
-static void mesh_queue_preq(struct mesh_path *mpath, u8 flags)
+static void mesh_queue_preq(struct mesh_path *mpath, u8 flags, bool immediate)
 {
struct ieee80211_sub_if_data *sdata = mpath->sdata;
struct ieee80211_if_mesh *ifmsh = >u.mesh;
@@ -964,18 +965,24 @@ static void mesh_queue_preq(struct mesh_path *mpath, u8 
flags)
++ifmsh->preq_queue_len;
spin_unlock_bh(>mesh_preq_queue_lock);
 
-   if (time_after(jiffies, ifmsh->last_preq + min_preq_int_jiff(sdata)))
+   if (immediate) {
ieee80211_queue_work(>local->hw, >work);
+   } else {
+   if (time_after(jiffies,
+  ifmsh->last_preq + min_preq_int_jiff(sdata))) {
+   ieee80211_queue_work(>local->hw, >work);
 
-   else if (time_before(jiffies, ifmsh->last_preq)) {
-   /* avoid long wait if did not send preqs for a long time
-* and jiffies wrapped around
-*/
-   ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
-   ieee80211_queue_work(>local->hw, >work);
-   } else
-   mod_timer(>mesh_path_timer, ifmsh->last_preq +
-   min_preq_int_jiff(sdata));
+   } else if (time_before(jiffies, ifmsh->last_preq)) {
+   /* avoid long wait if did not send preqs for a long time
+* and jiffies wrapped around
+*/
+   ifmsh->last_preq = jiffies -
+  min_preq_int_jiff(sdata) - 1;
+   ieee80211_queue_work(>local->hw, >work);
+   } else
+   mod_timer(>mesh_path_timer, ifmsh->last_preq +
+ min_preq_int_jiff(sdata));
+   }
 }
 
 /**
@@ -1110,7 +1117,7 @@ int mesh_nexthop_resolve(struct ieee80211_sub_if_data 
*sdata,
}
 
if (!(mpath->flags & MESH_PATH_RESOLVING))
-   mesh_queue_preq(mpath, PREQ_Q_F_START);
+   mesh_queue_preq(mpath, PREQ_Q_F_START, true);
 
if (skb_queue_len(>frame_queue) 

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

[Johannes Berg]

On Thu, 2016-05-12 at 17:34 +0800, Wei-Ning Huang wrote:
> 
> Johannes, I feel like being able to set calibration data at runtime
> is something common to all wireless drivers, so instead of using
> vendor commands what do you think if I pass the calibration data name
> instead of using those magic constants? This way, userspace does not
> need to know the details of what band/range power limit the driver
> supports. It allows for flexible driver side implementation and
> easier for userspace to control.
> 

Sorry - I dropped this thread accidentally.

I'm not really sure I understand the situation fully, but right now to
me this seems very strange.

The physical antennas probably don't really change between "clamshell"
and "tablet" mode, do the physical radiation properties change enough
to actually require different *calibration*? To me, that sounds very
strange.

Assuming they don't really change fundamentally, then I understand the
need to set different power levels, per band/channel/whatever
granularity. But that can be achieved in very different ways, and in
fact if you look at Chrome then for our iwl7000 driver there we do have
a command to do something similar (currently a vendor command, but that
can be changed) without ever changing the *calibration*.

So to me, the whole premise of the patch is confusing and/or wrong.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] nl80211: improve nl80211_parse_mesh_config type checking

[Johannes Berg]

On Wed, 2016-06-15 at 22:29 +0200, Arnd Bergmann wrote:
> When building a kernel with W=1, the nl80211.c file causes a number
> of
> warnings, all about the same problem:
> 
> net/wireless/nl80211.c: In function 'nl80211_parse_mesh_config':
> net/wireless/nl80211.c:5287:103: error: comparison is always false
> due to limited range of data type [-Werror=type-limits]
> net/wireless/nl80211.c:5290:96: error: comparison is always false due
> to limited range of data type [-Werror=type-limits]
> net/wireless/nl80211.c:5293:124: error: comparison is always false
> due to limited range of data type [-Werror=type-limits]
> net/wireless/nl80211.c:5295:148: error: comparison is always false
> due to limited range of data type [-Werror=type-limits]
> net/wireless/nl80211.c:5298:106: error: comparison is always false
> due to limited range of data type [-Werror=type-limits]
> net/wireless/nl80211.c:5305:116: error: comparison is always false
> due to limited range of data type [-Werror=type-limits]
> 
> The problem is that gcc does not notice that the check is generate
> by a macro, so it complains about comparing an unsigned type against
> 0.
> 
> I've tried to come up with a way to rephrase that code in a way that
> avoids the warnings and otherwise improves the code as well.
> 
> This uses a set of new helper functions that perform the range
> checking,
> and should provide slightly better type safety than the older patch,
> at the expense of adding 44 lines to the code. Binary code size is
> basically unchanged though (20 bytes added to 126561 bytes .text).
> 
Applied.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] cfg80211: Add support to set tx power for a station associated

[Johannes Berg]

On Tue, 2016-06-14 at 23:14 +0530, Ashok Raj Nagarajan wrote:
> This patch adds support to set transmit power setting type and
> transmit power level attributes to NL80211_CMD_SET_STATION in order
> to facilitate adjusting the transmit power level of a station
> associated to the AP.

Why would you ever need to do that manually? Please give more
explanation in the commit message.

We have minstrel-blues (which never made it into the code, but that's
just because the submitter went away) doing power adjustments, so you
need to explain why this should be necessary.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Fix mesh estab_plinks counting in STA removal case

[Johannes Berg]

On Sun, 2016-06-19 at 23:51 +0300, Jouni Malinen wrote:
> If a user space program (e.g., wpa_supplicant) deletes a STA entry
> that
> is currently in NL80211_PLINK_ESTAB state, the number of established
> plinks counter was not decremented and this could result in rejecting
> new plink establishment before really hitting the real maximum plink
> limit. For !user_mpm case, this decrementation is handled by
> mesh_plink_deactive().
> 
> Fix this by decrementing estab_plinks on STA deletion
> (mesh_sta_cleanup() gets called from there) so that the counter has a
> correct value and the Beacon frame advertisement in Mesh
> Configuration
> element shows the proper value for capability to accept additional
> peers.
> 

Applied.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] wlcore/wl18xx: mesh: added initial mesh support for wl8

[Yaniv Machani]

From: Maital Hahn 

1. Added support for interface and role of mesh type.
2. Enabled enable/start of mesh-point role,
   and opening and closing a connection with a mesh peer.
3. Added multirole combination of mesh and ap
   under the same limits of dual ap mode.
4. Add support for 'sta_rc_update' opcode for mesh IF.
   The 'sta_rc_update' opcode is being used in mesh_plink.c.
Add support in wlcore to handle this opcode correctly for mesh
(as opposed to current implementation that handles STA only).
5. Bumped the firmware version to support new Mesh functionality

Signed-off-by: Maital Hahn 
Signed-off-by: Yaniv Machani 
---
 drivers/net/wireless/ti/wl18xx/main.c | 15 ---
 drivers/net/wireless/ti/wl18xx/wl18xx.h   |  2 +-
 drivers/net/wireless/ti/wlcore/acx.h  |  1 +
 drivers/net/wireless/ti/wlcore/boot.c |  2 +-
 drivers/net/wireless/ti/wlcore/cmd.c  | 13 -
 drivers/net/wireless/ti/wlcore/main.c | 32 +++
 drivers/net/wireless/ti/wlcore/wlcore_i.h |  1 +
 7 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/ti/wl18xx/main.c 
b/drivers/net/wireless/ti/wl18xx/main.c
index ae47c79..4811b74 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -1821,9 +1821,12 @@ static const struct ieee80211_iface_limit 
wl18xx_iface_limits[] = {
},
{
.max = 1,
-   .types = BIT(NL80211_IFTYPE_AP) |
-BIT(NL80211_IFTYPE_P2P_GO) |
-BIT(NL80211_IFTYPE_P2P_CLIENT),
+   .types =   BIT(NL80211_IFTYPE_AP)
+| BIT(NL80211_IFTYPE_P2P_GO)
+| BIT(NL80211_IFTYPE_P2P_CLIENT)
+#ifdef CONFIG_MAC80211_MESH
+| BIT(NL80211_IFTYPE_MESH_POINT)
+#endif
},
{
.max = 1,
@@ -1836,6 +1839,12 @@ static const struct ieee80211_iface_limit 
wl18xx_iface_ap_limits[] = {
.max = 2,
.types = BIT(NL80211_IFTYPE_AP),
},
+#ifdef CONFIG_MAC80211_MESH
+   {
+   .max = 1,
+   .types = BIT(NL80211_IFTYPE_MESH_POINT),
+   },
+#endif
{
.max = 1,
.types = BIT(NL80211_IFTYPE_P2P_DEVICE),
diff --git a/drivers/net/wireless/ti/wl18xx/wl18xx.h 
b/drivers/net/wireless/ti/wl18xx/wl18xx.h
index 71e9e38..d65cc6d 100644
--- a/drivers/net/wireless/ti/wl18xx/wl18xx.h
+++ b/drivers/net/wireless/ti/wl18xx/wl18xx.h
@@ -29,7 +29,7 @@
 #define WL18XX_IFTYPE_VER  9
 #define WL18XX_MAJOR_VER   WLCORE_FW_VER_IGNORE
 #define WL18XX_SUBTYPE_VER WLCORE_FW_VER_IGNORE
-#define WL18XX_MINOR_VER   11
+#define WL18XX_MINOR_VER   58
 
 #define WL18XX_CMD_MAX_SIZE  740
 
diff --git a/drivers/net/wireless/ti/wlcore/acx.h 
b/drivers/net/wireless/ti/wlcore/acx.h
index 0d61fae..6321ed4 100644
--- a/drivers/net/wireless/ti/wlcore/acx.h
+++ b/drivers/net/wireless/ti/wlcore/acx.h
@@ -105,6 +105,7 @@ enum wl12xx_role {
WL1271_ROLE_DEVICE,
WL1271_ROLE_P2P_CL,
WL1271_ROLE_P2P_GO,
+   WL1271_ROLE_MESH_POINT,
 
WL12XX_INVALID_ROLE_TYPE = 0xff
 };
diff --git a/drivers/net/wireless/ti/wlcore/boot.c 
b/drivers/net/wireless/ti/wlcore/boot.c
index 19b7ec7..f75d304 100644
--- a/drivers/net/wireless/ti/wlcore/boot.c
+++ b/drivers/net/wireless/ti/wlcore/boot.c
@@ -130,7 +130,7 @@ fail:
wl1271_error("Your WiFi FW version (%u.%u.%u.%u.%u) is invalid.\n"
 "Please use at least FW %s\n"
 "You can get the latest firmwares at:\n"
-"git://github.com/TI-OpenLink/firmwares.git",
+"git://git.ti.com/wilink8-wlan/wl18xx_fw.git",
 fw_ver[FW_VER_CHIP], fw_ver[FW_VER_IF_TYPE],
 fw_ver[FW_VER_MAJOR], fw_ver[FW_VER_SUBTYPE],
 fw_ver[FW_VER_MINOR], min_fw_str);
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c 
b/drivers/net/wireless/ti/wlcore/cmd.c
index 3315356..d002dc7 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -629,11 +629,14 @@ int wl12xx_cmd_role_start_ap(struct wl1271 *wl, struct 
wl12xx_vif *wlvif)
 
wl1271_debug(DEBUG_CMD, "cmd role start ap %d", wlvif->role_id);
 
-   /* trying to use hidden SSID with an old hostapd version */
-   if (wlvif->ssid_len == 0 && !bss_conf->hidden_ssid) {
-   wl1271_error("got a null SSID from beacon/bss");
-   ret = -EINVAL;
-   goto out;
+   /* If MESH --> ssid_len is always 0 */
+   if (!ieee80211_vif_is_mesh(vif)) {
+   /* trying to use hidden SSID with an old hostapd version */
+   if (wlvif->ssid_len == 0 && !bss_conf->hidden_ssid) {
+   wl1271_error("got a null SSID from beacon/bss");
+   ret = -EINVAL;

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

[Michal Kazior]

On 27 June 2016 at 16:36, Mohammed Shafi Shajakhan
 wrote:
> Hi Michal,
>
> thanks for the review ..
>
> On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote:
>> On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan
>>  wrote:
>> > From: Mohammed Shafi Shajakhan 
>> >
>> > For chipsets like QCA99X0, IPQ4019 and later we are not getting proper
>> > NULL func status (always acked/successs !!) when hostapd does a
>> > PROBE_CLIENT via nullfunc frames when the station is powered off
>> > abruptly (inactive timer probes client via null func after the inactive
>> > time reaches beyond the threshold). Fix this by disabling the workaround
>> > (getting the ACK status of NULL func frames by sending via HTT mgmt-tx
>> >  path) introduced by the change ("ath10k: fix beacon loss handling ")
>> > for QCA99X0 and later chipsets. The normal tx path provides the proper
>> > ACK status for NULL data frames. As of now disable this workaround for
>> > chipsets QCA99X0 and later, once the 10.1 firmware is obselete we can
>> > completely get rid of this workaround for all the chipsets
>> >
>> > Signed-off-by: Tamizh chelvam 
>> > Signed-off-by: Mohammed Shafi Shajakhan 
>> > ---
>> >  drivers/net/wireless/ath/ath10k/core.c | 3 +++
>> >  drivers/net/wireless/ath/ath10k/core.h | 6 ++
>> >  drivers/net/wireless/ath/ath10k/mac.c  | 1 +
>> >  3 files changed, 10 insertions(+)
>> >
>> > diff --git a/drivers/net/wireless/ath/ath10k/core.c 
>> > b/drivers/net/wireless/ath/ath10k/core.c
>> > index 689d6ce..9978e4a 100644
>> > --- a/drivers/net/wireless/ath/ath10k/core.c
>> > +++ b/drivers/net/wireless/ath/ath10k/core.c
>> > @@ -181,6 +181,7 @@ static const struct ath10k_hw_params 
>> > ath10k_hw_params_list[] = {
>> > .board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
>> > .board_size = QCA99X0_BOARD_DATA_SZ,
>> > .board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
>> > +   .disable_null_func_workaround = true,
>>
>> Tx completion (bugs) are firmware specific, not hardware. This should
>> be expressed via features bits in ath10k FW API, no?
>>
>>
> [shafi] Are you suggesting me to introduce something like
> "ATH10K_FW_FEATURE_SUPPORTS_SKIP_CLOCK_INIT" ? Kalle any suggestions ?
>
> Also how about getting this workaround completely if Ben had fixed this in 
> his tree,
> will this affect older 10.2.4 ?

There's still 636.

We could probably get rid of this as long as:
 - ath10k can express the need to use Probe Requests for AP probing
(in client mode) and beacon loss handling purposes instead of NullFunc
to mac80211
 - everyone uses hostapd with disassoc_low_ack=1 with affected
firmware revisions
 - supplicant uses disassoc_low_ack=1 for p2p go
 - I have no idea about mesh/ibss but they might require some work as well

Otherwise you'll introduce regressions.


Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html