* Re: [PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets
From: Per Förlin @ 2016-07-13 18:52 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, arend
In-Reply-To: <cdb613ba-d2b1-d9eb-9beb-2934cff96aa6@broadcom.com>
2016-07-13 13:20 GMT+02:00 Arend Van Spriel <arend.vanspriel@broadcom.com>:
> On 12-7-2016 12:23, Per Förlin wrote:
>> 2016-07-12 11:48 GMT+02:00 Arend Van Spriel <arend.vanspriel@broadcom.com>:
>>>
>>>
>>> On 12-7-2016 10:35, Per Förlin wrote:
>>>> 2016-07-06 11:53 GMT+02:00 Per Förlin <per.forlin@gmail.com>:
>>>>> I have now verified this patch on backports 4.4.
>>>>>
>>>>> 2016-04-12 23:55 GMT+02:00 <per.forlin@gmail.com>:
>>>>>> From: Per Forlin <per.forlin@gmail.com>
>>>>>>
>>>>>> This patch resolves an issue where pend_8021x_cnt was not decreased
>>>>>> on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
>>>>>> because the counter indicated pending packets.
>>>>>>
>>>>>> WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
>>>>>> (warn_slowpath_common)
>>>>>> (warn_slowpath_null)
>>>>>> (brcmf_netdev_wait_pend8021x [brcmfmac])
>>>>>> (send_key_to_dongle [brcmfmac])
>>>>>> (brcmf_cfg80211_del_key [brcmfmac])
>>>>>> (nl80211_del_key [cfg80211])
>>>>>> (genl_rcv_msg)
>>>>>> (netlink_rcv_skb)
>>>>>> (genl_rcv)
>>>>>> (netlink_unicast)
>>>>>> (netlink_sendmsg)
>>>>>> (sock_sendmsg)
>>>>>> (___sys_sendmsg)
>>>>>> (__sys_sendmsg)
>>>>>> (SyS_sendmsg)
>>>>>>
>>>>>> The solution is to pull back the header offset in case
>>>>>> of an error in txdata(), which may happen in case of
>>>> Clarification:
>>>>
>>>> txdata=brcmf_proto_bcdc_txdata()
>>>> brcmf_proto_bcdc_txdata(): Calls brcmf_proto_bcdc_hdrpush()
>>>>
>>>> The header needs to be pulled back in case of error otherwise
>>>> the error handling and cleanup up will fail to decrease the counter
>>>> of pending packets.
>>>
>>> Yes, this part of the patch is clear to me.
>>>
>> Thanks, I wasn't sure.
>>
>>>>>> packet overload in brcmf_sdio_bus_txdata.
>>>>>>
>>>>>> Overloading an WLAN interface is not an unlikely scenario.
>>>
>>> So here is where things start to look suspicious and I have mentioned
>>> this before. My thought here was "How the hell can you end up with a
>>> 2048 packets on the sdio queue", which I mentioned to you before. There
>>> is a high watermark on the queue upon which we do a netif_stop_queue()
>>> so network layer does not keep pushing tx packets our way. Looking
>>> further into this I found that we introduced a bug with commit
>>> 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.") so we ended
>>> up doing nothing except increasing as statistics debug counter :-(
>>>
>> Is there a fix available for the high watermark issue or is it
>> something you will look into?
>>
>> To produce a load on the wlan interface I run
>> iperf -c 239.255.1.3 -u -b 10m -f m -i 60 -t 3000
>> and this is enough in my case to fill up the 2048 queue.
>>
>>>>>> In case of packet overload the error print "out of bus->txq"
>>>>>> is very verbose. To reduce SPAM degrade it to a debug print.
>>>>>>
>>>>>> Signed-off-by: Per Forlin <per.forlin@gmail.com>
>>>>>> ---
>>>>>> Change log:
>>>>>> v2 - Add variable to know whether the counter is increased or not
>>>>>> v3 - txfinalize should decrease the counter. Adjust skb header offset
>>>>>> v4 - Fix build error
>>>>>>
>>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++++
>>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 4 +++-
>>>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>>>>>> 3 files changed, 8 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>>>> index ed9998b..f342f7c 100644
>>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>>>>>> @@ -541,6 +541,9 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>>>>>> struct ethhdr *eh;
>>>>>> u16 type;
>>>>>>
>>>>>> + if (!ifp)
>>>>>> + goto free;
>>>>>> +
>>>
>>> This may not be needed.
>>>
>> This is not strictly needed. I can remove it.
>>
>>>>>> eh = (struct ethhdr *)(txp->data);
>>>>>> type = ntohs(eh->h_proto);
>>>>>>
>>>>>> @@ -553,6 +556,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
>>>>>> if (!success)
>>>>>> ifp->stats.tx_errors++;
>>>>>>
>>>>>> +free:
>>>>>> brcmu_pkt_buf_free_skb(txp);
>>>>>> }
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>>>> index f82c9ab..98cb83f 100644
>>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>>>>>> @@ -1899,8 +1899,10 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
>>>>>>
>>>>>> if (fws->avoid_queueing) {
>>>>>> rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
>>>>>> - if (rc < 0)
>>>>>> + if (rc < 0) {
>>>>>> + (void)brcmf_proto_hdrpull(drvr, false, skb, &ifp);
>>>
>>> Could it be that the ifp is NULL pointer after brcmf_proto_hdrpull().
>>> Can you check. Better use tmp_ifp variable in this call as you have a
>>> valid ifp before this call for sure.
>>>
>> To be on the safe side I can use NULL as in param like you propose,
>> and use the available ifp.
>>
>>>>>> brcmf_txfinalize(ifp, skb, false);
>>>>>> + }
>>>>>> return rc;
>>>>>> }
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>>>> index a14d9d9d..485e2ad 100644
>>>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>>>>> @@ -2721,7 +2721,7 @@ static int brcmf_sdio_bus_txdata(struct device *dev, struct sk_buff *pkt)
>>>>>> *(u16 *)(pkt->cb) = 0;
>>>>>> if (!brcmf_sdio_prec_enq(&bus->txq, pkt, prec)) {
>>>>>> skb_pull(pkt, bus->tx_hdrlen);
>>>>>> - brcmf_err("out of bus->txq !!!\n");
>>>>>> + brcmf_dbg(INFO, "out of bus->txq !!!\n");
>>>
>>> Now that I understand the issue I want to keep this as error print as it
>>> should be very unlikely.
>> I would like to test this patch with the watermark fix to confirm this.
>
> Can you try this?
>
> Regards,
> Arend
>
> ---
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> b/drive
> index cd221ab..9f9024a 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> @@ -2469,10 +2469,22 @@ void brcmf_fws_bustxfail(struct brcmf_fws_info
> *fws, str
> void brcmf_fws_bus_blocked(struct brcmf_pub *drvr, bool flow_blocked)
> {
> struct brcmf_fws_info *fws = drvr->fws;
> + struct brcmf_if *ifp;
> + int i;
>
> - fws->bus_flow_blocked = flow_blocked;
> - if (!flow_blocked)
> - brcmf_fws_schedule_deq(fws);
> - else
> - fws->stats.bus_flow_block++;
> + if (fws->avoid_queueing) {
> + for (i = 0; i < BRCMF_MAX_IFS; i++) {
> + ifp = drvr->iflist[i];
> + if (!ifp || !ifp->ndev)
> + continue;
> + brcmf_txflowblock_if(ifp,
> BRCMF_NETIF_STOP_REASON_FLOW,
> + flow_blocked);
> + }
> + } else {
> + fws->bus_flow_blocked = flow_blocked;
> + if (!flow_blocked)
> + brcmf_fws_schedule_deq(fws);
> + else
> + fws->stats.bus_flow_block++;
> + }
> }
>
Thanks for the code. I run a quick test and it looks fine.
I added some prints to check the progress:
len - is number of items in the queue
max - is max number of entries in the queue
[ 89.407856] [brcmf_sdio_prec_enq] prec 2 prio 0 len 1789 max 2048
[ 89.414682] [brcmf_sdio_prec_enq] prec 2 prio 0 len 1790 max 2048
[ 89.421497] [brcmf_sdio_prec_enq] prec 2 prio 0 len 1791 max 2048
[ 93.970466] [brcmf_sdio_prec_enq] prec 2 prio 0 len 1524 max 2048
[ 93.977520] [brcmf_sdio_prec_enq] prec 2 prio 0 len 1525 max 2048
[ 93.984572] [brcmf_sdio_prec_enq] prec 2 prio 0 len 1526 max 2048
I will some run more WLAN tests tomorrow to make sure.
When I'm done testing I will update my patch as well and let you know.
I came across this issue when I tried to connect to my WLAN access
point. The bug was triggered due to a lot of background traffic
(broadcast and multicast) in the network filling up the queue.
It's now fixed so that the queue is not flooded. Now I move on to the
next issue. It's still difficult to connect because the background
eats up all the bandwidth (this is not a constant issue but it happens
from time to time depending on the background load).
For queueing-mode there seems to exist logic for handling multicast
traffic separately but for the SDIO case (no-queueing) normal traffic
gets same precedence as multicast traffic.
I'm considering something like this:
--- a/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
@@ -1900,6 +1902,8 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp,
struct sk_buff *skb)
drvr->tx_multicast += !!multicast;
if (fws->avoid_queueing) {
+ if (multicast)
+ skb->priority = PRIO_8021D_NONE;
rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
if (rc < 0) {
(void)brcmf_proto_hdrpull(drvr, false, skb, NULL);
It feels a little hacky.
I would like to use the drvr->tx_multicast instead, if possible.
The problem is that the "drvr" struct is not passed down to the sdio layer.
One could update bcdc.c : brcmf_proto_bcdc_txdata() to pass
"drcr->multicast" to the SDIO layer but not all bus implementations
need this information (USB for instance)
Any suggestions?
BR
Per Forlin
^ permalink raw reply
* Re: iwlwifi + wpa2-leap + multiple AP's = call trace
From: Ismael Farfán @ 2016-07-13 18:33 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: Arend Van Spriel, linux-wireless
In-Reply-To: <CANUX_P3A5YohcustmZzC9A6b5DKyaY9dGDpYAxWWFKc8wH1Gng@mail.gmail.com>
Hi
I'm using wicd, so changed from wext to nl80211 and I don't see the
trace anymore... it still refuses to connect though, so I'll check
what's wrong with my configuration.
Do you want me to collect some information regarding wpa_supplicant
and wext from my system?
If so, how?
Thanks for your help
-Farfan
2016-07-13 11:31 GMT-05:00 Emmanuel Grumbach <egrumbach@gmail.com>:
> On Jul 13, 2016 9:23 AM, "Arend Van Spriel" <arend.vanspriel@broadcom.com>
> wrote:
>>
>>
>>
>> On 13-7-2016 2:29, Ismael Farfán wrote:
>> > Hello list
>> >
>> > I searched this error around and didn't find anything, so here it goes.
>> >
>> > Today I tried to connect to an enterprise network, which means,
>> > literally, tens of AP's sharing the same name... the network requieres
>> > user/password authentication (wpa2-leap).
>> >
>> > I'm using Arch
>> > $ uname -a
>> > Linux 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64
>> > GNU/Linux
>> >
>> > Since the thing just didn't connect, I checked dmesg and found this:
>> >
>> > Any ideas?
>>
>> From the stack trace it seems wpa_supplicant on Arch is using WEXT API.
>> You could try and change it to use NL80211 API. Personally, I have not
>> used Arch Linux so no idea where to change that.
>>
>> The warning is here [1]:
>>
>> 503 IWL_DEBUG_TE(mvm, "Add new TE, duration %d TU\n",
>> 504 le32_to_cpu(te_cmd->duration));
>> 505
>> 506 spin_lock_bh(&mvm->time_event_lock);
>> 507 if (WARN_ON(te_data->id != TE_MAX)) {
>> 508 spin_unlock_bh(&mvm->time_event_lock);
>> 509 return -EIO;
>> 510 }
>>
>> It seems this function is called with te_data that is already in use,
>> but that is my uneducated guess so I may be wrong.
>>
>
> This is right :)
>
> Can you please record tracing of this?
>
> Thank you.
>
>> Regards,
>> Arend
>>
>> [1]
>>
>> http://lxr.free-electrons.com/source/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c#L507
>> >
>> > [ 83.030072] wifi0: aborting authentication with xx:xx:xx:xx:xx:xx
>> > by local choice (Reason: 3=DEAUTH_LEAVING)
>> > [ 83.030073] ------------[ cut here ]------------
>> > [ 83.030082] WARNING: CPU: 2 PID: 1087 at
>> > drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:507 iwl_mvm_tim
>> > e_event_send_add+0x1c6/0x200 [iwlmvm]
>> > [ 83.030157] CPU: 2 PID: 1087 Comm: wpa_supplicant Tainted: G
>> > O 4.6.3-1-ARCH #1
>> > [ 83.030158] Hardware name: Notebook
>> > P65_P67SA /P65_P67SA
>> > , BIOS 1.03.01 07/22/2015
>> > [ 83.030160] 0000000000000286 0000000009e998bc ffff880403a5b940
>> > ffffffff812e54c2
>> > [ 83.030162] 0000000000000000 0000000000000000 ffff880403a5b980
>> > ffffffff8107a6bb
>> > [ 83.030164] 000001fb81a8a180 ffff88041b443580 ffff88041c329548
>> > 00000000fffffffb
>> > [ 83.030167] Call Trace:
>> > [ 83.030172] [<ffffffff812e54c2>] dump_stack+0x63/0x81
>> > [ 83.030174] [<ffffffff8107a6bb>] __warn+0xcb/0xf0
>> > [ 83.030176] [<ffffffff8107a7ed>] warn_slowpath_null+0x1d/0x20
>> > [ 83.030181] [<ffffffffa0b068d6>]
>> > iwl_mvm_time_event_send_add+0x1c6/0x200 [iwlmvm]
>> > [ 83.030184] [<ffffffff810c4772>] ? up+0x32/0x50
>> > [ 83.030187] [<ffffffff810d371b>] ? wake_up_klogd+0x3b/0x50
>> > [ 83.030189] [<ffffffff810d3c19>] ? console_unlock+0x4e9/0x590
>> > [ 83.030193] [<ffffffffa0b07520>]
>> > iwl_mvm_protect_session+0x220/0x280 [iwlmvm]
>> > [ 83.030196] [<ffffffffa0af100e>] ? iwl_mvm_ref_sync+0x2e/0x140
>> > [iwlmvm]
>> > [ 83.030199] [<ffffffff810d423f>] ? vprintk_default+0x1f/0x30
>> > [ 83.030202] [<ffffffffa0af154a>]
>> > iwl_mvm_mac_mgd_prepare_tx+0x5a/0xa0 [iwlmvm]
>> > [ 83.030216] [<ffffffffa0c8e198>] ieee80211_mgd_deauth+0x338/0x4d0
>> > [mac80211]
>> > [ 83.030219] [<ffffffff810b2333>] ? enqueue_entity+0x323/0xd70
>> > [ 83.030228] [<ffffffffa0c579b8>] ieee80211_deauth+0x18/0x20
>> > [mac80211]
>> > [ 83.030237] [<ffffffffa05a1b8f>] cfg80211_mlme_deauth+0x9f/0x1a0
>> > [cfg80211]
>> > [ 83.030242] [<ffffffffa05a62da>] cfg80211_disconnect+0x9a/0x200
>> > [cfg80211]
>> > [ 83.030248] [<ffffffffa05c4529>]
>> > cfg80211_mgd_wext_siwessid+0xa9/0x170 [cfg80211]
>> > [ 83.030255] [<ffffffffa05c3512>] cfg80211_wext_siwessid+0x22/0x40
>> > [cfg80211]
>> > [ 83.030258] [<ffffffff815af803>] ioctl_standard_iw_point+0x133/0x350
>> > [ 83.030264] [<ffffffffa05c34f0>] ?
>> > cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
>> > [ 83.030266] [<ffffffff810a4a82>] ? wake_up_q+0x32/0x70
>> > [ 83.030268] [<ffffffff815b0930>] ? iw_handler_get_private+0x60/0x60
>> > [ 83.030271] [<ffffffff815afd07>] ioctl_standard_call+0x87/0xd0
>> > [ 83.030273] [<ffffffff815afc80>] ?
>> > call_commit_handler.part.4+0x30/0x30
>> > [ 83.030275] [<ffffffff815afc10>] wireless_process_ioctl+0x1f0/0x230
>> > [ 83.030278] [<ffffffff814b52fe>] ? dev_get_by_name_rcu+0x5e/0x80
>> > [ 83.030280] [<ffffffff815aff58>] wext_handle_ioctl+0x78/0xd0
>> > [ 83.030283] [<ffffffff814d7777>] dev_ioctl+0x2a7/0x5a0
>> > [ 83.030285] [<ffffffff8149dc86>] sock_ioctl+0x126/0x290
>> > [ 83.030287] [<ffffffff81209be3>] do_vfs_ioctl+0xa3/0x5d0
>> > [ 83.030290] [<ffffffff811f7362>] ? vfs_write+0x142/0x190
>> > [ 83.030292] [<ffffffff8120a189>] SyS_ioctl+0x79/0x90
>> > [ 83.030294] [<ffffffff815c71b2>] entry_SYSCALL_64_fastpath+0x1a/0xa4
>> > [ 83.030296] ---[ end trace 8247b235a66a1a21 ]---
>> >
>> >
>> >
>> >
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Do not let me induce you to satisfy my curiosity, from an expectation,
that I shall gratify yours. What I may judge proper to conceal, does
not concern myself alone.
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-07-13
From: Kalle Valo @ 2016-07-13 18:29 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request for net-next. This time there are few conflicts
due to the cfg80211 scan API changes, and one of them is easy to miss,
so please pay extra attention to them. Otherwise there's not nothing
really out of ordinary. Please note that I also pulled wireless-drivers
to wireless-drivers-next to reduce the amount of conflicts.
So about the conflicts, the obvious are notified by git:
CONFLICT (content): Merge conflict in drivers/net/wireless/marvell/mwifiex/cmdevt.c
CONFLICT (content): Merge conflict in drivers/net/wireless/intel/iwlwifi/mvm/scan.c
Basically the major change is that in iwlwifi del_timer() is changed to
cancel_delayed_work() and in mwifiex the code was refactored to use
mwifiex_cancel_scan(). But the tricky part comes here which is easy to
miss:
Auto-merging drivers/net/wireless/marvell/mwifiex/scan.c
You need to convert the scan code in mwifiex_cancel_scan():
cfg80211_scan_done(priv->scan_request, 1);
to use the new API:
struct cfg80211_scan_info info = {
.aborted = true,
};
[...]
cfg80211_scan_done(priv->scan_request, &info);
I have attached the output from git diff as an example how to resolve
this, hopefully that helps. Please let me know if there are any problems
or if you want to handle these differently.
Kalle
The following changes since commit 742fb20fd4c75bd08733b0ea232c7e0fa67a6f87:
net: ethernet: ti: cpdma: switch to use genalloc (2016-06-29 04:16:11 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2016-07-13
for you to fetch changes up to 25f700ef0653d7644ed273f8770230e734cae726:
iwlwifi: add missing type declaration (2016-07-12 14:51:57 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.8
Major changes:
iwlwifi
* more work on the RX path for the 9000 device series
* some more dynamic queue allocation work
* SAR BIOS implementation
* some work on debugging capabilities
* added support for GCMP encryption
* data path rework in preparation for new HW
* some cleanup to remove transport dependency on mac80211
* support for MSIx in preparation for new HW
* lots of work in preparation for HW support (9000 and a000 series)
mwifiex
* implement get_tx_power and get_antenna cfg80211 operation callbacks
wl18xx
* add support for 64bit clock
rtl8xxxu
* aggregation support (optional for now)
Also wireless-drivers is merged to fix some conflicts.
----------------------------------------------------------------
Amitkumar Karwar (8):
mwifiex: fix system hang problem after resume
mwifiex: fix AP unable to start in VHT40 problem
mwifiex: fix AP start problem for newly added interface
mwifiex: code rearrangement in suspend handler
mwifiex: clear scan_aborting flag
mwifiex: fix NULL pointer dereference during suspend
mwifiex: fix scan_block flag handling
mwifiex: Change default firmware for PCIe8997 chipset
Andrei Otcheretianski (1):
iwlwifi: mvm: Support CSA countdown offloading
Andy Shevchenko (1):
rtl8xxxu: tuse %*ph to dump buffers
Arnd Bergmann (6):
rtlwifi: use s8 instead of char
wireless: airo: rename 'register' variable
wireless: brcmsmac: fix old-style declaration
wireless: ipw2200: fix old-style declaration
iwlwifi: mvm: avoid harmless -Wmaybe-uninialized warning
iwlwifi: add missing type declaration
Avraham Stern (1):
iwlwifi: rename CAPA_P2P_STANDALONE_UAPSD to CAPA_P2P_SCM_UAPSD
Ayala Beker (2):
iwlwifi: mvm: fix RX mpdu status enum
iwlwifi: mvm: add support for GCMP encryption
Bhaktipriya Shridhar (1):
libertas_tf: Remove create_workqueue
Brian Norris (1):
mwifiex: mask PCIe interrupts before removal
Bruno Herrera (1):
wlcore: sdio: Fix crash on wlcore_probe_of when failing to parse/map irq
Dan Carpenter (2):
iwlwifi: mvm: remove an unused variable
iwlwifi: mvm: silence uninitialized variable warning
Emmanuel Grumbach (7):
iwlwifi: advertise maximal MPDU length when Rx MQ is supported
iwlwifi: pcie: enable interrupts before releasing the NIC's CPU
iwlwifi: mvm: cleanup the coex code
iwlwifi: mvm: fix coex related comments
iwlwifi: mvm: fix the channel inhibition table for Channel 14
iwlwifi: mvm: unmap the paging memory before freeing it
iwlwifi: pcie: fix a race in firmware loading flow
Ganapathi Bhat (1):
mwifiex: Fix an issue spotted by KASAN
Golan Ben-Ami (2):
iwlwifi: Reserve iwl_fw_error_dump_type enum
iwlwifi: mvm: write the correct internal TXF index
Gregory Greenman (1):
iwlwifi: mvm: rs: add rate scaling support for 160MHz channels
Guenter Roeck (1):
iwlwifi: dvm: Remove unused array 'iwlagn_loose_lookup'
Guy Mishol (1):
wlcore: reconfigure sta rates on authorization
Haim Dreyfuss (1):
iwlwifi: Add a000 HW family support
Ido Yariv (1):
iwlwifi: pcie: Enable MSI mode when using MSI interrupts
Javier Martinez Canillas (2):
mwifiex: fix unconditional error return in .add_virtual_intf callback
mwifiex: add a cfg80211 .get_tx_power operation callback
Jes Sorensen (15):
rtl8xxxu: Add bit definitions for REG_USB_SPECIAL_OPTION
rtl8xxxu: Add additional documentation for RX DMA registers
rtl8xxxu: Reduce console noise when removing the kernel module
rtl8xxxu: Set all ieee80211_rx_status values in parse_rx_desc()
rtl8xxxu: Move skb delivery into parse_tx_desc() handler
rtl8xxxu: Obtain ieee80211_rx_status within parse_rx_desc()
rtl8xxxu: Correct rxdesc16 definition
rtl8xxxu: Add support for aggregated RX packets on gen1 parts
rtl8xxxu: Allocate larger RX skbs when aggregation is enabled
rtl8xxxu: Adjust RX skb size to include space for phystats
rtl8xxxu: Enable aggregation for rtl8723au
rtl8xxxu: Enable aggregation for rtl8192cu/rtl8188cu/rtl8188ru
rtl8xxxu: Make DMA aggregation optional by setting a module parameter
rtl8xxxu: gen1: Set aggregation timeout (REG_RXDMA_AGG_PG_TH + 1) as well
rtl8xxxu: gen1: Add module parameters to adjust DMA aggregation parameters
Joe Perches (2):
rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size
rtlwifi: Add missing newlines to RT_TRACE calls
Johannes Berg (8):
iwlwifi: mvm: fix comment indentation
iwlwifi: mvm: handle FRAME_RELEASE in MQ code
iwlwifi: remove useless enum values
iwlwifi: change fw.mvm_fw to fw.type
iwlwifi: remove iwl_ht_params.smps_mode
iwlwifi: store cipher scheme independent of mac80211
iwlwifi: tracing: decouple from mac80211
iwlwifi: decouple PCIe transport from mac80211
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2016-07-01' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2016-07-06' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge git://git.kernel.org/.../kvalo/wireless-drivers.git
Larry Finger (16):
rtlwifi: Remove unused parameter from rtl_ps_set_rf_state()
rtlwifi: rtl8188ee: Fix potential race condition
rtlwifi: rtl8192ee: Fix potential race condition
rtlwifi: rtl8723be: Fix potential race condition
rtlwifi: rtl8723ae: Fix potential race condition
rtlwifi: rtl8821ae: Fix potential race condition
rtlwifi: Create common routine to get hardware info
rtlwifi: rtl8192ce: Convert driver to use common hardware info routine
rtlwifi: rtl8192cu: Convert driver to use common hardware info routine
rtlwifi: rtl8188ee: Convert driver to use common hardware info routine
rtlwifi: rtl8192ee: Convert driver to use common hardware info routine
rtlwifi: rtl8723ae: Convert driver to use common hardware info routine
rtlwifi: rtl8723be: Convert driver to use common hardware info routine
rtlwifi: rtl8821ae: Convert driver to use common hardware info routine
rtlwifi: rtl8192de: Convert driver to use common hardware info routine
rtlwifi: rtl8723ae: Clean up the hardware info routine
Liad Kaufman (8):
iwlwifi: mvm: free dqa queues on STA removal also in non-bss
iwlwifi: mvm: support dqa queue inactivation upon timeout
iwlwifi: mvm: support dqa queue sharing
iwlwifi: mvm: set sta_id in SCD_QUEUE_CONFIG cmd
iwlwifi: mvm: update aux queue in dqa mode
iwlwifi: mvm: support dqa-enable hcmd
iwlwifi: mvm: support tdls in dqa mode
iwlwifi: mvm: support dqa-mode scd queue redirection
Luca Coelho (4):
iwlwifi: mvm: change scan timeout to a delayed work
iwlwifi: mvm: remove unnecessary device conversion when reading the MCC
iwlwifi: mvm: read SAR BIOS table from ACPI
iwlwifi: mvm: support v4 of the TX power command
Luis de Bethencourt (1):
rtl8xxxu: remove unneeded assignments
Machani, Yaniv (1):
wlcore: time sync : add support for 64 bit clock
Masanari Iida (1):
rtlwifi: Fix typo in printk
Matti Gottlieb (1):
iwlwifi: mvm: Do not open aggregations for null data packets
Oren Givon (3):
iwlwifi: add new 8260 PCI IDs
iwlwifi: add new 8265
iwlwifi: mvm: fix txq aggregation bug
Pavel Andrianov (1):
libertas: Add spinlock to avoid race condition
Prasun Maiti (1):
mwifiex: Fix endianness for event TLV type TLV_BTCOEX_WL_SCANTIME
Rafał Miłecki (7):
brcmfmac: slightly simplify building interface combinations
brcmfmac: fix lockup when removing P2P interface after event timeout
brcmfmac: use const char * for interface name in brcmf_add_if
brcmfmac: include also core.h header in cfg80211.h
brcmfmac: add missing break when deleting P2P_DEVICE
brcmfmac: delete interface directly in code that sent fw request
brcmfmac: support removing AP interfaces with "interface_remove"
Sara Sharon (24):
iwlwifi: mvm: do not trust NSSN for amsdu sub-frames
iwlwifi: mvm: remove RX_PHY support for 9000 device
iwlwifi: mvm: update mpdu metadata API
iwlwifi: pcie: workaround HW shadow registers bug
iwlwifi: pcie: set RB chunk size per bus
iwlwifi: pcie: allow more than one frame in RB for 9000 devices
iwlwifi: pcie: make sure packet arrived to destined queue
iwlwifi: pcie: unify restock calls on init
iwlwifi: mvm: fix possible division by zero
iwlwifi: pcie: poll RFH for RX DMA stop
iwlwifi: add dump of RFH
iwlwifi: mvm: support new statistics notification
iwlwifi: mvm: checksum IPv6 fragmented packet
iwlwifi: pcie: fix access to scratch buffer
iwlwifi: pcie: don't use vid 0
iwlwifi: mvm: add RX aggregation prints
iwlwifi: mvm: free RX reorder buffer on restart
iwlwifi: pcie: track rxb status
iwlwifi: pcie: generalize and increase the size of scratchbuf
iwlwifi: centralize 64 bit HW registers write
iwlwifi: pcie: initialize a000 device's TFD table
iwlwifi: pcie: load FW chunk for a000 devices
iwlwifi: pcie: centralize SCD status logging
iwlwifi: move iwl_drv to be shared across transports
Shengzhen Li (3):
mwifiex: add get_antenna support for cfg80211
mwifiex: disable MSIx interrupt for 8997 chipset
mwifiex: fix interrupt processing corner case in MSI mode
Xinming Hu (2):
mwifiex: factor out mwifiex_cancel_scan
mwifiex: cancel pending scan during disconnect
striebit (1):
iwlmvm: mvm: set correct state in smart-fifo configuration
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 1 -
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
drivers/net/wireless/ath/ath9k/reg.h | 8 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 76 ++-
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 31 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 10 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 7 +-
.../wireless/broadcom/brcm80211/brcmsmac/main.c | 4 +-
drivers/net/wireless/cisco/airo.c | 4 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/lib.c | 17 -
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 3 +
drivers/net/wireless/intel/iwlwifi/dvm/rxon.c | 5 -
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 131 +++++
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 13 +-
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 6 +-
drivers/net/wireless/intel/iwlwifi/iwl-debug.h | 1 +
.../net/wireless/intel/iwlwifi/iwl-devtrace-io.h | 35 ++
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.h | 25 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 49 +-
.../net/wireless/intel/iwlwifi/iwl-eeprom-parse.c | 4 +-
.../net/wireless/intel/iwlwifi/iwl-eeprom-parse.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 99 +++-
.../net/wireless/intel/iwlwifi/iwl-fw-error-dump.h | 4 +
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 13 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw.h | 17 +-
drivers/net/wireless/intel/iwlwifi/iwl-io.c | 142 ++++-
drivers/net/wireless/intel/iwlwifi/iwl-io.h | 3 +
drivers/net/wireless/intel/iwlwifi/iwl-modparams.h | 10 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 7 +
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 33 +-
drivers/net/wireless/intel/iwlwifi/mvm/coex.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 2 +
.../net/wireless/intel/iwlwifi/mvm/fw-api-coex.h | 222 --------
.../net/wireless/intel/iwlwifi/mvm/fw-api-mac.h | 3 +
.../net/wireless/intel/iwlwifi/mvm/fw-api-power.h | 22 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rx.h | 56 +-
.../net/wireless/intel/iwlwifi/mvm/fw-api-sta.h | 8 +-
.../net/wireless/intel/iwlwifi/mvm/fw-api-stats.h | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 58 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 26 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 217 +++++++-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 108 +++-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 80 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 47 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 45 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 61 ++-
drivers/net/wireless/intel/iwlwifi/mvm/power.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 94 +++-
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 44 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 107 ++--
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 18 +-
drivers/net/wireless/intel/iwlwifi/mvm/sf.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 555 ++++++++++++++++++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 8 +
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 106 ++--
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 186 ++++++-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 26 +-
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 70 ++-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 145 +++--
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 167 +++---
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 188 ++++---
drivers/net/wireless/marvell/libertas/cmdresp.c | 4 +
drivers/net/wireless/marvell/libertas_tf/main.c | 2 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 91 +++-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 40 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 7 +-
drivers/net/wireless/marvell/mwifiex/init.c | 4 +-
drivers/net/wireless/marvell/mwifiex/ioctl.h | 2 +
drivers/net/wireless/marvell/mwifiex/join.c | 12 +
drivers/net/wireless/marvell/mwifiex/main.h | 3 +
drivers/net/wireless/marvell/mwifiex/pcie.c | 68 ++-
drivers/net/wireless/marvell/mwifiex/pcie.h | 6 +-
drivers/net/wireless/marvell/mwifiex/scan.c | 32 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 50 +-
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 10 +-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 6 +-
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 4 +
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 30 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 18 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 11 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 13 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c | 2 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 9 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 315 +++++++----
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 14 +-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 2 +-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 4 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/debug.c | 25 +
drivers/net/wireless/realtek/rtlwifi/debug.h | 17 +-
drivers/net/wireless/realtek/rtlwifi/efuse.c | 78 +++
drivers/net/wireless/realtek/rtlwifi/efuse.h | 2 +
drivers/net/wireless/realtek/rtlwifi/ps.c | 25 +-
drivers/net/wireless/realtek/rtlwifi/ps.h | 3 -
drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/dm.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 76 +--
.../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/rf.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.h | 4 +-
.../wireless/realtek/rtlwifi/rtl8192c/dm_common.h | 2 +-
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 10 +-
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 83 +--
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.h | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 61 +--
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.h | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 77 +--
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/rf.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/dm.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 73 +--
.../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 16 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/phy.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/rf.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.h | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/rf.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 6 +-
.../wireless/realtek/rtlwifi/rtl8723ae/hal_btc.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 307 +++++------
.../net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/rf.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.h | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 76 +--
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/rf.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.h | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 86 +--
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 62 +--
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/rf.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 16 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 10 +-
drivers/net/wireless/realtek/rtlwifi/stats.c | 6 +-
drivers/net/wireless/realtek/rtlwifi/stats.h | 4 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 68 +--
drivers/net/wireless/ti/wl18xx/event.c | 26 +-
drivers/net/wireless/ti/wl18xx/event.h | 19 +-
drivers/net/wireless/ti/wlcore/cmd.c | 7 +
drivers/net/wireless/ti/wlcore/main.c | 5 +
drivers/net/wireless/ti/wlcore/sdio.c | 1 -
165 files changed, 3695 insertions(+), 1968 deletions(-)
create mode 100644 drivers/net/wireless/intel/iwlwifi/iwl-a000.c
The example resolution from 'git diff':
diff --cc drivers/net/wireless/intel/iwlwifi/mvm/scan.c
index 1cac10c5d818,fb25d9e41912..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@@ -400,9 -396,10 +400,9 @@@ void iwl_mvm_rx_lmac_scan_complete_noti
iwl_mvm_ebs_status_str(scan_notif->ebs_status));
mvm->scan_status &= ~IWL_MVM_SCAN_REGULAR;
- ieee80211_scan_completed(mvm->hw,
- scan_notif->status == IWL_SCAN_OFFLOAD_ABORTED);
+ ieee80211_scan_completed(mvm->hw, &info);
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- del_timer(&mvm->scan_timer);
+ cancel_delayed_work(&mvm->scan_timeout_dwork);
} else {
IWL_ERR(mvm,
"got scan complete notification but no scan is running\n");
@@@ -1433,13 -1432,9 +1435,13 @@@ void iwl_mvm_rx_umac_scan_complete_noti
/* if the scan is already stopping, we don't need to notify mac80211 */
if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_REGULAR) {
- ieee80211_scan_completed(mvm->hw, aborted);
+ struct cfg80211_scan_info info = {
+ .aborted = aborted,
+ };
+
+ ieee80211_scan_completed(mvm->hw, &info);
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- del_timer(&mvm->scan_timer);
+ cancel_delayed_work(&mvm->scan_timeout_dwork);
} else if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_SCHED) {
ieee80211_sched_scan_stopped(mvm->hw);
mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;
@@@ -1644,14 -1630,9 +1646,14 @@@ out
* to release the scan reference here.
*/
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
- del_timer(&mvm->scan_timer);
+ cancel_delayed_work(&mvm->scan_timeout_dwork);
- if (notify)
- ieee80211_scan_completed(mvm->hw, true);
+ if (notify) {
+ struct cfg80211_scan_info info = {
+ .aborted = true,
+ };
+
+ ieee80211_scan_completed(mvm->hw, &info);
+ }
} else if (notify) {
ieee80211_sched_scan_stopped(mvm->hw);
mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;
diff --cc drivers/net/wireless/marvell/mwifiex/cmdevt.c
index e7a21443647e,c29f26d8baf2..000000000000
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index a2c84171fbc3..21ec84794d0c 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -2029,9 +2029,13 @@ void mwifiex_cancel_scan(struct mwifiex_adapter *adapter)
if (!priv)
continue;
if (priv->scan_request) {
+ struct cfg80211_scan_info info = {
+ .aborted = true,
+ };
+
mwifiex_dbg(adapter, INFO,
"info: aborting scan\n");
- cfg80211_scan_done(priv->scan_request, 1);
+ cfg80211_scan_done(priv->scan_request, &info);
priv->scan_request = NULL;
priv->scan_aborting = false;
}
^ permalink raw reply related
* RE: [PATCH v3 1/2] mwifiex: add manufacturing mode support
From: Amitkumar Karwar @ 2016-07-13 16:39 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <87eg6xzeih.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Wednesday, July 13, 2016 10:01 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
> Subject: Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> > Hi Kalle,
> >
> >> -----Original Message-----
> >> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> >> Sent: Wednesday, July 13, 2016 9:20 PM
> >> To: Amitkumar Karwar
> >> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
> >> Subject: Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
> >>
> >> Amitkumar Karwar <akarwar@marvell.com> writes:
> >>
> >> > By default normal mode is chosen when driver is loaded. This patch
> >> > adds a provision to choose manufacturing mode via module
> parameters.
> >> >
> >> > Command to load driver in manufacturing mode insmod mwifiex.ko
> >> > mfg_mode=1 and mfg_firmware=mrvl/firmware.
> >> >
> >> > Tested-by: chunfan chen <jeffc@marvell.com>
> >> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> >>
> >> Why the mfg_firmware module parameter?
> >
> > It's to specify a firmware name.
>
> Yeah, I got that. But why do you need that? Why not just hardcode the
> firmware name in the driver, which is the normal thing to do?
Ok. I will do this in updated version.
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
From: Kalle Valo @ 2016-07-13 16:31 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <2dcba20e490840918e80c4f91a250739@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> Hi Kalle,
>
>> -----Original Message-----
>> From: Kalle Valo [mailto:kvalo@codeaurora.org]
>> Sent: Wednesday, July 13, 2016 9:20 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
>> Subject: Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
>>
>> Amitkumar Karwar <akarwar@marvell.com> writes:
>>
>> > By default normal mode is chosen when driver is loaded. This patch
>> > adds a provision to choose manufacturing mode via module parameters.
>> >
>> > Command to load driver in manufacturing mode insmod mwifiex.ko
>> > mfg_mode=1 and mfg_firmware=mrvl/firmware.
>> >
>> > Tested-by: chunfan chen <jeffc@marvell.com>
>> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>>
>> Why the mfg_firmware module parameter?
>
> It's to specify a firmware name.
Yeah, I got that. But why do you need that? Why not just hardcode the
firmware name in the driver, which is the normal thing to do?
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
From: Amitkumar Karwar @ 2016-07-13 15:59 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
Xinming Hu
In-Reply-To: <87inw9zghp.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Wednesday, July 13, 2016 9:18 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> Xinming Hu
> Subject: Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> > Hi Kalle,
> >
> >> -----Original Message-----
> >> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> >> Sent: Wednesday, July 13, 2016 8:44 PM
> >> To: Amitkumar Karwar
> >> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> >> Xinming Hu
> >> Subject: Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
> >>
> >> Amitkumar Karwar <akarwar@marvell.com> writes:
> >>
> >> > From: Xinming Hu <huxm@marvell.com>
> >> >
> >> > This patch adds ndo_ioctl support to mwifiex netdev handlers.
> >> > This will be used to download hostcmds to firmware from userspace.
> >> > This is needed for manufacturing mode support in mwifiex. ndo_ioctl
> >> > is allowed only when mfg mode is enabled via module load
> parameters.
> >> >
> >> > Signed-off-by: Xinming Hu <huxm@marvell.com>
> >> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> >> > ---
> >> > v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test
> >> > robot
> >> errors.
> >> > WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
> >> > v2: 1) Sequence of these two patches are changed to resolve
> >> compilation
> >> > error seen if only 1/2 is applied.
> >> > 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings
> >> > reported
> >> by
> >> > kbuild test robot.
> >>
> >> Why can't you use nl80211 testmode interface?
> >
> > These two patches facilitates user to configure manufacturing mode. We
> > have a separate firmware for this mode. It's needed to run special
> > WiFi conductive and radiated tests at factory.
>
> This is exactly what nl80211 testmode is for.
>
> > The userspace tools used for this purpose expects WEXT interface.
>
> So convert them to use nl80211. I have done that myself, multiple times
> actually.
>
> And for wireless extensions, from my point of view it's dead and buried.
> I'm not going to take any new wireless extension related code.
Thanks for your feedback. We will change the tools and prepare driver patch using nl80211 testmode.
Regards,
Amitkumar
^ permalink raw reply
* RE: [PATCH v3 1/2] mwifiex: add manufacturing mode support
From: Amitkumar Karwar @ 2016-07-13 15:57 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <87twfta66k.fsf@purkki.adurom.net>
Hi Kalle,
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Wednesday, July 13, 2016 9:20 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
> Subject: Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> > By default normal mode is chosen when driver is loaded. This patch
> > adds a provision to choose manufacturing mode via module parameters.
> >
> > Command to load driver in manufacturing mode insmod mwifiex.ko
> > mfg_mode=1 and mfg_firmware=mrvl/firmware.
> >
> > Tested-by: chunfan chen <jeffc@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>
> Why the mfg_firmware module parameter?
It's to specify a firmware name.
Regards,
Amitkumar Karwar
^ permalink raw reply
* Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
From: Kalle Valo @ 2016-07-13 15:50 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <1468417703-32716-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> By default normal mode is chosen when driver is loaded. This patch adds
> a provision to choose manufacturing mode via module parameters.
>
> Command to load driver in manufacturing mode
> insmod mwifiex.ko mfg_mode=1 and mfg_firmware=mrvl/firmware.
>
> Tested-by: chunfan chen <jeffc@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Why the mfg_firmware module parameter?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
From: Kalle Valo @ 2016-07-13 15:48 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
Xinming Hu
In-Reply-To: <35fedc2035a64135a4d995aca379d4e9@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> Hi Kalle,
>
>> -----Original Message-----
>> From: Kalle Valo [mailto:kvalo@codeaurora.org]
>> Sent: Wednesday, July 13, 2016 8:44 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> Xinming Hu
>> Subject: Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
>>
>> Amitkumar Karwar <akarwar@marvell.com> writes:
>>
>> > From: Xinming Hu <huxm@marvell.com>
>> >
>> > This patch adds ndo_ioctl support to mwifiex netdev handlers.
>> > This will be used to download hostcmds to firmware from userspace.
>> > This is needed for manufacturing mode support in mwifiex. ndo_ioctl is
>> > allowed only when mfg mode is enabled via module load parameters.
>> >
>> > Signed-off-by: Xinming Hu <huxm@marvell.com>
>> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>> > ---
>> > v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test robot
>> errors.
>> > WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
>> > v2: 1) Sequence of these two patches are changed to resolve
>> compilation
>> > error seen if only 1/2 is applied.
>> > 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported
>> by
>> > kbuild test robot.
>>
>> Why can't you use nl80211 testmode interface?
>
> These two patches facilitates user to configure manufacturing mode. We
> have a separate firmware for this mode. It's needed to run special
> WiFi conductive and radiated tests at factory.
This is exactly what nl80211 testmode is for.
> The userspace tools used for this purpose expects WEXT interface.
So convert them to use nl80211. I have done that myself, multiple times
actually.
And for wireless extensions, from my point of view it's dead and buried.
I'm not going to take any new wireless extension related code.
--
Kalle Valo
^ permalink raw reply
* RE: building brcmfmac driver for iMX6 Ultralite platform
From: Michael Eskowitz @ 2016-07-13 14:51 UTC (permalink / raw)
To: 'Rafał Miłecki'
Cc: 'Arend Van Spriel', linux-wireless
In-Reply-To: <CACna6rzU91CRGmgPtAgEhdqwpSGSs0i-C3qL7OiB8soHk8vq8Q@mail.gmail.com>
>> Arend,
>
>What about my reply? ;)
Sorry. No offense intended. I clearly need to not treat this as email. I'll figure out the protocol soon enough.
>
>
>> That is news to me. I was under the impression that bcmdhd was
>> Broadcom's proprietary (closed source) Linux driver and brcmfmac was
>> the open source Linux driver.
>
>Don't top post. It's hard to say what you're replying to. bcmdhd is also open source (not sure what license), just not mainline.
>
>
>> Either way, I am now running
>>
>> insmod brcmutil.ko
>> insmod brcmfmac.ko
>>
>> I receive no errors and no kernel messages.
>>
>> When I insert the 43341 module into the SDIO slot nothing happens.
>> I'm guessing that the version of the brcmfmac driver that I built does
>> not support that chip.
>
>Is is detected by the system? If so, what ID does it use?
>
The system recognizes that an mmc card has been inserted. The driver doesn't see the module, however. Looking at the page
https://wireless.wiki.kernel.org/en/users/drivers/brcm80211
suggests that I simply need to move to a newer Linux kernel as I am using 3.14.38. NXP recently posted a 4.1.15 install so I will try getting the 43341 module up and running with that.
>
>> When I insert the 43362 module into the SDIO slot I receive the
>> following errors
>>
>> mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>> mmc0: new high speed SDIO card at address 0001
>> brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jun
>> 7 2012
>> 18:27:16 version 5.90.225 FWID 01-d8fe14bd
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
>> brcmfmac: brcmf_add_if: ignore IF event
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_construct_reginfo: channel 1: f=2412 bw=0
>> sb=-1998840228
>> brcmfmac: brcmf_construct_reginfo: channel 2: f=2417 bw=0
>> sb=-1998840228
>>
>> and suddenly ifconfig shows the interface wlan0. The interface looks
>> to be valid as it is displaying a MAC from our address range.
>>
>> Although the interface wlan0 is present I am not able to use wl
>> commands to scan for networks. wl reports "wl driver adapter not
>> found" for all command arguments. If I run the command
>>
>> iwlist wlan0 scan
>>
>> I'm told that the interface does not support scanning. If I run
>> wpa_cli and then the commands scan and scanresults I don't see any networks.
>
>"wl" user space tool uses wlioctl, proprietary protocol, brcmfmac doesn't support it.
>
>iwlist uses wext protocol, legacy one.
>
>Please use nl80211 based tools, e.g. "iw".
I was able to scan with iw and join a WPA2 protected network using wpa_supplicant. It would appear that I have the 43362 up and running with the brcmfmac driver. I will try the other Linux install for the 43341.
Thank you all for all your help. It is much appreciated. :-)
-Mike
^ permalink raw reply
* RE: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
From: Amitkumar Karwar @ 2016-07-13 15:25 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
Xinming Hu
In-Reply-To: <87y455a7u3.fsf@purkki.adurom.net>
Hi Kalle,
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Wednesday, July 13, 2016 8:44 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> Xinming Hu
> Subject: Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> > From: Xinming Hu <huxm@marvell.com>
> >
> > This patch adds ndo_ioctl support to mwifiex netdev handlers.
> > This will be used to download hostcmds to firmware from userspace.
> > This is needed for manufacturing mode support in mwifiex. ndo_ioctl is
> > allowed only when mfg mode is enabled via module load parameters.
> >
> > Signed-off-by: Xinming Hu <huxm@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > ---
> > v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test robot
> errors.
> > WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
> > v2: 1) Sequence of these two patches are changed to resolve
> compilation
> > error seen if only 1/2 is applied.
> > 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported
> by
> > kbuild test robot.
>
> Why can't you use nl80211 testmode interface?
These two patches facilitates user to configure manufacturing mode. We have a separate firmware for this mode.
It's needed to run special WiFi conductive and radiated tests at factory. The userspace tools used for this purpose expects WEXT interface.
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
From: Kalle Valo @ 2016-07-13 15:14 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Xinming Hu
In-Reply-To: <1468417703-32716-2-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch adds ndo_ioctl support to mwifiex netdev handlers.
> This will be used to download hostcmds to firmware from userspace.
> This is needed for manufacturing mode support in mwifiex. ndo_ioctl
> is allowed only when mfg mode is enabled via module load parameters.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test robot errors.
> WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
> v2: 1) Sequence of these two patches are changed to resolve compilation
> error seen if only 1/2 is applied.
> 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported by
> kbuild test robot.
Why can't you use nl80211 testmode interface?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received
From: Bob Copeland @ 2016-07-13 13:50 UTC (permalink / raw)
To: Masashi Honma; +Cc: johannes, linux-wireless, j
In-Reply-To: <1468393475-2483-1-git-send-email-masashi.honma@gmail.com>
On Wed, Jul 13, 2016 at 04:04:35PM +0900, Masashi Honma wrote:
> The mesh STA sends QoS frame with EOSP (end of service period)
> subfiled=1 to end the MPSP(mesh peer service period). Previously, if
> the frame was not acked by peer, the mesh STA did not end the MPSP.
> This patch ends the MPSP even if the QoS frame was no acked.
Hmm, my recollection on this stuff is a little fuzzy. So we only get
here if the peer sta is in doze state, but it shouldn't do that if we
are in an MPSP. So, is the real problem that we don't wait for an ack
from the peer before marking ourselves in a MPSP?
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* [PATCH v3 1/2] mwifiex: add manufacturing mode support
From: Amitkumar Karwar @ 2016-07-13 13:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
By default normal mode is chosen when driver is loaded. This patch adds
a provision to choose manufacturing mode via module parameters.
Command to load driver in manufacturing mode
insmod mwifiex.ko mfg_mode=1 and mfg_firmware=mrvl/firmware.
Tested-by: chunfan chen <jeffc@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 8 ++++++
drivers/net/wireless/marvell/mwifiex/init.c | 22 +++++++++++------
drivers/net/wireless/marvell/mwifiex/main.c | 35 ++++++++++++++++++++++++---
drivers/net/wireless/marvell/mwifiex/main.h | 4 +++
drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 2 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 2 +-
7 files changed, 61 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index c29f26d..8d57493 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -581,6 +581,14 @@ int mwifiex_send_cmd(struct mwifiex_private *priv, u16 cmd_no,
return -1;
}
}
+ /* We don't expect commands in manufacturing mode. They are cooked
+ * in application and ready to download buffer is passed to the driver
+ */
+ if (adapter->mfg_mode && cmd_no) {
+ dev_dbg(adapter->dev, "Ignoring commands in manufacturing mode\n");
+ return -1;
+ }
+
/* Get a new command node */
cmd_node = mwifiex_get_cmd_node(adapter);
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index 1489c90..82839d9 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -298,6 +298,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter)
memset(&adapter->arp_filter, 0, sizeof(adapter->arp_filter));
adapter->arp_filter_size = 0;
adapter->max_mgmt_ie_index = MAX_MGMT_IE_INDEX;
+ adapter->mfg_mode = mfg_mode;
adapter->key_api_major_ver = 0;
adapter->key_api_minor_ver = 0;
eth_broadcast_addr(adapter->perm_addr);
@@ -553,15 +554,22 @@ int mwifiex_init_fw(struct mwifiex_adapter *adapter)
return -1;
}
}
+ if (adapter->mfg_mode) {
+ adapter->hw_status = MWIFIEX_HW_STATUS_READY;
+ ret = -EINPROGRESS;
+ } else {
+ for (i = 0; i < adapter->priv_num; i++) {
+ if (adapter->priv[i]) {
+ ret = mwifiex_sta_init_cmd(adapter->priv[i],
+ first_sta, true);
+ if (ret == -1)
+ return -1;
+
+ first_sta = false;
+ }
+
- for (i = 0; i < adapter->priv_num; i++) {
- if (adapter->priv[i]) {
- ret = mwifiex_sta_init_cmd(adapter->priv[i], first_sta,
- true);
- if (ret == -1)
- return -1;
- first_sta = false;
}
}
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 0e280f8..b54edf4 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -36,6 +36,14 @@ static unsigned short driver_mode;
module_param(driver_mode, ushort, 0);
MODULE_PARM_DESC(driver_mode,
"station=0x1(default), ap-sta=0x3, station-p2p=0x5, ap-sta-p2p=0x7");
+bool mfg_mode;
+module_param(mfg_mode, bool, 0);
+MODULE_PARM_DESC(mfg_mode, "0:disable 1:enable (bool)");
+
+char *mfg_firmware = "";
+module_param(mfg_firmware, charp, 0);
+MODULE_PARM_DESC(mfg_firmware, "firmware path");
+
/*
* This function registers the device and performs all the necessary
@@ -559,10 +567,12 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
goto done;
}
/* Wait for mwifiex_init to complete */
- wait_event_interruptible(adapter->init_wait_q,
- adapter->init_wait_q_woken);
- if (adapter->hw_status != MWIFIEX_HW_STATUS_READY)
- goto err_init_fw;
+ if (!adapter->mfg_mode) {
+ wait_event_interruptible(adapter->init_wait_q,
+ adapter->init_wait_q_woken);
+ if (adapter->hw_status != MWIFIEX_HW_STATUS_READY)
+ goto err_init_fw;
+ }
priv = adapter->priv[MWIFIEX_BSS_ROLE_STA];
if (mwifiex_register_cfg80211(adapter)) {
@@ -666,6 +676,23 @@ static int mwifiex_init_hw_fw(struct mwifiex_adapter *adapter)
{
int ret;
+ if (mfg_mode && !strlen(mfg_firmware)) {
+ pr_err("%s: mfg firmware missing. Ignoring manufacturing mode\n",
+ __func__);
+ mfg_mode = false;
+ }
+
+ /* Override default firmware with manufacturing one if
+ * manufacturing mode is enabled
+ */
+ if (mfg_mode) {
+ if (strlcpy(adapter->fw_name, mfg_firmware,
+ sizeof(adapter->fw_name)) >=
+ sizeof(adapter->fw_name)) {
+ pr_err("%s: fw_name too long!\n", __func__);
+ return -1;
+ }
+ }
ret = request_firmware_nowait(THIS_MODULE, 1, adapter->fw_name,
adapter->dev, GFP_KERNEL, adapter,
mwifiex_fw_dpc);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 9f6bb40..ee71e4a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -58,6 +58,9 @@
#include "sdio.h"
extern const char driver_version[];
+extern bool mfg_mode;
+extern char *mfg_firmware;
+
struct mwifiex_adapter;
struct mwifiex_private;
@@ -989,6 +992,7 @@ struct mwifiex_adapter {
u32 drv_info_size;
bool scan_chan_gap_enabled;
struct sk_buff_head rx_data_q;
+ bool mfg_mode;
struct mwifiex_chan_stats *chan_stats;
u32 num_in_chan_stats;
int survey_idx;
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 22fe993..e54a98a 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -226,7 +226,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
- if (user_rmmod) {
+ if (user_rmmod && !adapter->mfg_mode) {
#ifdef CONFIG_PM_SLEEP
if (adapter->is_suspended)
mwifiex_pcie_resume(&pdev->dev);
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..6dba409 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -289,7 +289,7 @@ mwifiex_sdio_remove(struct sdio_func *func)
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
- if (user_rmmod) {
+ if (user_rmmod && !adapter->mfg_mode) {
if (adapter->is_suspended)
mwifiex_sdio_resume(adapter->dev);
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index 0857575..ba616ec 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -611,7 +611,7 @@ static void mwifiex_usb_disconnect(struct usb_interface *intf)
if (!adapter->priv_num)
return;
- if (user_rmmod) {
+ if (user_rmmod && !adapter->mfg_mode) {
#ifdef CONFIG_PM
if (adapter->is_suspended)
mwifiex_usb_resume(intf);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
From: Amitkumar Karwar @ 2016-07-13 13:48 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1468417703-32716-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
This patch adds ndo_ioctl support to mwifiex netdev handlers.
This will be used to download hostcmds to firmware from userspace.
This is needed for manufacturing mode support in mwifiex. ndo_ioctl
is allowed only when mfg mode is enabled via module load parameters.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test robot errors.
WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
v2: 1) Sequence of these two patches are changed to resolve compilation
error seen if only 1/2 is applied.
2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported by
kbuild test robot.
---
drivers/net/wireless/marvell/mwifiex/Kconfig | 6 +++
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 59 +++++++++++++++++++++++++++
drivers/net/wireless/marvell/mwifiex/main.c | 38 +++++++++++++++++
drivers/net/wireless/marvell/mwifiex/main.h | 9 +++-
4 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/Kconfig b/drivers/net/wireless/marvell/mwifiex/Kconfig
index 279167d..aed32ce 100644
--- a/drivers/net/wireless/marvell/mwifiex/Kconfig
+++ b/drivers/net/wireless/marvell/mwifiex/Kconfig
@@ -13,6 +13,8 @@ config MWIFIEX_SDIO
depends on MWIFIEX && MMC
select FW_LOADER
select WANT_DEV_COREDUMP
+ select WIRELESS_EXT
+ select WEXT_PRIV
---help---
This adds support for wireless adapters based on Marvell
8786/8787/8797/8887/8897/8997 chipsets with SDIO interface.
@@ -25,6 +27,8 @@ config MWIFIEX_PCIE
depends on MWIFIEX && PCI
select FW_LOADER
select WANT_DEV_COREDUMP
+ select WIRELESS_EXT
+ select WEXT_PRIV
---help---
This adds support for wireless adapters based on Marvell
8766/8897/8997 chipsets with PCIe interface.
@@ -36,6 +40,8 @@ config MWIFIEX_USB
tristate "Marvell WiFi-Ex Driver for USB8766/8797/8997"
depends on MWIFIEX && USB
select FW_LOADER
+ select WIRELESS_EXT
+ select WEXT_PRIV
---help---
This adds support for wireless adapters based on Marvell
8797/8997 chipset with USB interface.
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 8d57493..d961305 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -826,6 +826,8 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
hostcmd = adapter->curr_cmd->data_buf;
hostcmd->len = size;
memcpy(hostcmd->cmd, resp, size);
+ adapter->hostcmd_resp_data.len = size;
+ memcpy(adapter->hostcmd_resp_data.cmd, resp, size);
}
}
orig_cmdresp_no = le16_to_cpu(resp->command);
@@ -1208,6 +1210,63 @@ mwifiex_process_hs_config(struct mwifiex_adapter *adapter)
false);
}
EXPORT_SYMBOL_GPL(mwifiex_process_hs_config);
+/* This function get hostcmd data from userspace and construct a cmd
+ * to be download to FW.
+ */
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+ struct iwreq *wrq)
+{
+ struct mwifiex_ds_misc_cmd *hostcmd_buf;
+ struct host_cmd_ds_command *cmd;
+ struct mwifiex_adapter *adapter = priv->adapter;
+ int ret;
+
+ hostcmd_buf = kzalloc(sizeof(*hostcmd_buf), GFP_KERNEL);
+ if (!hostcmd_buf)
+ return -ENOMEM;
+
+ cmd = (void *)hostcmd_buf->cmd;
+
+ if (copy_from_user(cmd, wrq->u.data.pointer,
+ sizeof(cmd->command) + sizeof(cmd->size))) {
+ ret = -EFAULT;
+ goto done;
+ }
+
+ hostcmd_buf->len = le16_to_cpu(cmd->size);
+ if (hostcmd_buf->len > MWIFIEX_SIZE_OF_CMD_BUFFER) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ if (copy_from_user(cmd, wrq->u.data.pointer, hostcmd_buf->len)) {
+ ret = -EFAULT;
+ goto done;
+ }
+
+ if (mwifiex_send_cmd(priv, 0, 0, 0, hostcmd_buf, true)) {
+ dev_err(priv->adapter->dev, "Failed to process hostcmd\n");
+ ret = -EFAULT;
+ goto done;
+ }
+
+ if (adapter->hostcmd_resp_data.len > hostcmd_buf->len) {
+ ret = -EFBIG;
+ goto done;
+ }
+
+ if (copy_to_user(wrq->u.data.pointer, adapter->hostcmd_resp_data.cmd,
+ adapter->hostcmd_resp_data.len)) {
+ ret = -EFAULT;
+ goto done;
+ }
+ wrq->u.data.length = adapter->hostcmd_resp_data.len;
+
+ ret = 0;
+done:
+ kfree(hostcmd_buf);
+ return ret;
+}
/*
* This function handles the command response of a sleep confirm command.
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index b54edf4..e3e1fe9 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1238,17 +1238,54 @@ mwifiex_netdev_select_wmm_queue(struct net_device *dev, struct sk_buff *skb,
return mwifiex_1d_to_wmm_queue[skb->priority];
}
+static int mwifiex_do_ioctl(struct net_device *dev, struct ifreq *req, int cmd)
+{
+ struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+ struct iwreq *wrq = (struct iwreq *)req;
+ int ret;
+
+ if (!priv->adapter->mfg_mode)
+ return -EINVAL;
+
+ dev_dbg(priv->adapter->dev, "ioctl cmd = 0x%x\n", cmd);
+
+ switch (cmd) {
+ case MWIFIEX_HOSTCMD_IOCTL:
+ ret = mwifiex_process_host_command(priv, wrq);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
/* Network device handlers */
static const struct net_device_ops mwifiex_netdev_ops = {
.ndo_open = mwifiex_open,
.ndo_stop = mwifiex_close,
.ndo_start_xmit = mwifiex_hard_start_xmit,
.ndo_set_mac_address = mwifiex_set_mac_address,
+ .ndo_do_ioctl = mwifiex_do_ioctl,
.ndo_validate_addr = eth_validate_addr,
.ndo_tx_timeout = mwifiex_tx_timeout,
.ndo_get_stats = mwifiex_get_stats,
.ndo_set_rx_mode = mwifiex_set_multicast_list,
.ndo_select_queue = mwifiex_netdev_select_wmm_queue,
+ };
+
+static const struct iw_priv_args mwifiex_iwpriv_args[] = {
+ { MWIFIEX_HOSTCMD_IOCTL,
+ IW_PRIV_TYPE_BYTE | 2047,
+ IW_PRIV_TYPE_BYTE | 2047,
+ "hostcmd"
+ },
+};
+
+static struct iw_handler_def mwifiex_iwpriv_handler_def = {
+ .num_private_args = ARRAY_SIZE(mwifiex_iwpriv_args),
+ .private_args = (struct iw_priv_args *)mwifiex_iwpriv_args,
};
/*
@@ -1276,6 +1313,7 @@ void mwifiex_init_priv_params(struct mwifiex_private *priv,
{
dev->netdev_ops = &mwifiex_netdev_ops;
dev->destructor = free_netdev;
+ dev->wireless_handlers = &mwifiex_iwpriv_handler_def;
/* Initialize private structure */
priv->current_key_index = 0;
priv->media_connected = false;
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index ee71e4a..5713fe5 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -48,6 +48,8 @@
#include <linux/pm_runtime.h>
#include <linux/slab.h>
#include <linux/of_irq.h>
+#include <linux/wireless.h>
+#include <net/iw_handler.h>
#include "decl.h"
#include "ioctl.h"
@@ -160,6 +162,9 @@ enum {
/* Threshold for tx_timeout_cnt before we trigger a card reset */
#define TX_TIMEOUT_THRESHOLD 6
+/* IOCTL number used for hostcmd process*/
+#define MWIFIEX_HOSTCMD_IOCTL (SIOCIWFIRSTPRIV + 17)
+
#define MWIFIEX_DRV_INFO_SIZE_MAX 0x40000
/* Address alignment */
@@ -895,6 +900,7 @@ struct mwifiex_adapter {
u8 event_received;
u8 data_received;
u16 seq_num;
+ struct mwifiex_ds_misc_cmd hostcmd_resp_data;
struct cmd_ctrl_node *cmd_pool;
struct cmd_ctrl_node *curr_cmd;
/* spin lock for command */
@@ -1557,7 +1563,8 @@ bool mwifiex_is_bss_in_11ac_mode(struct mwifiex_private *priv);
u8 mwifiex_get_center_freq_index(struct mwifiex_private *priv, u8 band,
u32 pri_chan, u8 chan_bw);
int mwifiex_init_channel_scan_gap(struct mwifiex_adapter *adapter);
-
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+ struct iwreq *wrq);
int mwifiex_tdls_check_tx(struct mwifiex_private *priv, struct sk_buff *skb);
void mwifiex_flush_auto_tdls_list(struct mwifiex_private *priv);
void mwifiex_auto_tdls_update_peer_status(struct mwifiex_private *priv,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped
From: Bob Copeland @ 2016-07-13 13:33 UTC (permalink / raw)
To: Machani, Yaniv
Cc: Johannes Berg, linux-kernel@vger.kernel.org, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
Hahn, Maital
In-Reply-To: <AE1C82FB3D0EC64DB1F752C81CBD1101391FC38C@DFRE01.ent.ti.com>
On Wed, Jul 13, 2016 at 10:11:25AM +0000, Machani, Yaniv wrote:
> > > 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.
> > >
> > How well have you tested that with other drivers?
> >
>
> Sorry for the delayed response (I've been out) and thanks for your comments,
> I have tested it with RT3572 as well, and didn't see any issue.
> I'll update the comment to reflect that.
I'll give this a test on ath10k and wcn36xx as they are the ones most
likely to care about ordering.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH v2 2/2] mwifiex: add hostcmd wext ioctl support
From: kbuild test robot @ 2016-07-13 13:23 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: kbuild-all, linux-wireless, Cathy Luo, Nishant Sarmukadam,
Xinming Hu, Amitkumar Karwar
In-Reply-To: <1468408746-28376-2-git-send-email-akarwar@marvell.com>
[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]
Hi,
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.7-rc7 next-20160712]
[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/Amitkumar-Karwar/mwifiex-add-manufacturing-mode-support/20160713-192928
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: arm-exynos_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
net/wireless/wext-core.c: In function 'wireless_process_ioctl':
>> net/wireless/wext-core.c:942:31: error: 'struct net_device' has no member named 'wireless_handlers'
if (cmd == SIOCGIWPRIV && dev->wireless_handlers)
^
--
net/wireless/wext-priv.c: In function 'iw_handler_get_private':
>> net/wireless/wext-priv.c:22:10: error: 'struct net_device' has no member named 'wireless_handlers'
if ((dev->wireless_handlers->num_private_args == 0) ||
^
net/wireless/wext-priv.c:23:9: error: 'struct net_device' has no member named 'wireless_handlers'
(dev->wireless_handlers->private_args == NULL))
^
net/wireless/wext-priv.c:27:29: error: 'struct net_device' has no member named 'wireless_handlers'
if (wrqu->data.length < dev->wireless_handlers->num_private_args) {
^
net/wireless/wext-priv.c:31:26: error: 'struct net_device' has no member named 'wireless_handlers'
wrqu->data.length = dev->wireless_handlers->num_private_args;
^
net/wireless/wext-priv.c:36:25: error: 'struct net_device' has no member named 'wireless_handlers'
wrqu->data.length = dev->wireless_handlers->num_private_args;
^
net/wireless/wext-priv.c:39:19: error: 'struct net_device' has no member named 'wireless_handlers'
memcpy(extra, dev->wireless_handlers->private_args,
^
net/wireless/wext-priv.c: In function 'get_priv_descr_and_size':
net/wireless/wext-priv.c:100:21: error: 'struct net_device' has no member named 'wireless_handlers'
for (i = 0; i < dev->wireless_handlers->num_private_args; i++) {
^
net/wireless/wext-priv.c:101:17: error: 'struct net_device' has no member named 'wireless_handlers'
if (cmd == dev->wireless_handlers->private_args[i].cmd) {
^
net/wireless/wext-priv.c:102:16: error: 'struct net_device' has no member named 'wireless_handlers'
descr = &dev->wireless_handlers->private_args[i];
^
vim +942 net/wireless/wext-core.c
3d23e349 net/wireless/wext-core.c Johannes Berg 2009-09-29 936 * (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST) */
3d23e349 net/wireless/wext-core.c Johannes Berg 2009-09-29 937 if (cmd == SIOCGIWSTATS)
3d23e349 net/wireless/wext-core.c Johannes Berg 2009-09-29 938 return standard(dev, iwr, cmd, info,
3d23e349 net/wireless/wext-core.c Johannes Berg 2009-09-29 939 &iw_handler_get_iwstats);
^1da177e net/core/wireless.c Linus Torvalds 2005-04-16 940
3d23e349 net/wireless/wext-core.c Johannes Berg 2009-09-29 941 #ifdef CONFIG_WEXT_PRIV
dd8ceabc net/wireless/wext.c Johannes Berg 2007-04-26 @942 if (cmd == SIOCGIWPRIV && dev->wireless_handlers)
0f5cabba net/wireless/wext.c David S. Miller 2008-06-03 943 return standard(dev, iwr, cmd, info,
3d23e349 net/wireless/wext-core.c Johannes Berg 2009-09-29 944 iw_handler_get_private);
3d23e349 net/wireless/wext-core.c Johannes Berg 2009-09-29 945 #endif
:::::: The code at line 942 was first introduced by commit
:::::: dd8ceabcd10d47f6f28ecfaf2eac7beffca11b3c [WEXT]: Cleanup early ioctl call path.
:::::: TO: Johannes Berg <johannes@sipsolutions.net>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 24983 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status
From: Marcel Holtmann @ 2016-07-13 13:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Gustavo F. Padovan, Johan Hedberg, Mauro Carvalho Chehab,
Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
Greg Kroah-Hartman, Pavan Savoy, Arnd Bergmann,
open list:BLUETOOTH DRIVERS, linux-media, linux-wireless,
linux-kernel
In-Reply-To: <1465203723-16928-1-git-send-email-geert@linux-m68k.org>
Hi Geert,
> On mips and parisc:
>
> drivers/bluetooth/btwilink.c: In function 'ti_st_open':
> drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit constant conversion [-Woverflow]
> hst->reg_status = -EINPROGRESS;
>
> drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
> drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant conversion [-Woverflow]
> drv->st_register_cb_status = -EINPROGRESS;
>
> There are actually two issues:
> 1. Whether "char" is signed or unsigned depends on the architecture.
> As the completion callback data is used to pass a (negative) error
> code, it should always be signed.
> 2. EINPROGRESS is 150 on mips, 245 on parisc.
> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
>
> Change the callback status from "char" to "int" to fix these.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Compile-tested only.
> ---
> drivers/bluetooth/btwilink.c | 4 ++--
> drivers/media/radio/wl128x/fmdrv_common.c | 2 +-
> drivers/misc/ti-st/st_core.c | 2 +-
> drivers/nfc/nfcwilink.c | 4 ++--
> include/linux/ti_wilink_st.h | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Sergei Shtylyov @ 2016-07-13 12:33 UTC (permalink / raw)
To: Yaniv Machani, linux-kernel
Cc: Meirav Kama, Johannes Berg, David S. Miller, linux-wireless,
netdev
In-Reply-To: <20160713114542.24937-1-yanivma@ti.com>
Hello.
On 7/13/2016 2:45 PM, Yaniv Machani wrote:
> The HT capab info field inside the HT capab IE of the mesh beacon
> is incorrect (in the case of 20MHz channel width).
> To fix this driver will check configuration from cfg and
> will build it accordingly.
>
> Signed-off-by: Meirav Kama <meiravk@ti.com>
> Signed-off-by: Yaniv Machani <yanivma@ti.com>
> ---
> V3 - Updated comment
> - Removed CFG changes, as they are not correct.
>
> net/mac80211/mesh.c | 33 ++++++++++++++++++++++++++++++++-
> net/mac80211/util.c | 3 ---
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
> index 9214bc1..275131d 100644
> --- a/net/mac80211/mesh.c
> +++ b/net/mac80211/mesh.c
> @@ -422,6 +422,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;
> +
Why add more empty lines where you already one?
>
> sband = local->hw.wiphy->bands[band];
> if (!sband->ht_cap.ht_supported ||
> @@ -430,11 +432,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 */
Please use tab, not spaces.
> + cap = sband->ht_cap.cap;
> +
> + /* if channel width is 20MHz - configure HT capab accordingly*/
Likewise.
> + 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);
No *break*? You need a comment like /* FALL THRU */ then...
> + 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, &sband->ht_cap, sband->ht_cap.cap);
> + ieee80211_ie_build_ht_cap(pos, &sband->ht_cap, cap);
>
> return 0;
> }
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH v2] mac80211: rx: frames received out of order
From: Yaniv Machani @ 2016-07-13 11:57 UTC (permalink / raw)
To: linux-kernel
Cc: Meirav Kama, Yaniv Machani, Johannes Berg, David S. Miller,
linux-wireless, netdev
From: Meirav Kama <meiravk@ti.com>
Upon forwarding frames from Rx to Tx in mesh, driver clones the skb.
It zeros the tx_info and doesn't set hw_queue correctly. It then enqueues
the frame in queue 0 (VOICE) instead of the correct queue.
Upon re-queue of this frame, driver inserts it to the correct queue (e.g. BE).
After that, driver dequeue frames from 2 different queues and sends them out of order.
To fix this, driver will set the tx_info->hw_queue to the correct queue when cloning the skb.
Signed-off-by: Meirav Kama <meiravk@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
---
V2 - Revised comment
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 = &rx->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
^ permalink raw reply related
* [PATCH] mac80211: rx: frames received out of order
From: Yaniv Machani @ 2016-07-13 11:46 UTC (permalink / raw)
To: linux-kernel
Cc: Meirav Kama, Yaniv Machani, Johannes Berg, David S. Miller,
linux-wireless, netdev
From: Meirav Kama <meiravk@ti.com>
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 <meiravk@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
---
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 = &rx->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
^ permalink raw reply related
* [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Yaniv Machani @ 2016-07-13 11:45 UTC (permalink / raw)
To: linux-kernel
Cc: Yaniv Machani, Meirav Kama, Johannes Berg, David S. Miller,
linux-wireless, netdev
The HT capab info field inside the HT capab IE of the mesh beacon
is incorrect (in the case of 20MHz channel width).
To fix this driver will check configuration from cfg and
will build it accordingly.
Signed-off-by: Meirav Kama <meiravk@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
---
V3 - Updated comment
- Removed CFG changes, as they are not correct.
net/mac80211/mesh.c | 33 ++++++++++++++++++++++++++++++++-
net/mac80211/util.c | 3 ---
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 9214bc1..275131d 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -422,6 +422,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 ||
@@ -430,11 +432,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, &sband->ht_cap, sband->ht_cap.cap);
+ ieee80211_ie_build_ht_cap(pos, &sband->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 = 0x0000;
- /* It seems that Basic MCS set and Supported MCS set
- are identical for the first 10 bytes */
memset(&ht_oper->basic_set, 0, 16);
- memcpy(&ht_oper->basic_set, &ht_cap->mcs, 10);
return pos + sizeof(struct ieee80211_ht_operation);
}
--
2.9.0
^ permalink raw reply related
* [PATCH v2 2/3] mac80211: mesh: improve path resolving time
From: Yaniv Machani @ 2016-07-13 11:45 UTC (permalink / raw)
To: linux-kernel
Cc: Yaniv Machani, Maital Hahn, Johannes Berg, David S. Miller,
linux-wireless, netdev
When a packet is received for transmission,
a PREQ frame is sent to resolve the appropriate path to the desired destination.
After path was established, any sequential PREQ will be sent only after
dot11MeshHWMPpreqMinInterval, which usually set to few seconds.
This implementation has an impact in cases where we would like to
resolve the path quickly.
A clear example is when a peer was disconnected from us,
while he acted as a hop to our destination.
Although the path table will be cleared, the next PREQ frame will be sent only after reaching the MinInterval.
This will cause unwanted delay, possibly of few seconds until the traffic will resume.
To improve that, added an 'immediate' flag to be used when the path needs to be resolved.
Once set, a PREQ frame will be send w/o considering the MinInterval parameter.
Signed-off-by: Maital Hahn <maitalm@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
---
v2 - Updated comment to explain the scenario better.
- Removed unnccesary changes that was alreay upstreamed.
net/mac80211/mesh_hwmp.c | 42 +++++++++++++++++++++++++-----------------
1 file changed, 25 insertions(+), 17 deletions(-)
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 = &sdata->u.mesh;
@@ -964,18 +965,24 @@ static void mesh_queue_preq(struct mesh_path *mpath, u8 flags)
++ifmsh->preq_queue_len;
spin_unlock_bh(&ifmsh->mesh_preq_queue_lock);
- if (time_after(jiffies, ifmsh->last_preq + min_preq_int_jiff(sdata)))
+ if (immediate) {
ieee80211_queue_work(&sdata->local->hw, &sdata->work);
+ } else {
+ if (time_after(jiffies,
+ ifmsh->last_preq + min_preq_int_jiff(sdata))) {
+ ieee80211_queue_work(&sdata->local->hw, &sdata->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(&sdata->local->hw, &sdata->work);
- } else
- mod_timer(&ifmsh->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(&sdata->local->hw, &sdata->work);
+ } else
+ mod_timer(&ifmsh->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(&mpath->frame_queue) >= MESH_FRAME_QUEUE_LEN)
skb_to_free = skb_dequeue(&mpath->frame_queue);
@@ -1157,8 +1164,9 @@ int mesh_nexthop_lookup(struct ieee80211_sub_if_data *sdata,
msecs_to_jiffies(sdata->u.mesh.mshcfg.path_refresh_time)) &&
ether_addr_equal(sdata->vif.addr, hdr->addr4) &&
!(mpath->flags & MESH_PATH_RESOLVING) &&
- !(mpath->flags & MESH_PATH_FIXED))
- mesh_queue_preq(mpath, PREQ_Q_F_START | PREQ_Q_F_REFRESH);
+ !(mpath->flags & MESH_PATH_FIXED)) {
+ mesh_queue_preq(mpath, PREQ_Q_F_START | PREQ_Q_F_REFRESH, false);
+ }
next_hop = rcu_dereference(mpath->next_hop);
if (next_hop) {
@@ -1192,7 +1200,7 @@ void mesh_path_timer(unsigned long data)
mpath->discovery_timeout *= 2;
mpath->flags &= ~MESH_PATH_REQ_QUEUED;
spin_unlock_bh(&mpath->state_lock);
- mesh_queue_preq(mpath, 0);
+ mesh_queue_preq(mpath, 0, false);
} else {
mpath->flags &= ~(MESH_PATH_RESOLVING |
MESH_PATH_RESOLVED |
--
2.9.0
^ permalink raw reply related
* [PATCH v2 1/3] mac80211: mesh: flush stations before beacons are stopped
From: Yaniv Machani @ 2016-07-13 11:44 UTC (permalink / raw)
To: linux-kernel
Cc: Maital Hahn, Yaniv Machani, Johannes Berg, David S. Miller,
linux-wireless, netdev
From: Maital Hahn <maitalm@ti.com>
Some drivers (e.g. wl18xx) expect that the last stage in the
de-initialization process will be stopping the beacons, similar to AP flow.
Update ieee80211_stop_mesh() flow accordingly.
As peers can be removed dynamically, this would not impact other drivers.
Tested also on Ralink RT3572 chipset.
Signed-off-by: Maital Hahn <maitalm@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
---
V2- updated comment, patch was tested with RT3572
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, &sdata->state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
+
+ /* remove beacon */
bcn = rcu_dereference_protected(ifmsh->beacon,
lockdep_is_held(&sdata->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(&ifmsh->ps.bc_buf);
skb_queue_purge(&ifmsh->ps.bc_buf);
--
2.9.0
^ permalink raw reply related
* [PATCH v2 0/3] Mesh mpm fixes and enhancements
From: Yaniv Machani @ 2016-07-13 11:44 UTC (permalink / raw)
To: linux-kernel; +Cc: johannes, netdev, linux-wireless, 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.
V2 - Updated patches following review comments.
- Remove unneccary patches (already upsteamed)
Maital Hahn (1):
mac80211: mesh: flush stations before beacons are stopped
Yaniv Machani (2):
mac80211: mesh: improve path resolving time
mac80211: mesh: fixed HT ies in beacon template
net/mac80211/mesh.c | 43 ++++++++++++++++++++++++++++++++++++++-----
net/mac80211/mesh_hwmp.c | 42 +++++++++++++++++++++++++-----------------
net/mac80211/util.c | 3 ---
3 files changed, 63 insertions(+), 25 deletions(-)
--
2.9.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox