Re: [PATCHv2 1/2] mac80211: implement fair queuing per txq

[Michal Kazior]

On 5 April 2016 at 15:57, Johannes Berg  wrote:
> On Thu, 2016-03-31 at 12:28 +0200, Michal Kazior wrote:
>
>> +++ b/net/mac80211/codel.h
>> +++ b/net/mac80211/codel_i.h
>
> Do we really need all this code in .h files? It seems very odd to me to
> have all the algorithm implementation there rather than a C file, you
> should (can?) only include codel.h into a single C file anyway.

I just wanted to follow the suggested/implied usage of codel code and
keep modifications to a minimum. I could very well just assimilate it
if you wish.


>>  struct txq_info {
>> - struct sk_buff_head queue;
>> + struct txq_flow flow;
>> + struct list_head new_flows;
>> + struct list_head old_flows;
>
> This is confusing, can you please document that? Why are there two
> lists of flows, *and* an embedded flow? Is the embedded flow on any of
> the lists?

The new/old flows is follows the same principle as net/sched/sch_fq_codel.c

The embedded flow is for possible collisions, explained below.

Nevertheless I'll add more comments on what-is-what-and-why.


>> + u32 backlog_bytes;
>> + u32 backlog_packets;
>> + u32 drop_codel;
>
> Would it make some sense to at least conceptually layer this a bit?
> I.e. rather than calling this "drop_codel" call it "drop_congestion" or
> something like that?

Sure, I'll change it.


>> +/**
>> + * struct txq_flow - per traffic flow queue
>> + *
>> + * This structure is used to distinguish and queue different traffic flows
>> + * separately for fair queueing/AQM purposes.
>> + *
>> + * @txqi: txq_info structure it is associated at given time
>
> Do we actually have to keep that? It's on a list per txqi, no?

It's used to track ownership.

Packets can be destined to different stations/txqs. At enqueue time I
do a partial hash of a packet to get an "index" which I then use to
address a txq_flow from per-radio list (out of 4096 of them). You can
end up with a situtation like this:
 - packet A hashing to X destined to txq P which is VI
 - packet B hashing to X destined to txq Q which is BK

You can't use the same txq_flow for both A and B because you want to
maintain packets per txqs more than you want to maintain them per flow
(you don't want to queue BK traffic onto VI or vice versa as an
artifact, do you? ;). When a txq_flow doesn't have a txqi it is bound.
Later, if a collision happens (i.e. resulting txq_flow has non-NULL
txqi) the "embedded" per-txq flow is used:

  struct txq_info {
 - struct sk_buff_head queue;
 + struct txq_flow flow; // <--- this

When txq_flow becomes empty its txqi is reset.

The embedded flow is otherwise treated like any other flow, i.e. it
can be linked to old_flows and new_flows.


>> + * @flowchain: can be linked to other flows for RR purposes
>
> RR?

Round-robin. Assuming it's correct to call fq_codel an RR scheme?



>> +void ieee80211_teardown_flows(struct ieee80211_local *local)
>> +{
>> + struct ieee80211_fq *fq = >fq;
>> + struct ieee80211_sub_if_data *sdata;
>> + struct sta_info *sta;
>> + int i;
>> +
>> + if (!local->ops->wake_tx_queue)
>> + return;
>> +
>> + list_for_each_entry_rcu(sta, >sta_list, list)
>> + for (i = 0; i < IEEE80211_NUM_TIDS; i++)
>> + ieee80211_purge_txq(local,
>> + to_txq_info(sta->sta.txq[i]));
>> +
>> + list_for_each_entry_rcu(sdata, >interfaces, list)
>> + ieee80211_purge_txq(local, to_txq_info(sdata->vif.txq));
>
> Using RCU iteration here seems rather strange, since it's a teardown
> flow? That doesn't seem necessary, since it's control path and must be
> holding appropriate locks anyway to make sure nothing is added to the
> lists.

You're probably right. I'll look into changing it.


>
>> + skb = codel_dequeue(flow,
>> + >backlog,
>> + 0,
>> + >cvars,
>> + >cparams,
>> + codel_get_time(),
>> + false);
>
> What happened here? :)

I'm not a huge fan of wrapping functions with a lot of (ugly-looking)
arguments. I can make it a different ugly if you want :)


>> + if (!skb) {
>> + if ((head == >new_flows) &&
>> + !list_empty(>old_flows)) {
>> + list_move_tail(>flowchain, >old_flows);
>> + } else {
>> + list_del_init(>flowchain);
>> + flow->txqi = NULL;
>> + }
>> + goto begin;
>> + }
>
> Ouch. Any way you can make that easier to follow?

This follows net/sched/sch_fq_codel.h. I can put up a comment to
explain what it's supposed to do?


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

Re: [PATCH] mac80211: debugfs var for the default aggregation timeout.

[Avery Pennarun]

On Tue, Feb 23, 2016 at 3:05 PM, Johannes Berg
 wrote:
> On Tue, 2016-02-23 at 13:43 -0500, Avery Pennarun wrote:
>> We're putting my version of the patch into our devices in order to be
>> able to try different values and see how it changes the percentage of
>> devices with nonzero 'pending' field in agg_status.  I'm hoping using
>> zero here will result in total elimination of the pending problem,
>> but we'll see.
>
> :)
> I for one would be interested in the result. And, if you find mac80211
> is at fault, knowing what happens there.

Here's the promised update!  The news is not as good as I had hoped.

Across the GFiber fleet, number of APs per day observing the problem
(ie. the pending field > 0 for more than a minute for any station),
with the original aggregation timeout, is about 41% (yikes).  With the
aggregation timeout set to zero, the number of APs observing the
problem in a day drops to about 10%.

Obviously this is a huge improvement, but the problem isn't completely
eliminated.  In retrospect that's not totally surprising, as there are
reasons other than an AP-side aggregation timeout that an aggregation
would need to be negotiated, and a race condition in aggregation queue
setup could happen at any of those times.  I was just hoping that
those other cases would be much less frequent than they apparently
are.

This test was with backports-20150525 on ath9k.  (We have newer
versions in the queue, but they haven't rolled out to our customers
yet.  Anyway, earlier in this thread, I was able to trigger the race
condition on much newer backports.  Unfortunately the current fix
makes my reproducible test case go away, but I don't know any reason
to assume the race condition is fixed.)

While we're here, unfortunately it turns out that just observing the
agg_status file can cause crashes (though not very often... except for
a few unlucky customers), probably due to a different race condition.
Any suggestions about this one?  Stack trace attached below.  (I think
the stack trace suggests a mac80211 problem?)

Thanks!

Avery


03/30,133400.674 Unable to handle kernel paging request at virtual
address 5b35da9e
03/30,133400.675 pgd = ac238000
03/30,133400.675 [5b35da9e] *pgd=
03/30,133400.675 Internal error: Oops: 5 [#1] PREEMPT SMP
03/30,133400.680 Modules linked in: ccm nf_conntrack_netlink
auto_bridge(O) fci(O) nfnetlink pktgen ath9k_htc(O) mwifiex_usb(O)
mwifiex(O) ath10k_pci(O) ath10k_core(O) arc4 ath9k(O) mac80211(O)
ath9k_common(O) ath9k_hw(O) ath(O) cfg80211(O) compat(O) bmoca(O)
xt_connmark ip6table_mangle xt_CLASSIFY iptable_mangle xt_helper
nf_nat_sip nf_conntrack_sip ip6t_REJECT ip6t_LOG nf_conntrack_ipv6
nf_defrag_ipv6 ip6table_filter ip6_tables nf_nat_rtsp
nf_conntrack_rtsp nf_nat_h323 nf_conntrack_h323 nf_nat_irc
nf_conntrack_irc nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre
nf_nat_proto_gre nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
nf_conntrack_ftp ipt_MASQUERADE ipt_REJECT ipt_LOG xt_limit xt_pkttype
xt_conntrack xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables pfe(O)
03/30,133400.753 CPU: 0Tainted: G   O  (3.2.26 #1)
03/30,133400.758 PC is at sta_agg_status_read+0xeb/0x170 [mac80211]
03/30,133400.764 LR is at sta_agg_status_read+0xd8/0x170 [mac80211]
03/30,133400.770 pc : [<838b4d0c>]lr : [<838b4cf9>]psr: 20010033
03/30,133400.770 sp : ac0c3c58  ip : 000f  fp : ac0c3c71
03/30,133400.782 r10: ac341800  r9 : af7f3b53  r8 : 0001
03/30,133400.787 r7 : 0007  r6 : 5b35da40  r5 : ac0c3f38  r4 : ac0c3d90
03/30,133400.794 r3 : ac0c3d8d  r2 : 838c6958  r1 : 01a8  r0 : ac0c3d90
03/30,133400.800 Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb
 Segment user
03/30,133400.807 Control: 50c53c7d  Table: 2c23804a  DAC: 0015
03/30,133400.813 Process psstat (pid: 25220, stack limit = 0xac0c22f0)
03/30,133400.819 Stack: (0xac0c3c58 to 0xac0c4000)
03/30,133400.824 3c40:
  0209 a6199050
03/30,133400.832 3c60: ac0c3d58 7e957143 0001 ac0c3f88 78656e00
69642074 676f6c61 6b6f745f
03/30,133400.840 3c80: 203a6e65 0a317830 09444954 09585209 4e4b5444
4e535309 58540909 4b544409
03/30,133400.848 3ca0: 6570094e 6e69646e 30300a67 09300909 30307830
30783009 09093030 78300930
03/30,133400.857 3cc0: 30093030 300a3030 30090931 30783009 78300930
09303030 30093009 09303078
03/30,133400.865 3ce0: 0a303030 09093230 78300930 30093030 30303078
09300909 30307830 30303009
03/30,133400.873 3d00: 0933300a 30093009 09303078 30307830 30090930
30783009 30300930 34300a30
03/30,133400.881 3d20: 09300909 30307830 30783009 09093030 78300930
30093030 300a3030 30090935
03/30,133400.889 3d40: 30783009 78300930 09303030 30093009 09303078
0a303030 09093630 78300931
03/30,133400.898 3d60: 30096632 32323678 31090966 38783009 32310933
30343230 3538 0937300a
03/30,133400.906 3d80: 30093109 09303578 31307830 31090961 38300a00
09300909 30307830 30783009
03/30,133400.914 3da0: 09093030 

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Reinoud Koornstra]

On Tue, Apr 5, 2016 at 7:25 AM, Gucea Doru  wrote:
> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
>  wrote:
>>>
>>> Hello,
>>>
>>> I am trying to capture packets that are exchanged between an AP and a
>>> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
>>> traffic from a laptop PC towards the smartphone using iperf.
>>>
>>> The problem is that I can see _only_ the control frames like RTS/CTS, Block
>>> ACK, while the data packets are not captured. I uploaded the Wireshark
>>> capture files at [1] (located inside the folders whose name starts with 
>>> 5Ghz).
>>
>> Most likely the packets on A band have a VHT preamble and your SKU is 11N 
>> only.
>
> My card, Intel 7260 [1]  supports 802.11 ac. So it should also support
> VHT, right? Is there any interface in user-space for checking after
> VHT?
>
> However, I noticed a "failure" message in dmesg:
> [4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
> [4.030570] iwlwifi :04:00.0: irq 37 for MSI/MSI-X
> [4.030760] iwlwifi :04:00.0: Direct firmware load for
> iwlwifi-7260-10.ucode failed with error -2
> [4.035509] iwlwifi :04:00.0: loaded firmware version
> 25.228.9.0 op_mode iwlmvm
> [4.454772] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> Wireless N 7260, REV=0x144
> [4.454825] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [4.455055] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [   15.049933] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [   15.050269] iwlwifi :04:00.0: L1 Disabled - LTR Enabled

The ucode failure isn't a problem, you'll likely find that another
firmware does load.
I've got also a 7620, but mine does support 11ac, so mine does support VHT.

[9.820637] iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144

I also got a firmware load failure, but that's ok

[8.399101] iwlwifi :04:00.0: Direct firmware load for
iwlwifi-7260-17.ucode failed with error -2

Cause here it does load the one it needs:

[9.110486] iwlwifi :04:00.0: loaded firmware version
16.242414.0 op_mode iwlmvm

I did fetch recent firmware by git to be up to date.
I also added some instrumentation to get to see the unsupported splx
structure and in my case it's just because of the package.count isn't
what it should be.
This isn't a problem as well really.

Mar 14 00:32:36 router-dev kernel: [8.273274] iwlwifi
:04:00.0: Unsupported splx structure
Mar 14 00:32:36 router-dev kernel: [8.273276] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: splx->type is 0x04
Mar 14 00:32:36 router-dev kernel: [8.273277] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: splx->package.count is 4
Mar 14 00:32:36 router-dev kernel: [8.273277] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: splx->package.elements[0].type is 0x01
Mar 14 00:32:36 router-dev kernel: [8.273278] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: splx->package.elements[0].integer.value is 0
Mar 14 00:32:36 router-dev kernel: [8.273279] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: limits->type is 0x04
Mar 14 00:32:36 router-dev kernel: [8.273280] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: limits->package.count is 3
Mar 14 00:32:36 router-dev kernel: [8.273281] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: limits->package.elements[0].type is 0x01
Mar 14 00:32:36 router-dev kernel: [8.273281] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: limits->package.elements[1].type is 0x01
Mar 14 00:32:36 router-dev kernel: [8.273282] iwlwifi
:04:00.0: drivers/net/wireless/iwlwifi/pcie/drv.c,
splx_get_pwr_limit: WiFi power is not limited,
domain_type->integer.value is 0

I compiled wpa_supplicant and it connects without trouble to several
access points.
I mostly do it this way, because I maintain the mtk driver I use in
the access point here so I get to see extensive info from both sides
when things go pearshape. :)

>
> Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
> assumption is that the card can't enter into the 802.11 ac mode, it
> just stays into 802.11n.
>
> doru@doru-N551JK:~$ iwconfig wlan0
> wlan0 IEEE 802.11abgn  ESSID:"5_mptcp"
>   Mode:Managed  Frequency:5.24 GHz  Access Point: C4:6E:1F:4B:10:A2
>   Bit Rate=150 Mb/s   Tx-Power=22 dBm
>   Retry short limit:7   RTS thr:off   Fragment thr:off
>   Power Management:on
>   Link Quality=70/70  Signal level=-36 dBm
>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>   Tx excessive retries:0  Invalid misc:22   Missed beacon:0
>
>
> [1] 
> 

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Matthew Garrett]

On Tue, Apr 05, 2016 at 02:40:15PM -0500, Bjorn Helgaas wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=111781 and
> https://mjg59.dreamwidth.org/11235.html describe a sort of similar
> issue, but with DMA.  An interrupt from the device is probably to
> signal a DMA completion, but these problem reports only mention the
> "IRQ nobody cared" issue; I don't see anything about memory
> corruption.

I "fixed" this with 
https://github.com/mjg59/grub-fedora/commit/21fcd6d79b7601e4b20ad70c5408adff2dabbc1d
 
- doing the same in the kernel EFI stub would probably be the best way 
to handle it. This way you're guaranteed to stop DMA before the kernel 
reclaims boot services memory, which guarantees you won't have any 
corruption.

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

[PATCH v2] brcmfmac: Don't increase 8021x_cnt for dropped packets

[per . forlin]

From: Per Forlin 

The pend_8021x_cnt gets into a state where it's not being decreased.
When the brcmf_netdev_wait_pend8021x is called it will timeout
because there are no pending packets to be consumed. There is no
easy way of getting out of this state once it has happened.
Preventing the counter from being increased in case of dropped
packets seem like a reasonable solution.

Log showing overflow txq and increased cnt:

// Extra debug prints
brcmfmac: [brcmf_netdev_wait_pend8021x] pend_8021x_cnt == 0
brcmfmac: [brcmf_netdev_start_xmit] pend_8021x_cnt == 1
brcmfmac: [brcmf_netdev_start_xmit] pend_8021x_cnt == 2

brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!

// Extra debug prints
brcmfmac: [brcmf_netdev_start_xmit] pend_8021x_cnt == 3
brcmfmac: [brcmf_netdev_start_xmit] pend_8021x_cnt == 4
brcmfmac: [brcmf_netdev_wait_pend8021x] pend_8021x_cnt == 4

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)

Signed-off-by: Per Forlin 
---
I came across this bug in an older kernel but it seems relevant
for the latest kernel as well. I'm not familiar with the code
but I can reproduce the issue and verify a fix for it.
With this patch I no longer get stuck with a pend8021_cnt > 0.

Change log:
 v2 - Add variable to know whether the counter is increased or not

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index ed9998b..de80ad8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -196,6 +196,7 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff 
*skb,
struct brcmf_if *ifp = netdev_priv(ndev);
struct brcmf_pub *drvr = ifp->drvr;
struct ethhdr *eh = (struct ethhdr *)(skb->data);
+   bool pend_8021x_cnt_increased = false;
 
brcmf_dbg(DATA, "Enter, bsscfgidx=%d\n", ifp->bsscfgidx);
 
@@ -233,14 +234,18 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff 
*skb,
goto done;
}
 
-   if (eh->h_proto == htons(ETH_P_PAE))
+   if (eh->h_proto == htons(ETH_P_PAE)) {
atomic_inc(>pend_8021x_cnt);
+   pend_8021x_cnt_increased = true;
+   }
 
ret = brcmf_fws_process_skb(ifp, skb);
 
 done:
if (ret) {
ifp->stats.tx_dropped++;
+   if (pend_8021x_cnt_increased)
+   atomic_dec(>pend_8021x_cnt);
} else {
ifp->stats.tx_packets++;
ifp->stats.tx_bytes += skb->len;
-- 
2.1.4

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

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Michael Büsch]

On Tue, 5 Apr 2016 14:40:15 -0500
Bjorn Helgaas  wrote:

> [+cc Matthew]
> 
> Hi Lukas,
> 
> On Tue, Mar 29, 2016 at 08:20:30PM +0200, Lukas Wunner wrote:
> > Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> > on boot until they are reset, causing spurious interrupts if the IRQ is
> > shared. Apparently the EFI bootloader enables the device and does not
> > disable it before passing control to the OS. The bootloader contains a
> > driver for the wireless card which allows it to phone home to Cupertino.
> > This is used for Internet Recovery (download and install OS X images)
> > and probably also for Back to My Mac (remote access, RFC 6281) and to
> > discover stolen hardware.
> > 
> > The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
> > is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
> > reader, HDA card on discrete GPU). As soon as an interrupt handler is
> > installed for one of these devices, the ensuing storm of spurious IRQs
> > causes the kernel to disable the IRQ and switch to polling. This lasts
> > until the b43 driver loads and resets the device.
> > 
> > Loading the b43 driver first is not always an option, in particular with
> > the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
> > installed early on because it is built in, unlike b43 which is usually
> > a module.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
> > Tested-by: Lukas Wunner  [MacBookPro9,1]
> > Signed-off-by: Lukas Wunner 
> > ---
> >  drivers/bcma/bcma_private.h |  2 --
> >  drivers/pci/quirks.c| 27 +++
> >  include/linux/bcma/bcma.h   |  1 +
> >  3 files changed, 28 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
> > index eda0909..f642c42 100644
> > --- a/drivers/bcma/bcma_private.h
> > +++ b/drivers/bcma/bcma_private.h
> > @@ -8,8 +8,6 @@
> >  #include 
> >  #include 
> >  
> > -#define BCMA_CORE_SIZE 0x1000
> > -
> >  #define bcma_err(bus, fmt, ...) \
> > pr_err("bus%d: " fmt, (bus)->num, ##__VA_ARGS__)
> >  #define bcma_warn(bus, fmt, ...) \
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 8e67802..d4fb5ee 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -25,6 +25,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include/* isa_dma_bridge_buggy */
> >  #include "pci.h"
> >  
> > @@ -3282,6 +3284,31 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, 
> > 0x156d,
> >quirk_apple_wait_for_thunderbolt);
> >  #endif
> >  
> > +/*
> > + * Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> > + * on boot until they are reset, causing spurious interrupts if the IRQ is
> > + * shared. Apparently the EFI bootloader enables the device to phone home
> > + * to Cupertino and does not disable it before passing control to the OS.
> > + */
> > +static void quirk_apple_b43_reset(struct pci_dev *dev)
> > +{
> > +   void __iomem *mmio;
> > +
> > +   if (!dmi_match(DMI_BOARD_VENDOR, "Apple Inc.") || !dev->bus->self ||
> > +   pci_pcie_type(dev->bus->self) != PCI_EXP_TYPE_ROOT_PORT)
> > +   return;
> > +
> > +   mmio = pci_iomap(dev, 0, 0);
> > +   if (!mmio) {
> > +   pr_err("b43 quirk: Cannot iomap device, IRQ storm ahead\n");
> > +   return;
> > +   }
> > +   iowrite32(BCMA_RESET_CTL_RESET,
> > + mmio + (1 * BCMA_CORE_SIZE) + BCMA_RESET_CTL);
> > +   pci_iounmap(dev, mmio);  
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=111781 and
> https://mjg59.dreamwidth.org/11235.html describe a sort of similar
> issue, but with DMA.  An interrupt from the device is probably to
> signal a DMA completion, but these problem reports only mention the
> "IRQ nobody cared" issue; I don't see anything about memory
> corruption.
> 
> If this resets the device, I guess that should prevent future DMA as
> well as future interrupts.  Would pci_reset_function() do the same
> thing in a more generic way?
> 
> I'm a little bit hesitant to put a quirk like this in Linux because
> it's only a 90% solution.  If the only problem is the interrupts, it's
> probably OK since a few extra interrupts doesn't hurt anything.  But
> if there is also DMA that might corrupt something, a 90% solution just
> makes it harder to debug for the remaining 10%.

This was already discussed in this thread.

It is not a 90% solution. It fixes the IRQ issue. It is not supposed to
fix the DMA issue. And it can't. It does mitigate it a tiny bit though.

-- 
Michael


pgpTVbWuOsMJq.pgp
Description: OpenPGP digital signature

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Bjorn Helgaas]

[+cc Matthew]

Hi Lukas,

On Tue, Mar 29, 2016 at 08:20:30PM +0200, Lukas Wunner wrote:
> Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> on boot until they are reset, causing spurious interrupts if the IRQ is
> shared. Apparently the EFI bootloader enables the device and does not
> disable it before passing control to the OS. The bootloader contains a
> driver for the wireless card which allows it to phone home to Cupertino.
> This is used for Internet Recovery (download and install OS X images)
> and probably also for Back to My Mac (remote access, RFC 6281) and to
> discover stolen hardware.
> 
> The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
> is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
> reader, HDA card on discrete GPU). As soon as an interrupt handler is
> installed for one of these devices, the ensuing storm of spurious IRQs
> causes the kernel to disable the IRQ and switch to polling. This lasts
> until the b43 driver loads and resets the device.
> 
> Loading the b43 driver first is not always an option, in particular with
> the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
> installed early on because it is built in, unlike b43 which is usually
> a module.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
> Tested-by: Lukas Wunner  [MacBookPro9,1]
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/bcma/bcma_private.h |  2 --
>  drivers/pci/quirks.c| 27 +++
>  include/linux/bcma/bcma.h   |  1 +
>  3 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
> index eda0909..f642c42 100644
> --- a/drivers/bcma/bcma_private.h
> +++ b/drivers/bcma/bcma_private.h
> @@ -8,8 +8,6 @@
>  #include 
>  #include 
>  
> -#define BCMA_CORE_SIZE   0x1000
> -
>  #define bcma_err(bus, fmt, ...) \
>   pr_err("bus%d: " fmt, (bus)->num, ##__VA_ARGS__)
>  #define bcma_warn(bus, fmt, ...) \
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 8e67802..d4fb5ee 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -25,6 +25,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include  /* isa_dma_bridge_buggy */
>  #include "pci.h"
>  
> @@ -3282,6 +3284,31 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, 
> 0x156d,
>  quirk_apple_wait_for_thunderbolt);
>  #endif
>  
> +/*
> + * Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> + * on boot until they are reset, causing spurious interrupts if the IRQ is
> + * shared. Apparently the EFI bootloader enables the device to phone home
> + * to Cupertino and does not disable it before passing control to the OS.
> + */
> +static void quirk_apple_b43_reset(struct pci_dev *dev)
> +{
> + void __iomem *mmio;
> +
> + if (!dmi_match(DMI_BOARD_VENDOR, "Apple Inc.") || !dev->bus->self ||
> + pci_pcie_type(dev->bus->self) != PCI_EXP_TYPE_ROOT_PORT)
> + return;
> +
> + mmio = pci_iomap(dev, 0, 0);
> + if (!mmio) {
> + pr_err("b43 quirk: Cannot iomap device, IRQ storm ahead\n");
> + return;
> + }
> + iowrite32(BCMA_RESET_CTL_RESET,
> +   mmio + (1 * BCMA_CORE_SIZE) + BCMA_RESET_CTL);
> + pci_iounmap(dev, mmio);

https://bugzilla.kernel.org/show_bug.cgi?id=111781 and
https://mjg59.dreamwidth.org/11235.html describe a sort of similar
issue, but with DMA.  An interrupt from the device is probably to
signal a DMA completion, but these problem reports only mention the
"IRQ nobody cared" issue; I don't see anything about memory
corruption.

If this resets the device, I guess that should prevent future DMA as
well as future interrupts.  Would pci_reset_function() do the same
thing in a more generic way?

I'm a little bit hesitant to put a quirk like this in Linux because
it's only a 90% solution.  If the only problem is the interrupts, it's
probably OK since a few extra interrupts doesn't hurt anything.  But
if there is also DMA that might corrupt something, a 90% solution just
makes it harder to debug for the remaining 10%.

> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, 0x4331, 
> quirk_apple_b43_reset);
> +
>  static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
> struct pci_fixup *end)
>  {
> diff --git a/include/linux/bcma/bcma.h b/include/linux/bcma/bcma.h
> index 0367c63..5c37b58 100644
> --- a/include/linux/bcma/bcma.h
> +++ b/include/linux/bcma/bcma.h
> @@ -158,6 +158,7 @@ struct bcma_host_ops {
>  #define BCMA_CORE_DEFAULT0xFFF
>  
>  #define BCMA_MAX_NR_CORES16
> +#define 

RE: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

[David Laight]

From: Amitkumar Karwar
> Sent: 05 April 2016 06:48
...
> Our one time allocated 64k buffer read from firmware contains multiple data 
> chunks. We have a feature
> called single port aggregation in which firmware attaches an aggregated 
> buffer to single port. So
> sometimes a single data chunk can exceed 32k. dev_kfree_skb_any() is called 
> to free those data chunks.

Ah yes, which particular problem does aggregating data into a single buffer 
solve?

David

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH] ath10k: Fix return value for btcoex and peer stats debugfs

[Joe Perches]

On Tue, 2016-04-05 at 20:58 +0530, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Return value is incorrect for btcoex and peer stats debugfs
> 'write' entries if the user provides a value that matches with
> the already available debugfs entry, this results in the debugfs
> entry getting stuck and the operation has to be terminated manually.
> Fix this by returning the appropriate return 'count' as we do it for
> other debugfs entries like pktlog etc

Not your code, but some of the xor uses are odd at best.

> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> b/drivers/net/wireless/ath/ath10k/debug.c
[]
> @@ -2122,7 +2122,7 @@ static ssize_t ath10k_write_btcoex(struct file *file,
>   struct ath10k *ar = file->private_data;
>   char buf[32];
>   size_t buf_size;
> - int ret = 0;
> + int ret;
>   bool val;
>  
>   buf_size = min(count, (sizeof(buf) - 1));
> @@ -2142,8 +2142,10 @@ static ssize_t ath10k_write_btcoex(struct file *file,
>   goto exit;
>   }
>  
> - if (!(test_bit(ATH10K_FLAG_BTCOEX, >dev_flags) ^ val))
> + if (!(test_bit(ATH10K_FLAG_BTCOEX, >dev_flags) ^ val)) {

xor on an int and a bool.

> @@ -2189,7 +2191,7 @@ static ssize_t ath10k_write_peer_stats(struct file 
> *file,
>   struct ath10k *ar = file->private_data;
>   char buf[32];
>   size_t buf_size;
> - int ret = 0;
> + int ret;
>   bool val;
>  
>   buf_size = min(count, (sizeof(buf) - 1));
> @@ -2209,8 +2211,10 @@ static ssize_t ath10k_write_peer_stats(struct file 
> *file,
>   goto exit;
>   }
>  
> - if (!(test_bit(ATH10K_FLAG_PEER_STATS, >dev_flags) ^ val))
> + if (!(test_bit(ATH10K_FLAG_PEER_STATS, >dev_flags) ^ val)) {

here too

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

[PATCH] ath10k: Fix return value for btcoex and peer stats debugfs

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

Return value is incorrect for btcoex and peer stats debugfs
'write' entries if the user provides a value that matches with
the already available debugfs entry, this results in the debugfs
entry getting stuck and the operation has to be terminated manually.
Fix this by returning the appropriate return 'count' as we do it for
other debugfs entries like pktlog etc

Fixes: cc61a1bbbc0e ("ath10k: enable debugfs provision to enable
Peer Stats feature")
Fixes: c28e6f06ff40 ("ath10k: fix sanity check on enabling btcoex via
debugfs")
Signed-off-by: Mohammed Shafi Shajakhan 
---
 drivers/net/wireless/ath/ath10k/debug.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 76bbe17..e7d441c 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2122,7 +2122,7 @@ static ssize_t ath10k_write_btcoex(struct file *file,
struct ath10k *ar = file->private_data;
char buf[32];
size_t buf_size;
-   int ret = 0;
+   int ret;
bool val;
 
buf_size = min(count, (sizeof(buf) - 1));
@@ -2142,8 +2142,10 @@ static ssize_t ath10k_write_btcoex(struct file *file,
goto exit;
}
 
-   if (!(test_bit(ATH10K_FLAG_BTCOEX, >dev_flags) ^ val))
+   if (!(test_bit(ATH10K_FLAG_BTCOEX, >dev_flags) ^ val)) {
+   ret = count;
goto exit;
+   }
 
if (val)
set_bit(ATH10K_FLAG_BTCOEX, >dev_flags);
@@ -2189,7 +2191,7 @@ static ssize_t ath10k_write_peer_stats(struct file *file,
struct ath10k *ar = file->private_data;
char buf[32];
size_t buf_size;
-   int ret = 0;
+   int ret;
bool val;
 
buf_size = min(count, (sizeof(buf) - 1));
@@ -2209,8 +2211,10 @@ static ssize_t ath10k_write_peer_stats(struct file *file,
goto exit;
}
 
-   if (!(test_bit(ATH10K_FLAG_PEER_STATS, >dev_flags) ^ val))
+   if (!(test_bit(ATH10K_FLAG_PEER_STATS, >dev_flags) ^ val)) {
+   ret = count;
goto exit;
+   }
 
if (val)
set_bit(ATH10K_FLAG_PEER_STATS, >dev_flags);
-- 
1.7.9.5

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

Re: [PATCHv2 1/2] mac80211: implement fair queuing per txq

[Dave Taht]

thx for the review!

On Tue, Apr 5, 2016 at 6:57 AM, Johannes Berg  wrote:
> On Thu, 2016-03-31 at 12:28 +0200, Michal Kazior wrote:
>
>> +++ b/net/mac80211/codel.h
>> +++ b/net/mac80211/codel_i.h
>
> Do we really need all this code in .h files? It seems very odd to me to
> have all the algorithm implementation there rather than a C file, you
> should (can?) only include codel.h into a single C file anyway.

The hope had been the original codel.h would have been reusable, which
is not the case at present.

>
>>  struct txq_info {
>> - struct sk_buff_head queue;
>> + struct txq_flow flow;
>> + struct list_head new_flows;
>> + struct list_head old_flows;
>
> This is confusing, can you please document that? Why are there two
> lists of flows, *and* an embedded flow? Is the embedded flow on any of
> the lists?

To explain the new and old flow concepts, there's
https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06 which is in the
ietf editors queue for final publication and doesn't have a final name
yet.

The embedded flow concept is michal's and I'm not convinced it's the
right idea as yet.

>
>> + u32 backlog_bytes;
>> + u32 backlog_packets;
>> + u32 drop_codel;
>
> Would it make some sense to at least conceptually layer this a bit?
> I.e. rather than calling this "drop_codel" call it "drop_congestion" or
> something like that?

Is there a more generic place overall in ieee80211 to record per-sta
backlogs, drops and marks?

>> + skb = codel_dequeue(flow,
>> + >backlog,
>> + 0,
>> + >cvars,
>> + >cparams,
>> + codel_get_time(),
>> + false);
>
> What happened here? :)

Magic.

>
>> + if (!skb) {
>> + if ((head == >new_flows) &&
>> + !list_empty(>old_flows)) {
>> + list_move_tail(>flowchain, >old_flows);
>> + } else {
>> + list_del_init(>flowchain);
>> + flow->txqi = NULL;
>> + }
>> + goto begin;
>> + }
>
> Ouch. Any way you can make that easier to follow?

It made my brain hurt in the original code, too, but it is eric
optimizing out cycles at his finest.

if the the new_flows list is expired or done, switch to the old_flows
list, if the old_flows list is done, go try selecting another queue to
pull from (which may or may not exist). see the pending rfc for a more
elongated version.

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

Re: [PATCHv2 1/2] mac80211: implement fair queuing per txq

[Johannes Berg]

On Thu, 2016-03-31 at 12:28 +0200, Michal Kazior wrote:

> +++ b/net/mac80211/codel.h
> +++ b/net/mac80211/codel_i.h

Do we really need all this code in .h files? It seems very odd to me to
have all the algorithm implementation there rather than a C file, you
should (can?) only include codel.h into a single C file anyway.

>  struct txq_info {
> - struct sk_buff_head queue;
> + struct txq_flow flow;
> + struct list_head new_flows;
> + struct list_head old_flows;

This is confusing, can you please document that? Why are there two
lists of flows, *and* an embedded flow? Is the embedded flow on any of
the lists?

> + u32 backlog_bytes;
> + u32 backlog_packets;
> + u32 drop_codel;

Would it make some sense to at least conceptually layer this a bit?
I.e. rather than calling this "drop_codel" call it "drop_congestion" or
something like that?

> @@ -977,12 +978,9 @@ static void ieee80211_do_stop(struct
> ieee80211_sub_if_data *sdata,
>   if (sdata->vif.txq) {
>   struct txq_info *txqi = to_txq_info(sdata->vif.txq);
>  
> - spin_lock_bh(>queue.lock);
> - ieee80211_purge_tx_queue(>hw, >queue);
> - txqi->byte_cnt = 0;
> - spin_unlock_bh(>queue.lock);
> -
> - atomic_set(>txqs_len[txqi->txq.ac], 0);
> + spin_lock_bh(>lock);
> + ieee80211_purge_txq(local, txqi);
> + spin_unlock_bh(>lock);

This isn't very nice - you're going from locking a single txqi to
having a global hardware lock.

It's probably fine in this particular case, but I'll need to look for
other places :)

> +/**
> + * struct txq_flow - per traffic flow queue
> + *
> + * This structure is used to distinguish and queue different traffic flows
> + * separately for fair queueing/AQM purposes.
> + *
> + * @txqi: txq_info structure it is associated at given time

Do we actually have to keep that? It's on a list per txqi, no?

> + * @flowchain: can be linked to other flows for RR purposes

RR?

> +void ieee80211_teardown_flows(struct ieee80211_local *local)
> +{
> + struct ieee80211_fq *fq = >fq;
> + struct ieee80211_sub_if_data *sdata;
> + struct sta_info *sta;
> + int i;
> +
> + if (!local->ops->wake_tx_queue)
> + return;
> +
> + list_for_each_entry_rcu(sta, >sta_list, list)
> + for (i = 0; i < IEEE80211_NUM_TIDS; i++)
> + ieee80211_purge_txq(local,
> + to_txq_info(sta->sta.txq[i]));
> +
> + list_for_each_entry_rcu(sdata, >interfaces, list)
> + ieee80211_purge_txq(local, to_txq_info(sdata->vif.txq));

Using RCU iteration here seems rather strange, since it's a teardown
flow? That doesn't seem necessary, since it's control path and must be
holding appropriate locks anyway to make sure nothing is added to the
lists.

> + skb = codel_dequeue(flow,
> + >backlog,
> + 0,
> + >cvars,
> + >cparams,
> + codel_get_time(),
> + false);

What happened here? :)

> + if (!skb) {
> + if ((head == >new_flows) &&
> + !list_empty(>old_flows)) {
> + list_move_tail(>flowchain, >old_flows);
> + } else {
> + list_del_init(>flowchain);
> + flow->txqi = NULL;
> + }
> + goto begin;
> + }

Ouch. Any way you can make that easier to follow?

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

Re: [PATCH] mac80211: fix "warning: ‘target_metric’ may be used uninitialized"

[Jeff Mahoney]

On 4/5/16 9:40 AM, Johannes Berg wrote:
> On Tue, 2016-04-05 at 09:33 -0400, Jeff Mahoney wrote:
>> On 4/5/16 5:43 AM, Johannes Berg wrote:
>>>
>>> On Mon, 2016-04-04 at 14:15 -0400, Jeff Mahoney wrote:

 This fixes:

 net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be
 used
 uninitialized in this function

 target_metric is only consumed when reply = true so no bug exists
 here,
 but gcc doesn't notice that.  Initializing to 0 clears the
 warning.

>>> What gcc version are you using? Mine doesn't seem to have a problem
>>> following the logic here.
>> gcc version 4.8.5 (SUSE Linux)
> 
> Ok, mine's significantly newer:
> 
> gcc (Debian 5.3.1-10) 5.3.1 20160224
> 
> I do wonder though if we really should do this? It might hide errors
> later on?

AFAICT, the only way errors would be introduced is if someone added a
new case in which reply was true *and* needed a different target_metric
value (there are 3 cases it's used, 2 of which use 0).  Or if there was
a new case where the target_metric was used and reply wasn't true -- in
which case this code would have been broken anyway.

Also, using uninitalized_var would have a higher probability of hiding
an error later on.  Setting it to 0 seems the safest course.

-Jeff

-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ath10k: remove MSI range support

[Rajkumar Manoharan]

On 2016-04-05 18:21, Valo, Kalle wrote:

Rajkumar Manoharan  writes:


MSI-X is never well-tested, might contain bugs and generally isn't
really all that useful to maintain. Also ath10k is mainly used with
shared/singly-MSI interrupt systems. Hence removing MSI range support.
This change will be useful for further cleanup in copy engine lock
and to add NAPI support.

Signed-off-by: Rajkumar Manoharan 


[...]


@@ -171,14 +168,10 @@ struct ath10k_pci {
void __iomem *mem;
size_t mem_len;

-   /*
-* Number of MSI interrupts granted, 0 --> using legacy PCI line
-* interrupts.
-*/
-   int num_msi_intrs;
+   /* Operating interrupt mode */
+   u8 oper_irq_mode;


Shouldn't this be enum ath10k_pci_irq_mode?


Yes.. Then the enum should be moved to pci.h. will send next version

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

Re: [PATCH] mac80211: fix "warning: ‘target_metric’ may be used uninitialized"

[Johannes Berg]

On Tue, 2016-04-05 at 09:33 -0400, Jeff Mahoney wrote:
> On 4/5/16 5:43 AM, Johannes Berg wrote:
> > 
> > On Mon, 2016-04-04 at 14:15 -0400, Jeff Mahoney wrote:
> > > 
> > > This fixes:
> > > 
> > > net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be
> > > used
> > > uninitialized in this function
> > > 
> > > target_metric is only consumed when reply = true so no bug exists
> > > here,
> > > but gcc doesn't notice that.  Initializing to 0 clears the
> > > warning.
> > > 
> > What gcc version are you using? Mine doesn't seem to have a problem
> > following the logic here.
> gcc version 4.8.5 (SUSE Linux)

Ok, mine's significantly newer:

gcc (Debian 5.3.1-10) 5.3.1 20160224

I do wonder though if we really should do this? It might hide errors
later on?

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

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Rajkumar Manoharan]

On 2016-04-05 18:18, Valo, Kalle wrote:

Rajkumar Manoharan  writes:

Decrement num_mpdus_ready only when rx amsdu is processed 
successfully.

Not doing so, will result in leak and impact stabilty under low memory
cases.

Signed-off-by: Rajkumar Manoharan 
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c

index 96a7417..9696c2e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2412,14 +2412,12 @@ static void 
ath10k_htt_txrx_compl_task(unsigned long ptr)

struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
struct ath10k *ar = htt->ar;
struct htt_tx_done tx_done = {};
-   struct sk_buff_head rx_q;
struct sk_buff_head rx_ind_q;
struct sk_buff_head tx_ind_q;
struct sk_buff *skb;
unsigned long flags;
int num_mpdus;

-   __skb_queue_head_init(_q);
__skb_queue_head_init(_ind_q);
__skb_queue_head_init(_ind_q);


I guess you are removing the unused rx_q just as a cleanup? It's good
practise to mention that in the commit log (or better yet in a separate
patch).


update the commit log and send next version.

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

Re: [PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[Rajkumar Manoharan]

On 2016-04-05 18:10, Valo, Kalle wrote:

Rajkumar Manoharan  writes:


pre-calibration is meant for qca4019 which contains only caldata
whereas calibration file is used by ar9888 and qca99x0 that contains
both board data and caldata. So by definition both pre-cal-file and
cal-file can not coexist. Keeping them in shared memory (union), is
breaking boot sequence of qca99x0. Fix it by storing both binaries
in separate memories. This issue is reported in ipq8064 platform which
includes caldata in flash memory.

Reported-by: Sebastian Gottschall 
Signed-off-by: Rajkumar Manoharan 


I added the fixes line in the pending branch:

Fixes: 3d9195ea19e4 ("ath10k: incorporate qca4019 cal data download 
sequence")


Thanks.

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

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Grumbach, Emmanuel]

On Tue, 2016-04-05 at 16:25 +0300, Gucea Doru wrote:
> On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
>  wrote:
> > > 
> > > Hello,
> > > 
> > > I am trying to capture packets that are exchanged between an AP
> > > and a
> > > smartphone on the 5Ghz frequency. For generating traffic, I
> > > upload UDP
> > > traffic from a laptop PC towards the smartphone using iperf.
> > > 
> > > The problem is that I can see _only_ the control frames like
> > > RTS/CTS, Block
> > > ACK, while the data packets are not captured. I uploaded the
> > > Wireshark
> > > capture files at [1] (located inside the folders whose name
> > > starts with 5Ghz).
> > 
> > Most likely the packets on A band have a VHT preamble and your SKU
> > is 11N only.
> 
> My card, Intel 7260 [1]  supports 802.11 ac. So it should also
> support
> VHT, right? Is there any interface in user-space for checking after
> VHT?

7260 has several flavors. The one you have doesn't support VHT:
> iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 7260

Dual Band means you have support for 5.2GHz, but Wireless N, means no
VHT.

> 
> However, I noticed a "failure" message in dmesg:
> [4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
> [4.030570] iwlwifi :04:00.0: irq 37 for MSI/MSI-X
> [4.030760] iwlwifi :04:00.0: Direct firmware load for
> iwlwifi-7260-10.ucode failed with error -2
> [4.035509] iwlwifi :04:00.0: loaded firmware version
> 25.228.9.0 op_mode iwlmvm
> [4.454772] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> Wireless N 7260, REV=0x144
> [4.454825] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [4.455055] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [   15.049933] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> [   15.050269] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
> 
> Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
> assumption is that the card can't enter into the 802.11 ac mode, it
> just stays into 802.11n.
> 
> doru@doru-N551JK:~$ iwconfig wlan0
> wlan0 IEEE 802.11abgn  ESSID:"5_mptcp"
>   Mode:Managed  Frequency:5.24 GHz  Access Point:
> C4:6E:1F:4B:10:A2
>   Bit Rate=150 Mb/s   Tx-Power=22 dBm
>   Retry short limit:7   RTS thr:off   Fragment thr:off
>   Power Management:on
>   Link Quality=70/70  Signal level=-36 dBm
>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>   Tx excessive retries:0  Invalid misc:22   Missed beacon:0
> 
> 
> [1] http://www.intel.com/content/www/us/en/wireless-products/dual-ban
> d-wireless-ac-7260-bluetooth-brief.html
> 
> > Another option is that the traffic uses LDPC encoding and this
> > device doesn't support it.
> > 
> > 
> > > 
> > > If I use the 2.4 frequency, all the frames are captured. I also
> > > uploaded the
> > > Wireshark packet traces for 2.4Ghz at [1] (located inside the
> > > folders whose
> > > name starts with 2.4 Ghz).
> > > 
> > > Is this a known bug or am I doing something wrong?
> > > 
> > > Additional details:
> > > Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band
> > > Wireless N 7260,
> > > REV=0x144 Firmware version: iwlwifi :04:00.0: loaded firmware
> > > version
> > > 25.228.9.0 op_mode iwlmvm
> > > Traffic encryption: WPA & WPA2 Personal
> > > Setting up the card in wireless mode:
> > > ip link set dev wlan0 down
> > > iw wlan0 set type monitor
> > > ip link set dev wlan0 up
> > > iw wlan0 set freq 5240
> > > 
> > > [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
> > > 
> > > Thank you, 
> > > DoruN�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
> > > ���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH] mac80211: fix "warning: ‘target_metric’ may be used uninitialized"

[Jeff Mahoney]

On 4/5/16 5:43 AM, Johannes Berg wrote:
> On Mon, 2016-04-04 at 14:15 -0400, Jeff Mahoney wrote:
>> This fixes:
>>
>> net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used
>> uninitialized in this function
>>
>> target_metric is only consumed when reply = true so no bug exists
>> here,
>> but gcc doesn't notice that.  Initializing to 0 clears the warning.
>>
> 
> What gcc version are you using? Mine doesn't seem to have a problem
> following the logic here.

gcc version 4.8.5 (SUSE Linux)

-Jeff

-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Gucea Doru]

On Tue, Apr 5, 2016 at 1:00 PM, Grumbach, Emmanuel
 wrote:
>>
>> Hello,
>>
>> I am trying to capture packets that are exchanged between an AP and a
>> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
>> traffic from a laptop PC towards the smartphone using iperf.
>>
>> The problem is that I can see _only_ the control frames like RTS/CTS, Block
>> ACK, while the data packets are not captured. I uploaded the Wireshark
>> capture files at [1] (located inside the folders whose name starts with 
>> 5Ghz).
>
> Most likely the packets on A band have a VHT preamble and your SKU is 11N 
> only.

My card, Intel 7260 [1]  supports 802.11 ac. So it should also support
VHT, right? Is there any interface in user-space for checking after
VHT?

However, I noticed a "failure" message in dmesg:
[4.030428] Intel(R) Wireless WiFi driver for Linux, in-tree:
[4.030570] iwlwifi :04:00.0: irq 37 for MSI/MSI-X
[4.030760] iwlwifi :04:00.0: Direct firmware load for
iwlwifi-7260-10.ucode failed with error -2
[4.035509] iwlwifi :04:00.0: loaded firmware version
25.228.9.0 op_mode iwlmvm
[4.454772] iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless N 7260, REV=0x144
[4.454825] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
[4.455055] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
[   15.049933] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
[   15.050269] iwlwifi :04:00.0: L1 Disabled - LTR Enabled

Also, the maximum bit rate reported by iwconfig is 150 Mb/s, so my
assumption is that the card can't enter into the 802.11 ac mode, it
just stays into 802.11n.

doru@doru-N551JK:~$ iwconfig wlan0
wlan0 IEEE 802.11abgn  ESSID:"5_mptcp"
  Mode:Managed  Frequency:5.24 GHz  Access Point: C4:6E:1F:4B:10:A2
  Bit Rate=150 Mb/s   Tx-Power=22 dBm
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Power Management:on
  Link Quality=70/70  Signal level=-36 dBm
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:22   Missed beacon:0


[1] 
http://www.intel.com/content/www/us/en/wireless-products/dual-band-wireless-ac-7260-bluetooth-brief.html

> Another option is that the traffic uses LDPC encoding and this device doesn't 
> support it.
>
>
>>
>> If I use the 2.4 frequency, all the frames are captured. I also uploaded the
>> Wireshark packet traces for 2.4Ghz at [1] (located inside the folders whose
>> name starts with 2.4 Ghz).
>>
>> Is this a known bug or am I doing something wrong?
>>
>> Additional details:
>> Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 
>> 7260,
>> REV=0x144 Firmware version: iwlwifi :04:00.0: loaded firmware version
>> 25.228.9.0 op_mode iwlmvm
>> Traffic encryption: WPA & WPA2 Personal
>> Setting up the card in wireless mode:
>> ip link set dev wlan0 down
>> iw wlan0 set type monitor
>> ip link set dev wlan0 up
>> iw wlan0 set freq 5240
>>
>> [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
>>
>> Thank you, Doru
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath10k: Fix deadlock when peer cannot be created.

[Valo, Kalle]

Julian Calaby  writes:

> On Thu, Mar 31, 2016 at 10:08 AM,   wrote:
>> From: Ben Greear 
>>
>> We must not attempt to send WMI packets while dholding the data-lock,
>
> s/dholding/holding/ ?

I fixed it in the pending branch.

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

Re: [PATCH] ath10k: remove MSI range support

[Valo, Kalle]

Rajkumar Manoharan  writes:

> MSI-X is never well-tested, might contain bugs and generally isn't
> really all that useful to maintain. Also ath10k is mainly used with
> shared/singly-MSI interrupt systems. Hence removing MSI range support.
> This change will be useful for further cleanup in copy engine lock
> and to add NAPI support.
>
> Signed-off-by: Rajkumar Manoharan 

[...]

> @@ -171,14 +168,10 @@ struct ath10k_pci {
>   void __iomem *mem;
>   size_t mem_len;
>  
> - /*
> -  * Number of MSI interrupts granted, 0 --> using legacy PCI line
> -  * interrupts.
> -  */
> - int num_msi_intrs;
> + /* Operating interrupt mode */
> + u8 oper_irq_mode;

Shouldn't this be enum ath10k_pci_irq_mode?

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

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Valo, Kalle]

Rajkumar Manoharan  writes:

> Decrement num_mpdus_ready only when rx amsdu is processed successfully.
> Not doing so, will result in leak and impact stabilty under low memory
> cases.
>
> Signed-off-by: Rajkumar Manoharan 
> ---
>  drivers/net/wireless/ath/ath10k/htt_rx.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
> b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index 96a7417..9696c2e 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -2412,14 +2412,12 @@ static void ath10k_htt_txrx_compl_task(unsigned long 
> ptr)
>   struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
>   struct ath10k *ar = htt->ar;
>   struct htt_tx_done tx_done = {};
> - struct sk_buff_head rx_q;
>   struct sk_buff_head rx_ind_q;
>   struct sk_buff_head tx_ind_q;
>   struct sk_buff *skb;
>   unsigned long flags;
>   int num_mpdus;
>  
> - __skb_queue_head_init(_q);
>   __skb_queue_head_init(_ind_q);
>   __skb_queue_head_init(_ind_q);

I guess you are removing the unused rx_q just as a cleanup? It's good
practise to mention that in the commit log (or better yet in a separate
patch).

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

Re: [PATCH 3/3] ath10k: fix unconditional num_mpdus_ready subtraction

[Valo, Kalle]

Rajkumar Manoharan  writes:

> On 2016-04-01 00:22, Ben Greear wrote:
>> On 03/30/2016 08:42 AM, Rajkumar Manoharan wrote:
>>> Decrement num_mpdus_ready only when rx amsdu is processed
>>> successfully.
>>> Not doing so, will result in leak and impact stabilty under low memory
>>> cases.
>>
>> Should this patch be rebased on top of the "ath10k: process htt rx
>> indication as batch mode" patch?
>>
> It should be on top of "ath10k: speedup htt rx descriptor processing
> for rx_ind". Instead of sending next version of original series, i
> sent it as follow up.

Should this commit log have a fixes line like this:

Fixes: 59465fe46ef1 ("ath10k: speedup htt rx descriptor processing for tx 
completion")

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

Re: [PATCH 1/3] ath10k: fix calibration init sequence of qca99x0

[Valo, Kalle]

Rajkumar Manoharan  writes:

> pre-calibration is meant for qca4019 which contains only caldata
> whereas calibration file is used by ar9888 and qca99x0 that contains
> both board data and caldata. So by definition both pre-cal-file and
> cal-file can not coexist. Keeping them in shared memory (union), is
> breaking boot sequence of qca99x0. Fix it by storing both binaries
> in separate memories. This issue is reported in ipq8064 platform which
> includes caldata in flash memory.
>
> Reported-by: Sebastian Gottschall 
> Signed-off-by: Rajkumar Manoharan 

I added the fixes line in the pending branch:

Fixes: 3d9195ea19e4 ("ath10k: incorporate qca4019 cal data download sequence")

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

Re: [PATCH v3] cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION

[Mohammed Shafi Shajakhan]

Hi Johannes,

On Tue, Apr 05, 2016 at 12:04:10PM +0200, Johannes Berg wrote:
> Hi,
> 
> The implementation seems fine now, but I think the commit log needs some work.

[shafi] thanks for reviewing.

> 
> > Add support for new netlink attribute 'NL80211_STA_INFO_RX_DURATION'
> 
> I think it'd be worthwhile to describe the attribute a bit more,
> including why you're adding it.

[shafi] will update in v4

> 
> > This flag
> 
> There's no flag.

[shafi] i will replace it with the name 'NL80211_STA_INFO_RX_DURATION'

> 
> >  will be set when drivers can fill rx_duration (aggregate
> > PPDU duration(usecs) for all the frames from a peer) 
> 
> You have the description here, but putting it with the attribute would
> be better.

[shafi] ok

> 
> > via 'drv_sta_statistics' callback
> 
> drv_sta_statistics is a mac80211 detail, that's not relevant at
> cfg80211 level; mentioning that is just confusing. This can well used
> by non-mac80211 drivers.

[shafi] agreed, will remove it.

> 
> > Also make sta_info flags 'filled' as 64 bit to accommodate for new
> > per station stats. 
> 
> That sentence doesn't parse well.
> 
> > Extend 'PUT_SINFO' for supporting rx_duration
> > field and any new per sta information in future
> 
> That sentence I think should just be removed.

[shafi] ok.

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

Re: [PATCH v3 2/2] mac80211: minstrel_ht: set A-MSDU tx limits based on selected max_prob_rate

[Johannes Berg]

Applied both now, I've had to fix a locking issue in the first patch.

I also worded the requirement for drivers more strongly - drivers
really *must* update the max length if they set the flag and don't use
minstrel.

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

Re: [PATCH 2/2] mac80211: add NEED_ALIGNED4_SKBS hw flag

[Johannes Berg]

On Tue, 2016-02-23 at 17:15 +0100, Johannes Berg wrote:

> > > Perhaps we could live with this being done only for the fast-xmit
> > > case?
> > I don't think we should pass padded vs non-padded frames depending
> > on
> > whether fast-xmit was used. The non-fast-xmit codepath could simply
> > do the memmove at the end of the tx handlers though.
> I guess that's fair. Would it be sufficent though?
> 

So it turns out the patch 1/2 actually makes the code *bigger* for some
reason.

Janusz, can you see if the above suggestion would be good enough?

Hopefully high-tpt cases would all run through fast-xmit anyway.

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

[PATCH 2/7] wil6210: support regular scan on P2P_DEVICE interface

[Maya Erez]

From: Lior David 

P2P search can only run on the social channel (channel 2).
When issuing a scan request on the P2P_DEVICE interface,
driver ignored the channels argument and always performed a P2P
search.
Fix this by checking the channels argument, if it is
not specified (meaning full scan) or if a non-social channel
was specified, perform a regular scan and not a P2P search.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 5 +++--
 drivers/net/wireless/ath/wil6210/p2p.c  | 6 ++
 drivers/net/wireless/ath/wil6210/wil6210.h  | 1 +
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 12cae3c..49eb2e2 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -375,8 +375,9 @@ static int wil_cfg80211_scan(struct wiphy *wiphy,
return -EBUSY;
}
 
-   /* scan on P2P_DEVICE is handled as p2p search */
-   if (wdev->iftype == NL80211_IFTYPE_P2P_DEVICE) {
+   /* social scan on P2P_DEVICE is handled as p2p search */
+   if (wdev->iftype == NL80211_IFTYPE_P2P_DEVICE &&
+   wil_p2p_is_social_scan(request)) {
wil->scan_request = request;
wil->radio_wdev = wdev;
rc = wil_p2p_search(wil, request);
diff --git a/drivers/net/wireless/ath/wil6210/p2p.c 
b/drivers/net/wireless/ath/wil6210/p2p.c
index 2c1b895..1c91538 100644
--- a/drivers/net/wireless/ath/wil6210/p2p.c
+++ b/drivers/net/wireless/ath/wil6210/p2p.c
@@ -22,6 +22,12 @@
 #define P2P_SEARCH_DURATION_MS 500
 #define P2P_DEFAULT_BI 100
 
+bool wil_p2p_is_social_scan(struct cfg80211_scan_request *request)
+{
+   return (request->n_channels == 1) &&
+  (request->channels[0]->hw_value == P2P_DMG_SOCIAL_CHANNEL);
+}
+
 void wil_p2p_discovery_timer_fn(ulong x)
 {
struct wil6210_priv *wil = (void *)x;
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index d005370..7fcfd6f 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -781,6 +781,7 @@ void wil_disable_irq(struct wil6210_priv *wil);
 void wil_enable_irq(struct wil6210_priv *wil);
 
 /* P2P */
+bool wil_p2p_is_social_scan(struct cfg80211_scan_request *request);
 void wil_p2p_discovery_timer_fn(ulong x);
 int wil_p2p_search(struct wil6210_priv *wil,
   struct cfg80211_scan_request *request);
-- 
1.8.5.2

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

[PATCH 4/7] wil6210: print debug message when transmitting while disconnected

[Maya Erez]

Network stack can try to transmit data while AP / STA is
disconnected.
Change this print-out to debug level as this should not be
handled as error.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/debug.c   | 17 +
 drivers/net/wireless/ath/wil6210/txrx.c|  2 +-
 drivers/net/wireless/ath/wil6210/wil6210.h |  4 
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/debug.c 
b/drivers/net/wireless/ath/wil6210/debug.c
index 0a30127..e5395fd 100644
--- a/drivers/net/wireless/ath/wil6210/debug.c
+++ b/drivers/net/wireless/ath/wil6210/debug.c
@@ -49,6 +49,23 @@ void __wil_err_ratelimited(struct wil6210_priv *wil, const 
char *fmt, ...)
}
 }
 
+void __wil_dbg_ratelimited(struct wil6210_priv *wil, const char *fmt, ...)
+{
+   if (net_ratelimit()) {
+   struct net_device *ndev = wil_to_ndev(wil);
+   struct va_format vaf = {
+   .fmt = fmt,
+   };
+   va_list args;
+
+   va_start(args, fmt);
+   vaf.va = 
+   netdev_dbg(ndev, "%pV", );
+   trace_wil6210_log_dbg();
+   va_end(args);
+   }
+}
+
 void __wil_info(struct wil6210_priv *wil, const char *fmt, ...)
 {
struct net_device *ndev = wil_to_ndev(wil);
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c 
b/drivers/net/wireless/ath/wil6210/txrx.c
index f260b232..a4e4379 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -1759,7 +1759,7 @@ netdev_tx_t wil_start_xmit(struct sk_buff *skb, struct 
net_device *ndev)
goto drop;
}
if (unlikely(!test_bit(wil_status_fwconnected, wil->status))) {
-   wil_err_ratelimited(wil, "FW not connected\n");
+   wil_dbg_ratelimited(wil, "FW not connected, packet dropped\n");
goto drop;
}
if (unlikely(wil->wdev->iftype == NL80211_IFTYPE_MONITOR)) {
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index 7fcfd6f..84b3fa6 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -640,6 +640,8 @@ __printf(2, 3)
 void __wil_err_ratelimited(struct wil6210_priv *wil, const char *fmt, ...);
 __printf(2, 3)
 void __wil_info(struct wil6210_priv *wil, const char *fmt, ...);
+__printf(2, 3)
+void __wil_dbg_ratelimited(struct wil6210_priv *wil, const char *fmt, ...);
 #define wil_dbg(wil, fmt, arg...) do { \
netdev_dbg(wil_to_ndev(wil), fmt, ##arg); \
wil_dbg_trace(wil, fmt, ##arg); \
@@ -659,6 +661,8 @@ void __wil_info(struct wil6210_priv *wil, const char *fmt, 
...);
 #define wil_info(wil, fmt, arg...) __wil_info(wil, "%s: " fmt, __func__, ##arg)
 #define wil_err_ratelimited(wil, fmt, arg...) \
__wil_err_ratelimited(wil, "%s: " fmt, __func__, ##arg)
+#define wil_dbg_ratelimited(wil, fmt, arg...) \
+   __wil_dbg_ratelimited(wil, "%s: " fmt, __func__, ##arg)
 
 /* target operations */
 /* register read */
-- 
1.8.5.2

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

[PATCH 6/7] wil6210: prevent deep sleep of 60G device in critical paths

[Maya Erez]

In idle times 60G device can enter deep sleep and turn off
its XTAL clock.
Host access triggers the device power-up flow which will hold
the AHB during XTAL stabilization until device switches from
slow-clock to XTAL clock.
This behavior can stall the PCIe bus for some arbitrary period
of time.
In order to prevent this stall, host can vote for High Latency
Access Policy (HALP) before reading from PCIe bus.
This vote will wakeup the device from deep sleep and prevent
deep sleep until unvote is done.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/debugfs.c   | 22 +---
 drivers/net/wireless/ath/wil6210/interrupt.c | 80 ++--
 drivers/net/wireless/ath/wil6210/main.c  | 75 --
 drivers/net/wireless/ath/wil6210/wil6210.h   | 29 +-
 drivers/net/wireless/ath/wil6210/wmi.c   | 20 +--
 5 files changed, 194 insertions(+), 32 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index b338a09..5d8823d 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -171,6 +171,8 @@ static void wil_print_ring(struct seq_file *s, const char 
*prefix,
int rsize;
uint i;
 
+   wil_halp_vote(wil);
+
wil_memcpy_fromio_32(, off, sizeof(r));
wil_mbox_ring_le2cpus();
/*
@@ -236,6 +238,7 @@ static void wil_print_ring(struct seq_file *s, const char 
*prefix,
}
  out:
seq_puts(s, "}\n");
+   wil_halp_unvote(wil);
 }
 
 static int wil_mbox_debugfs_show(struct seq_file *s, void *data)
@@ -500,9 +503,9 @@ static ssize_t wil_read_file_ioblob(struct file *file, char 
__user *user_buf,
size_t count, loff_t *ppos)
 {
enum { max_count = 4096 };
-   struct debugfs_blob_wrapper *blob = file->private_data;
+   struct wil_blob_wrapper *wil_blob = file->private_data;
loff_t pos = *ppos;
-   size_t available = blob->size;
+   size_t available = wil_blob->blob.size;
void *buf;
size_t ret;
 
@@ -521,8 +524,9 @@ static ssize_t wil_read_file_ioblob(struct file *file, char 
__user *user_buf,
if (!buf)
return -ENOMEM;
 
-   wil_memcpy_fromio_32(buf, (const volatile void __iomem *)blob->data +
-pos, count);
+   wil_memcpy_fromio_halp_vote(wil_blob->wil, buf,
+   (const volatile void __iomem *)
+   wil_blob->blob.data + pos, count);
 
ret = copy_to_user(user_buf, buf, count);
kfree(buf);
@@ -545,9 +549,9 @@ static
 struct dentry *wil_debugfs_create_ioblob(const char *name,
 umode_t mode,
 struct dentry *parent,
-struct debugfs_blob_wrapper *blob)
+struct wil_blob_wrapper *wil_blob)
 {
-   return debugfs_create_file(name, mode, parent, blob, _ioblob);
+   return debugfs_create_file(name, mode, parent, wil_blob, _ioblob);
 }
 
 /*---reset---*/
@@ -1445,16 +1449,18 @@ static void wil6210_debugfs_init_blobs(struct 
wil6210_priv *wil,
char name[32];
 
for (i = 0; i < ARRAY_SIZE(fw_mapping); i++) {
-   struct debugfs_blob_wrapper *blob = >blobs[i];
+   struct wil_blob_wrapper *wil_blob = >blobs[i];
+   struct debugfs_blob_wrapper *blob = _blob->blob;
const struct fw_map *map = _mapping[i];
 
if (!map->name)
continue;
 
+   wil_blob->wil = wil;
blob->data = (void * __force)wil->csr + HOSTADDR(map->host);
blob->size = map->to - map->from;
snprintf(name, sizeof(name), "blob_%s", map->name);
-   wil_debugfs_create_ioblob(name, S_IRUGO, dbg, blob);
+   wil_debugfs_create_ioblob(name, S_IRUGO, dbg, wil_blob);
}
 }
 
diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index 22592f3..011e741 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -35,17 +35,19 @@
  *
  */
 
-#define WIL6210_IRQ_DISABLE(0xUL)
+#define WIL6210_IRQ_DISABLE(0xUL)
+#define WIL6210_IRQ_DISABLE_NO_HALP(0xF7FFUL)
 #define WIL6210_IMC_RX (BIT_DMA_EP_RX_ICR_RX_DONE | \
 BIT_DMA_EP_RX_ICR_RX_HTRSH)
 #define WIL6210_IMC_RX_NO_RX_HTRSH (WIL6210_IMC_RX & \
(~(BIT_DMA_EP_RX_ICR_RX_HTRSH)))
 #define WIL6210_IMC_TX (BIT_DMA_EP_TX_ICR_TX_DONE | \
BIT_DMA_EP_TX_ICR_TX_DONE_N(0))
-#define WIL6210_IMC_MISC   (ISR_MISC_FW_READY | \
-

[PATCH 3/7] wil6210: change RX_HTRSH interrupt print level to debug

[Maya Erez]

When using interrupt moderation RX_HTRSH interrupt can occur
frequently during high throughput and should not be considered
as error.
Such print-outs can degrade the performance hence should be printed
in debug print level.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index fe66b2b..6897754 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -228,11 +228,8 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 */
if (likely(isr & (BIT_DMA_EP_RX_ICR_RX_DONE |
  BIT_DMA_EP_RX_ICR_RX_HTRSH))) {
-   wil_dbg_irq(wil, "RX done\n");
-
-   if (unlikely(isr & BIT_DMA_EP_RX_ICR_RX_HTRSH))
-   wil_err_ratelimited(wil,
-   "Received \"Rx buffer is in risk of 
overflow\" interrupt\n");
+   wil_dbg_irq(wil, "RX done / RX_HTRSH received, ISR (0x%x)\n",
+   isr);
 
isr &= ~(BIT_DMA_EP_RX_ICR_RX_DONE |
 BIT_DMA_EP_RX_ICR_RX_HTRSH);
-- 
1.8.5.2

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

[PATCH 1/7] wil6210: add function name to wil log macros

[Maya Erez]

Add __func__ to all wil log macros for easier debugging.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/debug.c   |  6 +++---
 drivers/net/wireless/ath/wil6210/wil6210.h | 25 +
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/debug.c 
b/drivers/net/wireless/ath/wil6210/debug.c
index 3249562..0a30127 100644
--- a/drivers/net/wireless/ath/wil6210/debug.c
+++ b/drivers/net/wireless/ath/wil6210/debug.c
@@ -17,7 +17,7 @@
 #include "wil6210.h"
 #include "trace.h"
 
-void wil_err(struct wil6210_priv *wil, const char *fmt, ...)
+void __wil_err(struct wil6210_priv *wil, const char *fmt, ...)
 {
struct net_device *ndev = wil_to_ndev(wil);
struct va_format vaf = {
@@ -32,7 +32,7 @@ void wil_err(struct wil6210_priv *wil, const char *fmt, ...)
va_end(args);
 }
 
-void wil_err_ratelimited(struct wil6210_priv *wil, const char *fmt, ...)
+void __wil_err_ratelimited(struct wil6210_priv *wil, const char *fmt, ...)
 {
if (net_ratelimit()) {
struct net_device *ndev = wil_to_ndev(wil);
@@ -49,7 +49,7 @@ void wil_err_ratelimited(struct wil6210_priv *wil, const char 
*fmt, ...)
}
 }
 
-void wil_info(struct wil6210_priv *wil, const char *fmt, ...)
+void __wil_info(struct wil6210_priv *wil, const char *fmt, ...)
 {
struct net_device *ndev = wil_to_ndev(wil);
struct va_format vaf = {
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index 4d699ea4..d005370 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -635,21 +635,30 @@ struct wil6210_priv {
 __printf(2, 3)
 void wil_dbg_trace(struct wil6210_priv *wil, const char *fmt, ...);
 __printf(2, 3)
-void wil_err(struct wil6210_priv *wil, const char *fmt, ...);
+void __wil_err(struct wil6210_priv *wil, const char *fmt, ...);
 __printf(2, 3)
-void wil_err_ratelimited(struct wil6210_priv *wil, const char *fmt, ...);
+void __wil_err_ratelimited(struct wil6210_priv *wil, const char *fmt, ...);
 __printf(2, 3)
-void wil_info(struct wil6210_priv *wil, const char *fmt, ...);
+void __wil_info(struct wil6210_priv *wil, const char *fmt, ...);
 #define wil_dbg(wil, fmt, arg...) do { \
netdev_dbg(wil_to_ndev(wil), fmt, ##arg); \
wil_dbg_trace(wil, fmt, ##arg); \
 } while (0)
 
-#define wil_dbg_irq(wil, fmt, arg...) wil_dbg(wil, "DBG[ IRQ]" fmt, ##arg)
-#define wil_dbg_txrx(wil, fmt, arg...) wil_dbg(wil, "DBG[TXRX]" fmt, ##arg)
-#define wil_dbg_wmi(wil, fmt, arg...) wil_dbg(wil, "DBG[ WMI]" fmt, ##arg)
-#define wil_dbg_misc(wil, fmt, arg...) wil_dbg(wil, "DBG[MISC]" fmt, ##arg)
-#define wil_dbg_pm(wil, fmt, arg...) wil_dbg(wil, "DBG[ PM ]" fmt, ##arg)
+#define wil_dbg_irq(wil, fmt, arg...) \
+   wil_dbg(wil, "DBG[ IRQ]%s: " fmt, __func__, ##arg)
+#define wil_dbg_txrx(wil, fmt, arg...) \
+   wil_dbg(wil, "DBG[TXRX]%s: " fmt, __func__, ##arg)
+#define wil_dbg_wmi(wil, fmt, arg...) \
+   wil_dbg(wil, "DBG[ WMI]%s: " fmt, __func__,  ##arg)
+#define wil_dbg_misc(wil, fmt, arg...) \
+   wil_dbg(wil, "DBG[MISC]%s: " fmt, __func__, ##arg)
+#define wil_dbg_pm(wil, fmt, arg...) \
+   wil_dbg(wil, "DBG[ PM ]%s: " fmt, __func__, ##arg)
+#define wil_err(wil, fmt, arg...) __wil_err(wil, "%s: " fmt, __func__, ##arg)
+#define wil_info(wil, fmt, arg...) __wil_info(wil, "%s: " fmt, __func__, ##arg)
+#define wil_err_ratelimited(wil, fmt, arg...) \
+   __wil_err_ratelimited(wil, "%s: " fmt, __func__, ##arg)
 
 /* target operations */
 /* register read */
-- 
1.8.5.2

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

[PATCH 7/7] wil6210: add support for device led configuration

[Maya Erez]

Add the ability to configure the device led to be used for notifying
the AP activity (60G device supports leds 0-2).
The host can also configure the blinking frequency of the led in
three states.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/debugfs.c | 115 +
 drivers/net/wireless/ath/wil6210/main.c|   3 +
 drivers/net/wireless/ath/wil6210/wil6210.h |  25 +++
 drivers/net/wireless/ath/wil6210/wmi.c |  77 +++
 drivers/net/wireless/ath/wil6210/wmi.h |  61 +++
 5 files changed, 281 insertions(+)

diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 5d8823d..a8098b4 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1441,6 +1441,118 @@ static const struct file_operations fops_sta = {
.llseek = seq_lseek,
 };
 
+static ssize_t wil_read_file_led_cfg(struct file *file, char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   char buf[80];
+   int n;
+
+   n = snprintf(buf, sizeof(buf),
+"led_id is set to %d, echo 1 to enable, 0 to disable\n",
+led_id);
+
+   n = min_t(int, n, sizeof(buf));
+
+   return simple_read_from_buffer(user_buf, count, ppos,
+  buf, n);
+}
+
+static ssize_t wil_write_file_led_cfg(struct file *file,
+ const char __user *buf_,
+ size_t count, loff_t *ppos)
+{
+   struct wil6210_priv *wil = file->private_data;
+   int val;
+   int rc;
+
+   rc = kstrtoint_from_user(buf_, count, 0, );
+   if (rc) {
+   wil_err(wil, "Invalid argument\n");
+   return rc;
+   }
+
+   wil_info(wil, "%s led %d\n", val ? "Enabling" : "Disabling", led_id);
+   rc = wmi_led_cfg(wil, val);
+   if (rc) {
+   wil_info(wil, "%s led %d failed\n",
+val ? "Enabling" : "Disabling", led_id);
+   return rc;
+   }
+
+   return count;
+}
+
+static const struct file_operations fops_led_cfg = {
+   .read = wil_read_file_led_cfg,
+   .write = wil_write_file_led_cfg,
+   .open  = simple_open,
+};
+
+/* led_blink_time, write:
+ * "
 
+ */
+static ssize_t wil_write_led_blink_time(struct file *file,
+   const char __user *buf,
+   size_t len, loff_t *ppos)
+{
+   int rc;
+   char *kbuf = kmalloc(len + 1, GFP_KERNEL);
+
+   if (!kbuf)
+   return -ENOMEM;
+
+   rc = simple_write_to_buffer(kbuf, len, ppos, buf, len);
+   if (rc != len) {
+   kfree(kbuf);
+   return rc >= 0 ? -EIO : rc;
+   }
+
+   kbuf[len] = '\0';
+   rc = sscanf(kbuf, "%d %d %d %d %d %d",
+   _blink_time[WIL_LED_TIME_SLOW].on_ms,
+   _blink_time[WIL_LED_TIME_SLOW].off_ms,
+   _blink_time[WIL_LED_TIME_MED].on_ms,
+   _blink_time[WIL_LED_TIME_MED].off_ms,
+   _blink_time[WIL_LED_TIME_FAST].on_ms,
+   _blink_time[WIL_LED_TIME_FAST].off_ms);
+   kfree(kbuf);
+
+   if (rc < 0)
+   return rc;
+   if (rc < 6)
+   return -EINVAL;
+
+   return len;
+}
+
+static ssize_t wil_read_led_blink_time(struct file *file, char __user 
*user_buf,
+  size_t count, loff_t *ppos)
+{
+   static char text[400];
+
+   snprintf(text, sizeof(text),
+"To set led blink on/off time variables write:\n"
+"   "
+"  \n"
+"The current values are:\n"
+"%d %d %d %d %d %d\n",
+led_blink_time[WIL_LED_TIME_SLOW].on_ms,
+led_blink_time[WIL_LED_TIME_SLOW].off_ms,
+led_blink_time[WIL_LED_TIME_MED].on_ms,
+led_blink_time[WIL_LED_TIME_MED].off_ms,
+led_blink_time[WIL_LED_TIME_FAST].on_ms,
+led_blink_time[WIL_LED_TIME_FAST].off_ms);
+
+   return simple_read_from_buffer(user_buf, count, ppos, text,
+  sizeof(text));
+}
+
+static const struct file_operations fops_led_blink_time = {
+   .read = wil_read_led_blink_time,
+   .write = wil_write_led_blink_time,
+   .open  = simple_open,
+};
+
 /**/
 static void wil6210_debugfs_init_blobs(struct wil6210_priv *wil,
   struct dentry *dbg)
@@ -1489,6 +1601,8 @@ static const struct {
{"link",S_IRUGO,_link},
{"info",S_IRUGO,_info},
{"recovery",S_IRUGO | S_IWUSR,  _recovery},
+   {"led_cfg", S_IRUGO | S_IWUSR,  _led_cfg},
+ 

[PATCH 5/7] wil6210: unmask RX_HTRSH interrupt only when connected

[Maya Erez]

RX_HTRSH interrupt sometimes triggered during device reset
procedure.
To prevent handling this interrupt when not required, unmask
this interrupt only if we are connected and mask it when
disconnected.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/interrupt.c |  6 +-
 drivers/net/wireless/ath/wil6210/main.c  | 17 +
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index 6897754..22592f3 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -38,6 +38,8 @@
 #define WIL6210_IRQ_DISABLE(0xUL)
 #define WIL6210_IMC_RX (BIT_DMA_EP_RX_ICR_RX_DONE | \
 BIT_DMA_EP_RX_ICR_RX_HTRSH)
+#define WIL6210_IMC_RX_NO_RX_HTRSH (WIL6210_IMC_RX & \
+   (~(BIT_DMA_EP_RX_ICR_RX_HTRSH)))
 #define WIL6210_IMC_TX (BIT_DMA_EP_TX_ICR_TX_DONE | \
BIT_DMA_EP_TX_ICR_TX_DONE_N(0))
 #define WIL6210_IMC_MISC   (ISR_MISC_FW_READY | \
@@ -109,8 +111,10 @@ void wil6210_unmask_irq_tx(struct wil6210_priv *wil)
 
 void wil6210_unmask_irq_rx(struct wil6210_priv *wil)
 {
+   bool unmask_rx_htrsh = test_bit(wil_status_fwconnected, wil->status);
+
wil_w(wil, RGF_DMA_EP_RX_ICR + offsetof(struct RGF_ICR, IMC),
- WIL6210_IMC_RX);
+ unmask_rx_htrsh ? WIL6210_IMC_RX : WIL6210_IMC_RX_NO_RX_HTRSH);
 }
 
 static void wil6210_unmask_irq_misc(struct wil6210_priv *wil)
diff --git a/drivers/net/wireless/ath/wil6210/main.c 
b/drivers/net/wireless/ath/wil6210/main.c
index 8d4e884..261bdab 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -194,6 +194,18 @@ __acquires(>tid_rx_lock) __releases(>tid_rx_lock)
memset(>stats, 0, sizeof(sta->stats));
 }
 
+static bool wil_ap_is_connected(struct wil6210_priv *wil)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(wil->sta); i++) {
+   if (wil->sta[i].status == wil_sta_connected)
+   return true;
+   }
+
+   return false;
+}
+
 static void _wil6210_disconnect(struct wil6210_priv *wil, const u8 *bssid,
u16 reason_code, bool from_event)
 {
@@ -247,6 +259,11 @@ static void _wil6210_disconnect(struct wil6210_priv *wil, 
const u8 *bssid,
}
clear_bit(wil_status_fwconnecting, wil->status);
break;
+   case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_P2P_GO:
+   if (!wil_ap_is_connected(wil))
+   clear_bit(wil_status_fwconnected, wil->status);
+   break;
default:
break;
}
-- 
1.8.5.2

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

[PATCH 0/7] wil6210 patches

[Maya Erez]

Various of wil6210 fixes

Lior David (1):
  wil6210: support regular scan on P2P_DEVICE interface

Maya Erez (6):
  wil6210: add function name to wil log macros
  wil6210: change RX_HTRSH interrupt print level to debug
  wil6210: print debug message when transmitting while disconnected
  wil6210: unmask RX_HTRSH interrupt only when connected
  wil6210: prevent deep sleep of 60G device in critical paths
  wil6210: add support for device led configuration

 drivers/net/wireless/ath/wil6210/cfg80211.c  |   5 +-
 drivers/net/wireless/ath/wil6210/debug.c |  23 -
 drivers/net/wireless/ath/wil6210/debugfs.c   | 137 +--
 drivers/net/wireless/ath/wil6210/interrupt.c |  93 ++
 drivers/net/wireless/ath/wil6210/main.c  |  95 ++-
 drivers/net/wireless/ath/wil6210/p2p.c   |   6 ++
 drivers/net/wireless/ath/wil6210/txrx.c  |   2 +-
 drivers/net/wireless/ath/wil6210/wil6210.h   |  84 ++--
 drivers/net/wireless/ath/wil6210/wmi.c   |  97 ++-
 drivers/net/wireless/ath/wil6210/wmi.h   |  61 
 10 files changed, 551 insertions(+), 52 deletions(-)

-- 
1.8.5.2

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

[PATCH v2] mac80211: add an option to not disconnect on beacon loss

[Emmanuel Grumbach]

From: Avraham Stern 

Add the option to set mac80211 to not disconnect on beacon loss.
If this option is set, mac80211 will send a beacon loss event
to userspace but will not disconnect.
The beacon loss event is sent only once as long as no response
is received from the AP. If after receiving response from the AP the
beacon loss threshold is hit again, another beacon loss event will
be sent.
The default behavior remains as it was: probe the AP and disconnect
if the AP does not respond.

Signed-off-by: Avraham Stern 
Signed-off-by: Emmanuel Grumbach 
---
v2: fix the race
---
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/main.c|  2 ++
 net/mac80211/mlme.c| 15 ++-
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index ff8d08b..ea4fef3 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -356,6 +356,8 @@ enum ieee80211_sta_flags {
IEEE80211_STA_DISABLE_160MHZ= BIT(13),
IEEE80211_STA_DISABLE_WMM   = BIT(14),
IEEE80211_STA_ENABLE_RRM= BIT(15),
+   IEEE80211_STA_BEACON_LOSS_DO_NOT_DISCONNECT = BIT(16),
+   IEEE80211_STA_BEACON_LOSS_REPORTED  = BIT(17),
 };
 
 struct ieee80211_mgd_auth_data {
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 33c80de..6083256 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -554,6 +554,8 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t 
priv_data_len,
wiphy->features |= NL80211_FEATURE_LOW_PRIORITY_SCAN |
   NL80211_FEATURE_AP_SCAN;
 
+   wiphy_ext_feature_set(wiphy,
+ 
NL80211_EXT_FEATURE_BEACON_LOSS_DO_NOT_DISCONNECT);
 
if (!ops->set_key)
wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index d3c75ac..1c9823e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -128,6 +128,8 @@ void ieee80211_sta_reset_conn_monitor(struct 
ieee80211_sub_if_data *sdata)
if (ifmgd->probe_send_count)
ifmgd->probe_send_count = 0;
 
+   sdata->u.mgd.flags &= ~IEEE80211_STA_BEACON_LOSS_REPORTED;
+
if (ieee80211_hw_check(>local->hw, CONNECTION_MONITOR))
return;
 
@@ -1927,6 +1929,7 @@ static void ieee80211_set_associated(struct 
ieee80211_sub_if_data *sdata,
 
/* just to be sure */
ieee80211_stop_poll(sdata);
+   sdata->u.mgd.flags &= ~IEEE80211_STA_BEACON_LOSS_REPORTED;
 
ieee80211_led_assoc(local, 1);
 
@@ -1985,6 +1988,7 @@ static void ieee80211_set_disassoc(struct 
ieee80211_sub_if_data *sdata,
return;
 
ieee80211_stop_poll(sdata);
+   ifmgd->flags &= ~IEEE80211_STA_BEACON_LOSS_REPORTED;
 
ifmgd->associated = NULL;
netif_carrier_off(sdata->dev);
@@ -2432,8 +2436,12 @@ static void ieee80211_beacon_connection_loss_work(struct 
work_struct *work)
sdata_info(sdata, "Connection to AP %pM lost\n",
   ifmgd->bssid);
__ieee80211_disconnect(sdata);
-   } else {
+   } else if (!(ifmgd->flags & 
IEEE80211_STA_BEACON_LOSS_DO_NOT_DISCONNECT)) {
ieee80211_mgd_probe_ap(sdata, true);
+   } else if (!(ifmgd->flags & IEEE80211_STA_BEACON_LOSS_REPORTED)) {
+   ieee80211_cqm_beacon_loss_notify(>vif,
+GFP_KERNEL);
+   ifmgd->flags |= IEEE80211_STA_BEACON_LOSS_REPORTED;
}
 }
 
@@ -4752,6 +4760,11 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data 
*sdata,
sdata->encrypt_headroom = ieee80211_cs_headroom(local, >crypto,
sdata->vif.type);
 
+   if (req->flags & ASSOC_REQ_BEACON_LOSS_DO_NOT_DISCONNECT)
+   ifmgd->flags |= IEEE80211_STA_BEACON_LOSS_DO_NOT_DISCONNECT;
+   else
+   ifmgd->flags &= ~IEEE80211_STA_BEACON_LOSS_DO_NOT_DISCONNECT;
+
/* kick off associate process */
 
ifmgd->assoc_data = assoc_data;
-- 
2.5.0

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

Re: [PATCH 1/2] mac80211: mesh: fix cleanup for mesh pathtable

[Johannes Berg]

Also applied both of these.

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

Re: [PATCH 0/5] mesh struct cleanups

[Johannes Berg]

On Fri, 2016-03-18 at 22:11 -0400, Bob Copeland wrote:
> This series makes a few minor mesh cleanups after the rhashtable
> rework -- mostly some reductions in padding and allocation waste.
> 

Also applied.

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

Re: [PATCH v2] mac80211: mesh: fix crash in mesh_path_timer

[Johannes Berg]

On Fri, 2016-03-18 at 22:03 -0400, Bob Copeland wrote:
> The mesh_path_reclaim() function, called from an rcu callback,
> cancels
> the mesh_path_timer associated with a mesh path.  Unfortunately, this
> call can happen much later, perhaps after the hash table itself is
> destroyed.
> 
[...]

applied.

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

Re: [PATCH 1/5] nl80211: add an option to set driver action for beacon loss

[Johannes Berg]

I've applied 1,3-5 of this series.

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

Re: [PATCH 4/4] mac80211: fix cipher scheme function name

[Johannes Berg]

On Thu, 2016-03-17 at 15:02 +0200, Emmanuel Grumbach wrote:
> From: Johannes Berg 
> 
> The code is only used with iwlwifi, but still should have proper
> mac80211 naming scheme; fix that.
> 
All 4 applied.

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

[PATCH] ath10k: remove VHT capabilities from 2.4GHz

[Johannes Berg]

From: Johannes Berg 

According to the spec, VHT doesn't exist in 2.4GHz.

There are vendor extensions to allow a subset of VHT to work
(notably 256-QAM), but since mac80211 doesn't support those
advertising VHT capability on 2.4GHz leads to the behaviour
of reporting VHT capabilities but not being able to use any
of them due to mac80211's code requiring 80 MHz support.

Remove the VHT capabilities from 2.4GHz for now. If mac80211
gets extended to use the (likely Broadcom) vendor IEs for it
and handles the lack of 80 MHz support, it can be added back.

Signed-off-by: Johannes Berg 
---
 drivers/net/wireless/ath/ath10k/mac.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 78999c9de23b..b9d654ed0f80 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3921,9 +3921,6 @@ static void ath10k_mac_setup_ht_vht_cap(struct ath10k *ar)
if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY) {
band = >mac.sbands[IEEE80211_BAND_2GHZ];
band->ht_cap = ht_cap;
-
-   /* Enable the VHT support at 2.4 GHz */
-   band->vht_cap = vht_cap;
}
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
band = >mac.sbands[IEEE80211_BAND_5GHZ];
-- 
2.7.0

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

Re: [PATCH v3] cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION

[Johannes Berg]

Hi,

The implementation seems fine now, but I think the commit log needs some work.

> Add support for new netlink attribute 'NL80211_STA_INFO_RX_DURATION'

I think it'd be worthwhile to describe the attribute a bit more,
including why you're adding it.

> This flag

There's no flag.

>  will be set when drivers can fill rx_duration (aggregate
> PPDU duration(usecs) for all the frames from a peer) 

You have the description here, but putting it with the attribute would
be better.

> via 'drv_sta_statistics' callback

drv_sta_statistics is a mac80211 detail, that's not relevant at
cfg80211 level; mentioning that is just confusing. This can well used
by non-mac80211 drivers.

> Also make sta_info flags 'filled' as 64 bit to accommodate for new
> per station stats. 

That sentence doesn't parse well.

> Extend 'PUT_SINFO' for supporting rx_duration
> field and any new per sta information in future

That sentence I think should just be removed.

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

RE: iwlwifi monitor mode: No data frame captured on 5 Ghz

[Grumbach, Emmanuel]

> 
> Hello,
> 
> I am trying to capture packets that are exchanged between an AP and a
> smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
> traffic from a laptop PC towards the smartphone using iperf.
> 
> The problem is that I can see _only_ the control frames like RTS/CTS, Block
> ACK, while the data packets are not captured. I uploaded the Wireshark
> capture files at [1] (located inside the folders whose name starts with 5Ghz).

Most likely the packets on A band have a VHT preamble and your SKU is 11N only.
Another option is that the traffic uses LDPC encoding and this device doesn't 
support it.


> 
> If I use the 2.4 frequency, all the frames are captured. I also uploaded the
> Wireshark packet traces for 2.4Ghz at [1] (located inside the folders whose
> name starts with 2.4 Ghz).
> 
> Is this a known bug or am I doing something wrong?
> 
> Additional details:
> Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless N 
> 7260,
> REV=0x144 Firmware version: iwlwifi :04:00.0: loaded firmware version
> 25.228.9.0 op_mode iwlmvm
> Traffic encryption: WPA & WPA2 Personal
> Setting up the card in wireless mode:
> ip link set dev wlan0 down
> iw wlan0 set type monitor
> ip link set dev wlan0 up
> iw wlan0 set freq 5240
> 
> [1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE
> 
> Thank you, Doru

Re: [PATCH] mac80211: Remove unused variable in per STA debugfs struct

[Johannes Berg]

On Sat, 2016-03-19 at 19:59 +0530, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Remove unused variable in per STA debugfs structure, 'commit
> 34e895075e21
> ("mac80211: allow station add/remove to sleep")' removed the only
> user of
> 'add_has_run'.
> 
Applied.

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

iwlwifi monitor mode: No data frame captured on 5 Ghz

[Gucea Doru]

Hello,

I am trying to capture packets that are exchanged between an AP and a
smartphone on the 5Ghz frequency. For generating traffic, I upload UDP
traffic from a laptop PC towards the smartphone using iperf.

The problem is that I can see _only_ the control frames like RTS/CTS,
Block ACK, while the data packets are not captured. I uploaded the
Wireshark capture files at [1] (located inside the folders whose name
starts with 5Ghz).

If I use the 2.4 frequency, all the frames are captured. I also
uploaded the Wireshark packet traces for 2.4Ghz at [1] (located inside
the folders whose name starts with 2.4 Ghz).

Is this a known bug or am I doing something wrong?

Additional details:
Wi-Fi card:  iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless N 7260, REV=0x144
Firmware version: iwlwifi :04:00.0: loaded firmware version
25.228.9.0 op_mode iwlmvm
Traffic encryption: WPA & WPA2 Personal
Setting up the card in wireless mode:
ip link set dev wlan0 down
iw wlan0 set type monitor
ip link set dev wlan0 up
iw wlan0 set freq 5240

[1] https://drive.google.com/open?id=0B5SBH08PU_Chek9rOHY0VkxFRUE

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

NETLINK_URELEASE non-bound socket problem (was: [PATCH] Fix local DoS in cfg80211 subsystem)

[Johannes Berg]

Hi Dmitrijs,

Thanks for reporting this problem.

> The patch below corrects this problem in kernel space. 

I don't think that this is correct, there are four more users of
NETLINK_URELEASE (nfnetlink, NFC), and afaict all of them have the same
bug as nl80211.

Rather than fix all of them, I think we should simply not report
NETLINK_URELEASE for netlink sockets that weren't bound; if any user
comes up that requires them later we could add a new event instead.

I can't find what commit introduced this code, it goes back before git
history, so I don't have the commit log. Maybe it was done for
nfnetlink log/queue? Certainly both nl80211 and NFC are much newer.

> Also, it is
> recommended to ensure that user-space applications are not using
> user-supplied port_id for netlink sockets (which is default in
> libnl-tiny for example).

This I think we should remove from the commit log - it's misleading and
there's no point.

johannes

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

Re: [PATCH 2/2] mac80211: enable starting BA session with custom timeout

[Johannes Berg]

Both applied.

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

Re: [PATCH] mac80211: Set global RRM capability

[Johannes Berg]

On Wed, 2016-03-09 at 10:08 +0200, Emmanuel Grumbach wrote:
> Allow publishing RRM capabilities for features that are not
> HW dependent.
> 
Applied.

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

Re: [PATCH] mac80211: fix "warning: ‘target_metric’ may be used uninitialized"

[Johannes Berg]

On Mon, 2016-04-04 at 14:15 -0400, Jeff Mahoney wrote:
> This fixes:
> 
> net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used
> uninitialized in this function
> 
> target_metric is only consumed when reply = true so no bug exists
> here,
> but gcc doesn't notice that.  Initializing to 0 clears the warning.
> 

What gcc version are you using? Mine doesn't seem to have a problem
following the logic here.

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

Re: [PATCH] mac80211: minstrel_ht: improve sample rate skip logic

[Johannes Berg]

On Thu, 2016-03-03 at 23:25 +0100, Felix Fietkau wrote:
> There were a few issues that were slowing down the process of finding
> the optimal rate, especially on devices with multi-rate retry
> limitations:
> 
[...]

applied.

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

Re: [PATCH 2/2] mac80211: close the SP when we enqueue frames during the SP

[Johannes Berg]

On Thu, 2016-03-17 at 16:51 +0200, Emmanuel Grumbach wrote:
> Since we enqueued the frame that was supposed to be sent
> during the SP, and that frame may very well cary the
> IEEE80211_TX_STATUS_EOSP bit, we may never close the SP
> (WLAN_STA_SP will never be cleared). If that happens, we
> will not open any new SP and will never respond to any poll
> frame from the client.
> Clear WLAN_STA_SP manually if a frame that was polled during
> the SP is queued because of a starting A-MPDU session. The
> client may not see the EOSP bit, but it will at least be
> able to poll new frames in another SP.
> 
Also applied.

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

[PATCH v2] mac80211: close the SP when we enqueue frames during the SP

[Emmanuel Grumbach]

Since we enqueued the frame that was supposed to be sent
during the SP, and that frame may very well cary the
IEEE80211_TX_STATUS_EOSP bit, we may never close the SP
(WLAN_STA_SP will never be cleared). If that happens, we
will not open any new SP and will never respond to any poll
frame from the client.
Clear WLAN_STA_SP manually if a frame that was polled during
the SP is queued because of a starting A-MPDU session. The
client may not see the EOSP bit, but it will at least be
able to poll new frames in another SP.

Reported-by: Alesya Shapira 
Signed-off-by: Emmanuel Grumbach 
---
v2: remove TODO comment
---
 net/mac80211/tx.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 597c8fe..9fbc1b6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1116,6 +1116,12 @@ static bool ieee80211_tx_prep_agg(struct 
ieee80211_tx_data *tx,
reset_agg_timer = true;
} else {
queued = true;
+   if (info->flags & IEEE80211_TX_CTL_NO_PS_BUFFER) {
+   clear_sta_flag(tx->sta, WLAN_STA_SP);
+   ps_dbg(tx->sta->sdata,
+  "STA %pM aid %d: SP frame queued, close 
the SP w/o telling the peer\n",
+  tx->sta->sta.addr, tx->sta->sta.aid);
+   }
info->control.vif = >sdata->vif;
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->flags &= ~IEEE80211_TX_TEMPORARY_FLAGS |
-- 
2.5.0

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

Re: [PATCH] mac80211: Fix BW upgrade for TDLS peers

[Johannes Berg]

On Tue, 2016-03-08 at 13:35 +0200, Emmanuel Grumbach wrote:
> From: Ilan Peer 
> 
> It is possible that the station is connected to an AP
> with bandwidth of 80+80MHz or 160MHz. In such cases
> there is no need to perform an upgrade as the maximal
> supported bandwidth is 80MHz.
> 
> In addition, when upgrading and setting center_freq1
> and bandwidth to 80MHz also set center_freq2 to 0.
> 
Applied.

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

Re: [PATCH 1/2] mac80211: don't send deferred frames outside the SP

[Johannes Berg]

On Thu, 2016-03-17 at 16:51 +0200, Emmanuel Grumbach wrote:
> Frames that are sent between
> ampdu_action(IEEE80211_AMPDU_TX_START) and the move to the
> HT_AGG_STATE_OPERATIONAL state are buffered.
> If we try to start an A-MPDU session while the peer is
> sleeping and polling frames with U-APSD, we may have frames
> that will be buffered by ieee80211_tx_prep_agg. These frames
> have IEEE80211_TX_CTL_NO_PS_BUFFER set since they are sent to
> a sleeping client and possibly IEEE80211_TX_STATUS_EOSP.
> If the frame is buffered, we need clear these two flags
> since they will be re-sent after the move to
> HT_AGG_STATE_OPERATIONAL state which is very likely to
> happen after the SP ends.
> 
Applied.

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

Re: [PATCH] mac80211: remove description of dropped member

[Johannes Berg]

On Fri, 2016-03-18 at 19:23 +, Luis de Bethencourt wrote:
> Commit 976bd9efdae6 ("mac80211: move beacon_loss_count into ifmgd")
> removed the member from the sta_info struct but the description
> stayed
> lingering. Remove it.
> 
Also applied.

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

Re: [PATCH] mac80211: add doc for RX_FLAG_DUP_VALIDATED flag

[Johannes Berg]

On Fri, 2016-03-18 at 16:09 +, Luis de Bethencourt wrote:
> Add documentation for the flag for duplication check.
> 
> Fixes the following warning when running make htmldocs:
> warning: Enum value 'RX_FLAG_DUP_VALIDATED' not described in enum
> 'mac80211_rx_flags'
> 
Applied, thanks.

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

Re: [PATCH] mac80211: Ensure no limits on station rhashtable.

[Johannes Berg]

On Fri, 2016-04-01 at 14:13 -0700, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> By default, the rhashtable logic will fail to insert
> objects if the key-chains are too long and un-balanced.
> 
> In the degenerate case where mac80211 is creating many
> station vdevs connected to the same peer, this case can
> be hit.
> 
> So, set insecure_elasticity to true to allow chains to grow
> as long as needed.
> 
Applied.

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

[PATCH RESEND 5/7] mwifiex: schedule main workqueue for transmitting bridge packets

[Amitkumar Karwar]

From: Xinming Hu 

Bridge packets are enqueued to wmm tx queue, but will not be sent
until main workqeue is scheduled for new interrupt or other
reason. This adds unnecessary delay during traffic.

We will schedule main workqueue when bridge packet is queued.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c 
b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
index 193a809..305589e 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
@@ -216,6 +216,8 @@ static void mwifiex_uap_queue_bridged_pkt(struct 
mwifiex_private *priv,
atomic_inc(>tx_pending);
atomic_inc(>pending_bridged_pkts);
 
+   mwifiex_queue_main_work(priv->adapter);
+
return;
 }
 
-- 
1.8.1.4

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

[PATCH RESEND 3/7] mwifiex: check revision id while choosing PCIe firmware

[Amitkumar Karwar]

From: Shengzhen Li 

Some of the chipsets have two revisions. This patch
selects appropriate firmware by checking revision id.

Signed-off-by: Shengzhen Li 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 56 ++---
 drivers/net/wireless/marvell/mwifiex/pcie.h | 16 +
 2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index de36438..6a06ca5 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -190,7 +190,6 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
 
if (ent->driver_data) {
struct mwifiex_pcie_device *data = (void *)ent->driver_data;
-   card->pcie.firmware = data->firmware;
card->pcie.reg = data->reg;
card->pcie.blksz_fw_dl = data->blksz_fw_dl;
card->pcie.tx_buf_size = data->tx_buf_size;
@@ -269,6 +268,11 @@ static const struct pci_device_id mwifiex_ids[] = {
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
.driver_data = (unsigned long)_pcie8997,
},
+   {
+   PCIE_VENDOR_ID_V2_MARVELL, PCIE_DEVICE_ID_MARVELL_88W8997,
+   PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   .driver_data = (unsigned long)_pcie8997,
+   },
{},
 };
 
@@ -2759,6 +2763,51 @@ static int mwifiex_pcie_request_irq(struct 
mwifiex_adapter *adapter)
 }
 
 /*
+ * This function get firmare name for downloading by revision id
+ *
+ * Read revision id register to get revision id
+ */
+static void mwifiex_pcie_get_fw_name(struct mwifiex_adapter *adapter)
+{
+   int revision_id = 0;
+   struct pcie_service_card *card = adapter->card;
+
+   switch (card->dev->device) {
+   case PCIE_DEVICE_ID_MARVELL_88W8766P:
+   strcpy(adapter->fw_name, PCIE8766_DEFAULT_FW_NAME);
+   break;
+   case PCIE_DEVICE_ID_MARVELL_88W8897:
+   mwifiex_write_reg(adapter, 0x0c58, 0x80c0);
+   mwifiex_read_reg(adapter, 0x0c58, _id);
+   revision_id &= 0xff00;
+   switch (revision_id) {
+   case PCIE8897_A0:
+   strcpy(adapter->fw_name, PCIE8897_A0_FW_NAME);
+   break;
+   case PCIE8897_B0:
+   strcpy(adapter->fw_name, PCIE8897_B0_FW_NAME);
+   break;
+   default:
+   break;
+   }
+   case PCIE_DEVICE_ID_MARVELL_88W8997:
+   mwifiex_read_reg(adapter, 0x0c48, _id);
+   switch (revision_id) {
+   case PCIE8997_V2:
+   strcpy(adapter->fw_name, PCIE8997_FW_NAME_V2);
+   break;
+   case PCIE8997_Z:
+   strcpy(adapter->fw_name, PCIE8997_FW_NAME_Z);
+   break;
+   default:
+   break;
+   }
+   default:
+   break;
+   }
+}
+
+/*
  * This function registers the PCIE device.
  *
  * PCIE IRQ is claimed, block size is set and driver data is initialized.
@@ -2778,8 +2827,8 @@ static int mwifiex_register_dev(struct mwifiex_adapter 
*adapter)
adapter->tx_buf_size = card->pcie.tx_buf_size;
adapter->mem_type_mapping_tbl = card->pcie.mem_type_mapping_tbl;
adapter->num_mem_types = card->pcie.num_mem_types;
-   strcpy(adapter->fw_name, card->pcie.firmware);
adapter->ext_scan = card->pcie.can_ext_scan;
+   mwifiex_pcie_get_fw_name(adapter);
 
return 0;
 }
@@ -2907,6 +2956,3 @@ MODULE_AUTHOR("Marvell International Ltd.");
 MODULE_DESCRIPTION("Marvell WiFi-Ex PCI-Express Driver version " PCIE_VERSION);
 MODULE_VERSION(PCIE_VERSION);
 MODULE_LICENSE("GPL v2");
-MODULE_FIRMWARE(PCIE8766_DEFAULT_FW_NAME);
-MODULE_FIRMWARE(PCIE8897_DEFAULT_FW_NAME);
-MODULE_FIRMWARE(PCIE8997_DEFAULT_FW_NAME);
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 29e58ce..4455d19 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -30,14 +30,22 @@
 #include"main.h"
 
 #define PCIE8766_DEFAULT_FW_NAME "mrvl/pcie8766_uapsta.bin"
-#define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
-#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcie8997_uapsta.bin"
+#define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
+#define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
+#define PCIE8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
+#define PCIE8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
 
 #define PCIE_VENDOR_ID_MARVELL  (0x11ab)
+#define PCIE_VENDOR_ID_V2_MARVELL   (0x1b4b)
 #define PCIE_DEVICE_ID_MARVELL_88W8766P(0x2b30)
 #define PCIE_DEVICE_ID_MARVELL_88W8897

[PATCH RESEND 7/7] mwifiex: dump pcie scratch registers

[Amitkumar Karwar]

From: Xinming Hu 

This patch prints pcie scratch registers during firmware dump. They
will be useful for analysing firmware status.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/main.c |  8 +++---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 42 +
 drivers/net/wireless/marvell/mwifiex/pcie.h |  2 ++
 3 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 3cfa946..04b975c 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1074,12 +1074,14 @@ void mwifiex_drv_info_dump(struct mwifiex_adapter 
*adapter)
 priv->netdev->name, priv->num_tx_timeout);
}
 
-   if (adapter->iface_type == MWIFIEX_SDIO) {
-   p += sprintf(p, "\n=== SDIO register dump===\n");
+   if (adapter->iface_type == MWIFIEX_SDIO ||
+   adapter->iface_type == MWIFIEX_PCIE) {
+   p += sprintf(p, "\n=== %s register dump===\n",
+adapter->iface_type == MWIFIEX_SDIO ?
+   "SDIO" : "PCIE");
if (adapter->if_ops.reg_dump)
p += adapter->if_ops.reg_dump(adapter, p);
}
-
p += sprintf(p, "\n=== more debug information\n");
debug_info = kzalloc(sizeof(*debug_info), GFP_KERNEL);
if (debug_info) {
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 6a06ca5..edf8b07 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2355,6 +2355,47 @@ static int mwifiex_pcie_host_to_card(struct 
mwifiex_adapter *adapter, u8 type,
return 0;
 }
 
+/* Function to dump PCIE scratch registers in case of FW crash
+ */
+static int
+mwifiex_pcie_reg_dump(struct mwifiex_adapter *adapter, char *drv_buf)
+{
+   char *p = drv_buf;
+   char buf[256], *ptr;
+   int i;
+   u32 value;
+   struct pcie_service_card *card = adapter->card;
+   const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+   int pcie_scratch_reg[] = {PCIE_SCRATCH_12_REG,
+ PCIE_SCRATCH_13_REG,
+ PCIE_SCRATCH_14_REG};
+
+   if (!p)
+   return 0;
+
+   mwifiex_dbg(adapter, MSG, "PCIE register dump start\n");
+
+   if (mwifiex_read_reg(adapter, reg->fw_status, )) {
+   mwifiex_dbg(adapter, ERROR, "failed to read firmware status");
+   return 0;
+   }
+
+   ptr = buf;
+   mwifiex_dbg(adapter, MSG, "pcie scratch register:");
+   for (i = 0; i < ARRAY_SIZE(pcie_scratch_reg); i++) {
+   mwifiex_read_reg(adapter, pcie_scratch_reg[i], );
+   ptr += sprintf(ptr, "reg:0x%x, value=0x%x\n",
+  pcie_scratch_reg[i], value);
+   }
+
+   mwifiex_dbg(adapter, MSG, "%s\n", buf);
+   p += sprintf(p, "%s\n", buf);
+
+   mwifiex_dbg(adapter, MSG, "PCIE register dump end\n");
+
+   return p - drv_buf;
+}
+
 /* This function read/write firmware */
 static enum rdwr_status
 mwifiex_pcie_rdwr_firmware(struct mwifiex_adapter *adapter, u8 doneflag)
@@ -2899,6 +2940,7 @@ static struct mwifiex_if_ops pcie_ops = {
.cleanup_mpa_buf =  NULL,
.init_fw_port = mwifiex_pcie_init_fw_port,
.clean_pcie_ring =  mwifiex_clean_pcie_ring_buf,
+   .reg_dump = mwifiex_pcie_reg_dump,
.device_dump =  mwifiex_pcie_device_dump,
 };
 
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 4455d19..cc7a5df 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -73,6 +73,8 @@
 #define PCIE_SCRATCH_10_REG0xCE8
 #define PCIE_SCRATCH_11_REG0xCEC
 #define PCIE_SCRATCH_12_REG0xCF0
+#define PCIE_SCRATCH_13_REG0xCF8
+#define PCIE_SCRATCH_14_REG0xCFC
 #define PCIE_RD_DATA_PTR_Q0_Q1  0xC08C
 #define PCIE_WR_DATA_PTR_Q0_Q1  0xC05C
 
-- 
1.8.1.4

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

[PATCH RESEND 6/7] mwifiex: AMSDU Rx frame handling in AP mode

[Amitkumar Karwar]

From: Xinming Hu 

This patch processes sub AMSDU frame received in AP mode.

If a packet is multicast/broadcast, it is sent to kernel/upper
layer as well as queued back to AP TX queue so that it can be
sent to other associated stations.

If a packet is unicast and RA is present in associated station list,
it is again requeued into AP TX queue.

If a packet is unicast and RA is not in associated station list,
packet is forwarded to kernel to handle routing logic.

Signed-off-by: Xinming Hu 
Signed-off-by: Cathy Luo 
Signed-off-by: Amitkumar Karwar 
---
 .../net/wireless/marvell/mwifiex/11n_rxreorder.c   |  5 +-
 drivers/net/wireless/marvell/mwifiex/main.h|  2 +
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c| 90 ++
 3 files changed, 96 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c 
b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index 09578c6..a74cc43 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -59,7 +59,10 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct 
mwifiex_private *priv,
  skb->len);
}
 
-   ret = mwifiex_recv_packet(priv, rx_skb);
+   if (priv->bss_role == MWIFIEX_BSS_ROLE_UAP)
+   ret = mwifiex_uap_recv_packet(priv, rx_skb);
+   else
+   ret = mwifiex_recv_packet(priv, rx_skb);
if (ret == -1)
mwifiex_dbg(priv->adapter, ERROR,
"Rx of A-MSDU failed");
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index eb2c90c..63069dd 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1019,6 +1019,8 @@ int mwifiex_shutdown_fw_complete(struct mwifiex_adapter 
*adapter);
 int mwifiex_dnld_fw(struct mwifiex_adapter *, struct mwifiex_fw_image *);
 
 int mwifiex_recv_packet(struct mwifiex_private *priv, struct sk_buff *skb);
+int mwifiex_uap_recv_packet(struct mwifiex_private *priv,
+   struct sk_buff *skb);
 
 int mwifiex_process_mgmt_packet(struct mwifiex_private *priv,
struct sk_buff *skb);
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c 
b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
index 305589e..666e91a 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
@@ -269,6 +269,96 @@ int mwifiex_handle_uap_rx_forward(struct mwifiex_private 
*priv,
return mwifiex_process_rx_packet(priv, skb);
 }
 
+int mwifiex_uap_recv_packet(struct mwifiex_private *priv,
+   struct sk_buff *skb)
+{
+   struct mwifiex_adapter *adapter = adapter;
+   struct mwifiex_sta_node *src_node;
+   struct ethhdr *p_ethhdr;
+   struct sk_buff *skb_uap;
+   struct mwifiex_txinfo *tx_info;
+
+   if (!skb)
+   return -1;
+
+   p_ethhdr = (void *)skb->data;
+   src_node = mwifiex_get_sta_entry(priv, p_ethhdr->h_source);
+   if (src_node) {
+   src_node->stats.last_rx = jiffies;
+   src_node->stats.rx_bytes += skb->len;
+   src_node->stats.rx_packets++;
+   }
+
+   skb->dev = priv->netdev;
+   skb->protocol = eth_type_trans(skb, priv->netdev);
+   skb->ip_summed = CHECKSUM_NONE;
+
+   /* This is required only in case of 11n and USB/PCIE as we alloc
+* a buffer of 4K only if its 11N (to be able to receive 4K
+* AMSDU packets). In case of SD we allocate buffers based
+* on the size of packet and hence this is not needed.
+*
+* Modifying the truesize here as our allocation for each
+* skb is 4K but we only receive 2K packets and this cause
+* the kernel to start dropping packets in case where
+* application has allocated buffer based on 2K size i.e.
+* if there a 64K packet received (in IP fragments and
+* application allocates 64K to receive this packet but
+* this packet would almost double up because we allocate
+* each 1.5K fragment in 4K and pass it up. As soon as the
+* 64K limit hits kernel will start to drop rest of the
+* fragments. Currently we fail the Filesndl-ht.scr script
+* for UDP, hence this fix
+*/
+   if ((adapter->iface_type == MWIFIEX_USB ||
+adapter->iface_type == MWIFIEX_PCIE) &&
+   (skb->truesize > MWIFIEX_RX_DATA_BUF_SIZE))
+   skb->truesize += (skb->len - MWIFIEX_RX_DATA_BUF_SIZE);
+
+   if (is_multicast_ether_addr(p_ethhdr->h_dest) ||
+   

[PATCH RESEND 4/7] mwifiex: remove redundant GFP_DMA flag

[Amitkumar Karwar]

From: Xinming Hu 

skb forwarded to TCP/IP stack doesn't need to allocate in DMA ZONE.
This patch removes GFP_DMA flag in this case to save precious DMA
memory.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 901c064..2ea2827 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1122,8 +1122,8 @@ static void mwifiex_deaggr_sdio_pkt(struct 
mwifiex_adapter *adapter,
__func__, pkt_len, blk_size);
break;
}
-   skb_deaggr = mwifiex_alloc_dma_align_buf(pkt_len,
-GFP_KERNEL | GFP_DMA);
+
+   skb_deaggr = mwifiex_alloc_dma_align_buf(pkt_len, GFP_KERNEL);
if (!skb_deaggr)
break;
skb_put(skb_deaggr, pkt_len);
@@ -1372,8 +1372,7 @@ static int mwifiex_sdio_card_to_host_mp_aggr(struct 
mwifiex_adapter *adapter,
 
/* copy pkt to deaggr buf */
skb_deaggr = mwifiex_alloc_dma_align_buf(len_arr[pind],
-GFP_KERNEL |
-GFP_DMA);
+GFP_KERNEL);
if (!skb_deaggr) {
mwifiex_dbg(adapter, ERROR, "skb allocation 
failure\t"
"drop pkt len=%d type=%d\n",
-- 
1.8.1.4

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

[PATCH RESEND 2/7] mwifiex: add support for wakeup on GTK rekey failure

[Amitkumar Karwar]

From: Ganapathi Bhat 

User can configure wakeup on GTK rekey fail with wowlan.
Added corresponding wakeup reason.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 7 ++-
 drivers/net/wireless/marvell/mwifiex/fw.h   | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index ca8cdd2..49661e0 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3390,6 +3390,10 @@ static int mwifiex_cfg80211_resume(struct wiphy *wiphy)
break;
caseMANAGEMENT_FRAME_MATCHED:
break;
+   case GTK_REKEY_FAILURE:
+   if (wiphy->wowlan_config->gtk_rekey_failure)
+   wakeup_report.gtk_rekey_failure = true;
+   break;
default:
break;
}
@@ -3965,7 +3969,8 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
 #ifdef CONFIG_PM
 static const struct wiphy_wowlan_support mwifiex_wowlan_support = {
.flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT |
-   WIPHY_WOWLAN_NET_DETECT | WIPHY_WOWLAN_SUPPORTS_GTK_REKEY,
+   WIPHY_WOWLAN_NET_DETECT | WIPHY_WOWLAN_SUPPORTS_GTK_REKEY |
+   WIPHY_WOWLAN_GTK_REKEY_FAILURE,
.n_patterns = MWIFIEX_MEF_MAX_FILTERS,
.pattern_min_len = 1,
.pattern_max_len = MWIFIEX_MAX_PATTERN_LEN,
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h 
b/drivers/net/wireless/marvell/mwifiex/fw.h
index 8703d24..8e4145a 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -620,6 +620,7 @@ enum HS_WAKEUP_REASON {
MAGIC_PATTERN_MATCHED,
CONTROL_FRAME_MATCHED,
MANAGEMENT_FRAME_MATCHED,
+   GTK_REKEY_FAILURE,
RESERVED
 };
 
-- 
1.8.1.4

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

[PATCH RESEND 1/7] mwifiex: add support for GTK rekey offload

[Amitkumar Karwar]

From: Ganapathi Bhat 

Added driver functionality to offload GTK rekey to firmware. When
AP sends new GTK, firmware will update it.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c| 13 +-
 drivers/net/wireless/marvell/mwifiex/fw.h  | 10 
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 ++
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |  2 ++
 drivers/net/wireless/marvell/mwifiex/sta_event.c   |  3 +++
 5 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 108e641..ca8cdd2 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3416,6 +3416,16 @@ static void mwifiex_cfg80211_set_wakeup(struct wiphy 
*wiphy,
 
device_set_wakeup_enable(adapter->dev, enabled);
 }
+
+static int mwifiex_set_rekey_data(struct wiphy *wiphy, struct net_device *dev,
+ struct cfg80211_gtk_rekey_data *data)
+{
+   struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+
+   return mwifiex_send_cmd(priv, HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG,
+   HostCmd_ACT_GEN_SET, 0, data, true);
+}
+
 #endif
 
 static int mwifiex_get_coalesce_pkt_type(u8 *byte_seq)
@@ -3938,6 +3948,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
.suspend = mwifiex_cfg80211_suspend,
.resume = mwifiex_cfg80211_resume,
.set_wakeup = mwifiex_cfg80211_set_wakeup,
+   .set_rekey_data = mwifiex_set_rekey_data,
 #endif
.set_coalesce = mwifiex_cfg80211_set_coalesce,
.tdls_mgmt = mwifiex_cfg80211_tdls_mgmt,
@@ -3954,7 +3965,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
 #ifdef CONFIG_PM
 static const struct wiphy_wowlan_support mwifiex_wowlan_support = {
.flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT |
-   WIPHY_WOWLAN_NET_DETECT,
+   WIPHY_WOWLAN_NET_DETECT | WIPHY_WOWLAN_SUPPORTS_GTK_REKEY,
.n_patterns = MWIFIEX_MEF_MAX_FILTERS,
.pattern_min_len = 1,
.pattern_max_len = MWIFIEX_MAX_PATTERN_LEN,
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h 
b/drivers/net/wireless/marvell/mwifiex/fw.h
index c134cf8..8703d24 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -372,6 +372,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
 #define HostCmd_CMD_COALESCE_CFG  0x010a
 #define HostCmd_CMD_MGMT_FRAME_REG0x010c
 #define HostCmd_CMD_REMAIN_ON_CHAN0x010d
+#define HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG 0x010f
 #define HostCmd_CMD_11AC_CFG 0x0112
 #define HostCmd_CMD_HS_WAKEUP_REASON  0x0116
 #define HostCmd_CMD_TDLS_CONFIG   0x0100
@@ -2183,6 +2184,14 @@ struct host_cmd_ds_wakeup_reason {
u16  wakeup_reason;
 } __packed;
 
+struct host_cmd_ds_gtk_rekey_params {
+   __le16 action;
+   u8 kck[NL80211_KCK_LEN];
+   u8 kek[NL80211_KEK_LEN];
+   __le32 replay_ctr_low;
+   __le32 replay_ctr_high;
+} __packed;
+
 struct host_cmd_ds_command {
__le16 command;
__le16 size;
@@ -2256,6 +2265,7 @@ struct host_cmd_ds_command {
struct host_cmd_ds_multi_chan_policy mc_policy;
struct host_cmd_ds_robust_coex coex;
struct host_cmd_ds_wakeup_reason hs_wakeup_reason;
+   struct host_cmd_ds_gtk_rekey_params rekey;
} params;
 } __packed;
 
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 30f1526..8cb895b 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1558,6 +1558,30 @@ static int mwifiex_cmd_robust_coex(struct 
mwifiex_private *priv,
return 0;
 }
 
+static int mwifiex_cmd_gtk_rekey_offload(struct mwifiex_private *priv,
+struct host_cmd_ds_command *cmd,
+u16 cmd_action,
+struct cfg80211_gtk_rekey_data *data)
+{
+   struct host_cmd_ds_gtk_rekey_params *rekey = >params.rekey;
+   u64 rekey_ctr;
+
+   cmd->command = cpu_to_le16(HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG);
+   cmd->size = cpu_to_le16(sizeof(*rekey) + S_DS_GEN);
+
+   rekey->action = cpu_to_le16(cmd_action);
+   if (cmd_action == HostCmd_ACT_GEN_SET) {
+   memcpy(rekey->kek, data->kek, NL80211_KEK_LEN);
+   memcpy(rekey->kck, data->kck, NL80211_KCK_LEN);
+   rekey_ctr = be64_to_cpup((__be64 *)data->replay_ctr);
+   rekey->replay_ctr_low = cpu_to_le32((u32)rekey_ctr);
+  

[PATCH 7/7] mwifiex: dump pcie scratch registers

[Amitkumar Karwar]

From: Xinming Hu 

This patch prints pcie scratch registers during firmware dump. They
will be useful for analysing firmware status.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/main.c |  8 +++---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 42 +
 drivers/net/wireless/marvell/mwifiex/pcie.h |  2 ++
 3 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 3cfa946..04b975c 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1074,12 +1074,14 @@ void mwifiex_drv_info_dump(struct mwifiex_adapter 
*adapter)
 priv->netdev->name, priv->num_tx_timeout);
}
 
-   if (adapter->iface_type == MWIFIEX_SDIO) {
-   p += sprintf(p, "\n=== SDIO register dump===\n");
+   if (adapter->iface_type == MWIFIEX_SDIO ||
+   adapter->iface_type == MWIFIEX_PCIE) {
+   p += sprintf(p, "\n=== %s register dump===\n",
+adapter->iface_type == MWIFIEX_SDIO ?
+   "SDIO" : "PCIE");
if (adapter->if_ops.reg_dump)
p += adapter->if_ops.reg_dump(adapter, p);
}
-
p += sprintf(p, "\n=== more debug information\n");
debug_info = kzalloc(sizeof(*debug_info), GFP_KERNEL);
if (debug_info) {
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 6a06ca5..edf8b07 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2355,6 +2355,47 @@ static int mwifiex_pcie_host_to_card(struct 
mwifiex_adapter *adapter, u8 type,
return 0;
 }
 
+/* Function to dump PCIE scratch registers in case of FW crash
+ */
+static int
+mwifiex_pcie_reg_dump(struct mwifiex_adapter *adapter, char *drv_buf)
+{
+   char *p = drv_buf;
+   char buf[256], *ptr;
+   int i;
+   u32 value;
+   struct pcie_service_card *card = adapter->card;
+   const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+   int pcie_scratch_reg[] = {PCIE_SCRATCH_12_REG,
+ PCIE_SCRATCH_13_REG,
+ PCIE_SCRATCH_14_REG};
+
+   if (!p)
+   return 0;
+
+   mwifiex_dbg(adapter, MSG, "PCIE register dump start\n");
+
+   if (mwifiex_read_reg(adapter, reg->fw_status, )) {
+   mwifiex_dbg(adapter, ERROR, "failed to read firmware status");
+   return 0;
+   }
+
+   ptr = buf;
+   mwifiex_dbg(adapter, MSG, "pcie scratch register:");
+   for (i = 0; i < ARRAY_SIZE(pcie_scratch_reg); i++) {
+   mwifiex_read_reg(adapter, pcie_scratch_reg[i], );
+   ptr += sprintf(ptr, "reg:0x%x, value=0x%x\n",
+  pcie_scratch_reg[i], value);
+   }
+
+   mwifiex_dbg(adapter, MSG, "%s\n", buf);
+   p += sprintf(p, "%s\n", buf);
+
+   mwifiex_dbg(adapter, MSG, "PCIE register dump end\n");
+
+   return p - drv_buf;
+}
+
 /* This function read/write firmware */
 static enum rdwr_status
 mwifiex_pcie_rdwr_firmware(struct mwifiex_adapter *adapter, u8 doneflag)
@@ -2899,6 +2940,7 @@ static struct mwifiex_if_ops pcie_ops = {
.cleanup_mpa_buf =  NULL,
.init_fw_port = mwifiex_pcie_init_fw_port,
.clean_pcie_ring =  mwifiex_clean_pcie_ring_buf,
+   .reg_dump = mwifiex_pcie_reg_dump,
.device_dump =  mwifiex_pcie_device_dump,
 };
 
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 4455d19..cc7a5df 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -73,6 +73,8 @@
 #define PCIE_SCRATCH_10_REG0xCE8
 #define PCIE_SCRATCH_11_REG0xCEC
 #define PCIE_SCRATCH_12_REG0xCF0
+#define PCIE_SCRATCH_13_REG0xCF8
+#define PCIE_SCRATCH_14_REG0xCFC
 #define PCIE_RD_DATA_PTR_Q0_Q1  0xC08C
 #define PCIE_WR_DATA_PTR_Q0_Q1  0xC05C
 
-- 
1.8.1.4

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

[PATCH 6/7] mwifiex: AMSDU Rx frame handling in AP mode

[Amitkumar Karwar]

From: Xinming Hu 

This patch processes sub AMSDU frame received in AP mode.

If a packet is multicast/broadcast, it is sent to kernel/upper
layer as well as queued back to AP TX queue so that it can be
sent to other associated stations.

If a packet is unicast and RA is present in associated station list,
it is again requeued into AP TX queue.

If a packet is unicast and RA is not in associated station list,
packet is forwarded to kernel to handle routing logic.

Signed-off-by: Xinming Hu 
Signed-off-by: Cathy Luo 
Signed-off-by: Amitkumar Karwar 
---
 .../net/wireless/marvell/mwifiex/11n_rxreorder.c   |  5 +-
 drivers/net/wireless/marvell/mwifiex/main.h|  2 +
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c| 90 ++
 3 files changed, 96 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c 
b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index 09578c6..a74cc43 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -59,7 +59,10 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct 
mwifiex_private *priv,
  skb->len);
}
 
-   ret = mwifiex_recv_packet(priv, rx_skb);
+   if (priv->bss_role == MWIFIEX_BSS_ROLE_UAP)
+   ret = mwifiex_uap_recv_packet(priv, rx_skb);
+   else
+   ret = mwifiex_recv_packet(priv, rx_skb);
if (ret == -1)
mwifiex_dbg(priv->adapter, ERROR,
"Rx of A-MSDU failed");
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index eb2c90c..63069dd 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1019,6 +1019,8 @@ int mwifiex_shutdown_fw_complete(struct mwifiex_adapter 
*adapter);
 int mwifiex_dnld_fw(struct mwifiex_adapter *, struct mwifiex_fw_image *);
 
 int mwifiex_recv_packet(struct mwifiex_private *priv, struct sk_buff *skb);
+int mwifiex_uap_recv_packet(struct mwifiex_private *priv,
+   struct sk_buff *skb);
 
 int mwifiex_process_mgmt_packet(struct mwifiex_private *priv,
struct sk_buff *skb);
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c 
b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
index 305589e..666e91a 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
@@ -269,6 +269,96 @@ int mwifiex_handle_uap_rx_forward(struct mwifiex_private 
*priv,
return mwifiex_process_rx_packet(priv, skb);
 }
 
+int mwifiex_uap_recv_packet(struct mwifiex_private *priv,
+   struct sk_buff *skb)
+{
+   struct mwifiex_adapter *adapter = adapter;
+   struct mwifiex_sta_node *src_node;
+   struct ethhdr *p_ethhdr;
+   struct sk_buff *skb_uap;
+   struct mwifiex_txinfo *tx_info;
+
+   if (!skb)
+   return -1;
+
+   p_ethhdr = (void *)skb->data;
+   src_node = mwifiex_get_sta_entry(priv, p_ethhdr->h_source);
+   if (src_node) {
+   src_node->stats.last_rx = jiffies;
+   src_node->stats.rx_bytes += skb->len;
+   src_node->stats.rx_packets++;
+   }
+
+   skb->dev = priv->netdev;
+   skb->protocol = eth_type_trans(skb, priv->netdev);
+   skb->ip_summed = CHECKSUM_NONE;
+
+   /* This is required only in case of 11n and USB/PCIE as we alloc
+* a buffer of 4K only if its 11N (to be able to receive 4K
+* AMSDU packets). In case of SD we allocate buffers based
+* on the size of packet and hence this is not needed.
+*
+* Modifying the truesize here as our allocation for each
+* skb is 4K but we only receive 2K packets and this cause
+* the kernel to start dropping packets in case where
+* application has allocated buffer based on 2K size i.e.
+* if there a 64K packet received (in IP fragments and
+* application allocates 64K to receive this packet but
+* this packet would almost double up because we allocate
+* each 1.5K fragment in 4K and pass it up. As soon as the
+* 64K limit hits kernel will start to drop rest of the
+* fragments. Currently we fail the Filesndl-ht.scr script
+* for UDP, hence this fix
+*/
+   if ((adapter->iface_type == MWIFIEX_USB ||
+adapter->iface_type == MWIFIEX_PCIE) &&
+   (skb->truesize > MWIFIEX_RX_DATA_BUF_SIZE))
+   skb->truesize += (skb->len - MWIFIEX_RX_DATA_BUF_SIZE);
+
+   if (is_multicast_ether_addr(p_ethhdr->h_dest) ||
+   

[PATCH 1/7] mwifiex: add support for GTK rekey offload

[Amitkumar Karwar]

From: Ganapathi Bhat 

Added driver functionality to offload GTK rekey to firmware. When
AP sends new GTK, firmware will update it.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c| 13 +-
 drivers/net/wireless/marvell/mwifiex/fw.h  | 10 
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 ++
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |  2 ++
 drivers/net/wireless/marvell/mwifiex/sta_event.c   |  3 +++
 5 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 108e641..ca8cdd2 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3416,6 +3416,16 @@ static void mwifiex_cfg80211_set_wakeup(struct wiphy 
*wiphy,
 
device_set_wakeup_enable(adapter->dev, enabled);
 }
+
+static int mwifiex_set_rekey_data(struct wiphy *wiphy, struct net_device *dev,
+ struct cfg80211_gtk_rekey_data *data)
+{
+   struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
+
+   return mwifiex_send_cmd(priv, HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG,
+   HostCmd_ACT_GEN_SET, 0, data, true);
+}
+
 #endif
 
 static int mwifiex_get_coalesce_pkt_type(u8 *byte_seq)
@@ -3938,6 +3948,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
.suspend = mwifiex_cfg80211_suspend,
.resume = mwifiex_cfg80211_resume,
.set_wakeup = mwifiex_cfg80211_set_wakeup,
+   .set_rekey_data = mwifiex_set_rekey_data,
 #endif
.set_coalesce = mwifiex_cfg80211_set_coalesce,
.tdls_mgmt = mwifiex_cfg80211_tdls_mgmt,
@@ -3954,7 +3965,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
 #ifdef CONFIG_PM
 static const struct wiphy_wowlan_support mwifiex_wowlan_support = {
.flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT |
-   WIPHY_WOWLAN_NET_DETECT,
+   WIPHY_WOWLAN_NET_DETECT | WIPHY_WOWLAN_SUPPORTS_GTK_REKEY,
.n_patterns = MWIFIEX_MEF_MAX_FILTERS,
.pattern_min_len = 1,
.pattern_max_len = MWIFIEX_MAX_PATTERN_LEN,
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h 
b/drivers/net/wireless/marvell/mwifiex/fw.h
index c134cf8..8703d24 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -372,6 +372,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
 #define HostCmd_CMD_COALESCE_CFG  0x010a
 #define HostCmd_CMD_MGMT_FRAME_REG0x010c
 #define HostCmd_CMD_REMAIN_ON_CHAN0x010d
+#define HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG 0x010f
 #define HostCmd_CMD_11AC_CFG 0x0112
 #define HostCmd_CMD_HS_WAKEUP_REASON  0x0116
 #define HostCmd_CMD_TDLS_CONFIG   0x0100
@@ -2183,6 +2184,14 @@ struct host_cmd_ds_wakeup_reason {
u16  wakeup_reason;
 } __packed;
 
+struct host_cmd_ds_gtk_rekey_params {
+   __le16 action;
+   u8 kck[NL80211_KCK_LEN];
+   u8 kek[NL80211_KEK_LEN];
+   __le32 replay_ctr_low;
+   __le32 replay_ctr_high;
+} __packed;
+
 struct host_cmd_ds_command {
__le16 command;
__le16 size;
@@ -2256,6 +2265,7 @@ struct host_cmd_ds_command {
struct host_cmd_ds_multi_chan_policy mc_policy;
struct host_cmd_ds_robust_coex coex;
struct host_cmd_ds_wakeup_reason hs_wakeup_reason;
+   struct host_cmd_ds_gtk_rekey_params rekey;
} params;
 } __packed;
 
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 30f1526..8cb895b 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1558,6 +1558,30 @@ static int mwifiex_cmd_robust_coex(struct 
mwifiex_private *priv,
return 0;
 }
 
+static int mwifiex_cmd_gtk_rekey_offload(struct mwifiex_private *priv,
+struct host_cmd_ds_command *cmd,
+u16 cmd_action,
+struct cfg80211_gtk_rekey_data *data)
+{
+   struct host_cmd_ds_gtk_rekey_params *rekey = >params.rekey;
+   u64 rekey_ctr;
+
+   cmd->command = cpu_to_le16(HostCmd_CMD_GTK_REKEY_OFFLOAD_CFG);
+   cmd->size = cpu_to_le16(sizeof(*rekey) + S_DS_GEN);
+
+   rekey->action = cpu_to_le16(cmd_action);
+   if (cmd_action == HostCmd_ACT_GEN_SET) {
+   memcpy(rekey->kek, data->kek, NL80211_KEK_LEN);
+   memcpy(rekey->kck, data->kck, NL80211_KCK_LEN);
+   rekey_ctr = be64_to_cpup((__be64 *)data->replay_ctr);
+   rekey->replay_ctr_low = cpu_to_le32((u32)rekey_ctr);
+  

[PATCH 5/7] mwifiex: schedule main workqueue for transmitting bridge packets

[Amitkumar Karwar]

From: Xinming Hu 

Bridge packets are enqueued to wmm tx queue, but will not be sent
until main workqeue is scheduled for new interrupt or other
reason. This adds unnecessary delay during traffic.

We will schedule main workqueue when bridge packet is queued.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c 
b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
index 193a809..305589e 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
@@ -216,6 +216,8 @@ static void mwifiex_uap_queue_bridged_pkt(struct 
mwifiex_private *priv,
atomic_inc(>tx_pending);
atomic_inc(>pending_bridged_pkts);
 
+   mwifiex_queue_main_work(priv->adapter);
+
return;
 }
 
-- 
1.8.1.4

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

[PATCH 2/7] mwifiex: add support for wakeup on GTK rekey failure

[Amitkumar Karwar]

From: Ganapathi Bhat 

User can configure wakeup on GTK rekey fail with wowlan.
Added corresponding wakeup reason.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 7 ++-
 drivers/net/wireless/marvell/mwifiex/fw.h   | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index ca8cdd2..49661e0 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3390,6 +3390,10 @@ static int mwifiex_cfg80211_resume(struct wiphy *wiphy)
break;
caseMANAGEMENT_FRAME_MATCHED:
break;
+   case GTK_REKEY_FAILURE:
+   if (wiphy->wowlan_config->gtk_rekey_failure)
+   wakeup_report.gtk_rekey_failure = true;
+   break;
default:
break;
}
@@ -3965,7 +3969,8 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
 #ifdef CONFIG_PM
 static const struct wiphy_wowlan_support mwifiex_wowlan_support = {
.flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT |
-   WIPHY_WOWLAN_NET_DETECT | WIPHY_WOWLAN_SUPPORTS_GTK_REKEY,
+   WIPHY_WOWLAN_NET_DETECT | WIPHY_WOWLAN_SUPPORTS_GTK_REKEY |
+   WIPHY_WOWLAN_GTK_REKEY_FAILURE,
.n_patterns = MWIFIEX_MEF_MAX_FILTERS,
.pattern_min_len = 1,
.pattern_max_len = MWIFIEX_MAX_PATTERN_LEN,
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h 
b/drivers/net/wireless/marvell/mwifiex/fw.h
index 8703d24..8e4145a 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -620,6 +620,7 @@ enum HS_WAKEUP_REASON {
MAGIC_PATTERN_MATCHED,
CONTROL_FRAME_MATCHED,
MANAGEMENT_FRAME_MATCHED,
+   GTK_REKEY_FAILURE,
RESERVED
 };
 
-- 
1.8.1.4

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

[PATCH 3/7] mwifiex: check revision id while choosing PCIe firmware

[Amitkumar Karwar]

From: Shengzhen Li 

Some of the chipsets have two revisions. This patch
selects appropriate firmware by checking revision id.

Signed-off-by: Shengzhen Li 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 56 ++---
 drivers/net/wireless/marvell/mwifiex/pcie.h | 16 +
 2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index de36438..6a06ca5 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -190,7 +190,6 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
 
if (ent->driver_data) {
struct mwifiex_pcie_device *data = (void *)ent->driver_data;
-   card->pcie.firmware = data->firmware;
card->pcie.reg = data->reg;
card->pcie.blksz_fw_dl = data->blksz_fw_dl;
card->pcie.tx_buf_size = data->tx_buf_size;
@@ -269,6 +268,11 @@ static const struct pci_device_id mwifiex_ids[] = {
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
.driver_data = (unsigned long)_pcie8997,
},
+   {
+   PCIE_VENDOR_ID_V2_MARVELL, PCIE_DEVICE_ID_MARVELL_88W8997,
+   PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+   .driver_data = (unsigned long)_pcie8997,
+   },
{},
 };
 
@@ -2759,6 +2763,51 @@ static int mwifiex_pcie_request_irq(struct 
mwifiex_adapter *adapter)
 }
 
 /*
+ * This function get firmare name for downloading by revision id
+ *
+ * Read revision id register to get revision id
+ */
+static void mwifiex_pcie_get_fw_name(struct mwifiex_adapter *adapter)
+{
+   int revision_id = 0;
+   struct pcie_service_card *card = adapter->card;
+
+   switch (card->dev->device) {
+   case PCIE_DEVICE_ID_MARVELL_88W8766P:
+   strcpy(adapter->fw_name, PCIE8766_DEFAULT_FW_NAME);
+   break;
+   case PCIE_DEVICE_ID_MARVELL_88W8897:
+   mwifiex_write_reg(adapter, 0x0c58, 0x80c0);
+   mwifiex_read_reg(adapter, 0x0c58, _id);
+   revision_id &= 0xff00;
+   switch (revision_id) {
+   case PCIE8897_A0:
+   strcpy(adapter->fw_name, PCIE8897_A0_FW_NAME);
+   break;
+   case PCIE8897_B0:
+   strcpy(adapter->fw_name, PCIE8897_B0_FW_NAME);
+   break;
+   default:
+   break;
+   }
+   case PCIE_DEVICE_ID_MARVELL_88W8997:
+   mwifiex_read_reg(adapter, 0x0c48, _id);
+   switch (revision_id) {
+   case PCIE8997_V2:
+   strcpy(adapter->fw_name, PCIE8997_FW_NAME_V2);
+   break;
+   case PCIE8997_Z:
+   strcpy(adapter->fw_name, PCIE8997_FW_NAME_Z);
+   break;
+   default:
+   break;
+   }
+   default:
+   break;
+   }
+}
+
+/*
  * This function registers the PCIE device.
  *
  * PCIE IRQ is claimed, block size is set and driver data is initialized.
@@ -2778,8 +2827,8 @@ static int mwifiex_register_dev(struct mwifiex_adapter 
*adapter)
adapter->tx_buf_size = card->pcie.tx_buf_size;
adapter->mem_type_mapping_tbl = card->pcie.mem_type_mapping_tbl;
adapter->num_mem_types = card->pcie.num_mem_types;
-   strcpy(adapter->fw_name, card->pcie.firmware);
adapter->ext_scan = card->pcie.can_ext_scan;
+   mwifiex_pcie_get_fw_name(adapter);
 
return 0;
 }
@@ -2907,6 +2956,3 @@ MODULE_AUTHOR("Marvell International Ltd.");
 MODULE_DESCRIPTION("Marvell WiFi-Ex PCI-Express Driver version " PCIE_VERSION);
 MODULE_VERSION(PCIE_VERSION);
 MODULE_LICENSE("GPL v2");
-MODULE_FIRMWARE(PCIE8766_DEFAULT_FW_NAME);
-MODULE_FIRMWARE(PCIE8897_DEFAULT_FW_NAME);
-MODULE_FIRMWARE(PCIE8997_DEFAULT_FW_NAME);
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 29e58ce..4455d19 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -30,14 +30,22 @@
 #include"main.h"
 
 #define PCIE8766_DEFAULT_FW_NAME "mrvl/pcie8766_uapsta.bin"
-#define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
-#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcie8997_uapsta.bin"
+#define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
+#define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
+#define PCIE8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
+#define PCIE8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
 
 #define PCIE_VENDOR_ID_MARVELL  (0x11ab)
+#define PCIE_VENDOR_ID_V2_MARVELL   (0x1b4b)
 #define PCIE_DEVICE_ID_MARVELL_88W8766P(0x2b30)
 #define PCIE_DEVICE_ID_MARVELL_88W8897

[PATCH 4/7] mwifiex: remove redundant GFP_DMA flag

[Amitkumar Karwar]

From: Xinming Hu 

skb forwarded to TCP/IP stack doesn't need to allocate in DMA ZONE.
This patch removes GFP_DMA flag in this case to save precious DMA
memory.

Signed-off-by: Eric Dumaze 
Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 901c064..2ea2827 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1122,8 +1122,8 @@ static void mwifiex_deaggr_sdio_pkt(struct 
mwifiex_adapter *adapter,
__func__, pkt_len, blk_size);
break;
}
-   skb_deaggr = mwifiex_alloc_dma_align_buf(pkt_len,
-GFP_KERNEL | GFP_DMA);
+
+   skb_deaggr = mwifiex_alloc_dma_align_buf(pkt_len, GFP_KERNEL);
if (!skb_deaggr)
break;
skb_put(skb_deaggr, pkt_len);
@@ -1372,8 +1372,7 @@ static int mwifiex_sdio_card_to_host_mp_aggr(struct 
mwifiex_adapter *adapter,
 
/* copy pkt to deaggr buf */
skb_deaggr = mwifiex_alloc_dma_align_buf(len_arr[pind],
-GFP_KERNEL |
-GFP_DMA);
+GFP_KERNEL);
if (!skb_deaggr) {
mwifiex_dbg(adapter, ERROR, "skb allocation 
failure\t"
"drop pkt len=%d type=%d\n",
-- 
1.8.1.4

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

[PATCH 13/14] staging: wilc1000: remove unused hif_drv in wilc_del_beacon

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_del_beacon.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 270bb3e..2dba954 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3742,12 +3742,6 @@ int wilc_del_beacon(struct wilc_vif *vif)
 {
int result = 0;
struct host_if_msg msg;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
msg.id = HOST_IF_MSG_DEL_BEACON;
msg.vif = vif;
-- 
2.8.0

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

[PATCH 04/14] staging: wilc1000: remove unused hif_drv in wilc_set_power_mgmt

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_set_power_mgmt.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index a47666c..bfb738a 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3922,12 +3922,6 @@ int wilc_set_power_mgmt(struct wilc_vif *vif, bool 
enabled, u32 timeout)
int result = 0;
struct host_if_msg msg;
struct power_mgmt_param *pwr_mgmt_info = _mgmt_info;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
if (wilc_wlan_get_num_conn_ifcs(vif->wilc) == 2 && enabled)
return 0;
-- 
2.8.0

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

[PATCH 12/14] staging: wilc1000: remove unused hif_drv in wilc_set_pmkid_info

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_set_pmkid_info.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index d23c8ba..270bb3e 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2957,14 +2957,8 @@ int wilc_set_pmkid_info(struct wilc_vif *vif,
 {
int result = 0;
struct host_if_msg msg;
-   struct host_if_drv *hif_drv = vif->hif_drv;
int i;
 
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
-
memset(, 0, sizeof(struct host_if_msg));
 
msg.id = HOST_IF_MSG_KEY;
-- 
2.8.0

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

[PATCH 14/14] staging: wilc1000: remove unused hif_drv in wilc_add_beacon

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_add_beacon.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 2dba954..eb86fd4 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3693,12 +3693,6 @@ int wilc_add_beacon(struct wilc_vif *vif, u32 interval, 
u32 dtim_period,
int result = 0;
struct host_if_msg msg;
struct beacon_attr *beacon_info = _info;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
 
-- 
2.8.0

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

[PATCH 03/14] staging: wilc1000: remove unused hif_drv in wilc_setup_multicast_filter

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_setup_multicast_filter.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 5cda382..a47666c 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3952,12 +3952,6 @@ int wilc_setup_multicast_filter(struct wilc_vif *vif, 
bool enabled,
int result = 0;
struct host_if_msg msg;
struct set_multicast *multicast_filter_param = _info;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
 
-- 
2.8.0

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

[PATCH 09/14] staging: wilc1000: remove unused hif_drv in wilc_remain_on_channel

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_remain_on_channel.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 0d0026e..8591c00 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3630,12 +3630,6 @@ int wilc_remain_on_channel(struct wilc_vif *vif, u32 
session_id,
 {
int result = 0;
struct host_if_msg msg;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
 
-- 
2.8.0

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

[PATCH 08/14] staging: wilc1000: remove unused hif_drv in wilc_add_station

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_add_station.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 0c4a74e..0d0026e 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3788,12 +3788,6 @@ int wilc_add_station(struct wilc_vif *vif, struct 
add_sta_param *sta_param)
int result = 0;
struct host_if_msg msg;
struct add_sta_param *add_sta_info = _sta_info;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
 
-- 
2.8.0

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

[PATCH 06/14] staging: wilc1000: remove unused hif_drv in wilc_del_allstation

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_del_allstation.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 3222a5d..4433f99 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3848,16 +3848,10 @@ int wilc_del_allstation(struct wilc_vif *vif, u8 
mac_addr[][ETH_ALEN])
int result = 0;
struct host_if_msg msg;
struct del_all_sta *del_all_sta_info = _all_sta_info;
-   struct host_if_drv *hif_drv = vif->hif_drv;
u8 zero_addr[ETH_ALEN] = {0};
int i;
u8 assoc_sta = 0;
 
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
-
memset(, 0, sizeof(struct host_if_msg));
 
msg.id = HOST_IF_MSG_DEL_ALL_STA;
-- 
2.8.0

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

[PATCH 10/14] staging: wilc1000: remove unused hif_drv in wilc_set_mac_chnl_num

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_set_mac_chnl_num.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 8591c00..7b28ae5 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3134,12 +3134,6 @@ int wilc_set_mac_chnl_num(struct wilc_vif *vif, u8 
channel)
 {
int result;
struct host_if_msg msg;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
msg.id = HOST_IF_MSG_SET_CHANNEL;
-- 
2.8.0

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

[PATCH 11/14] staging: wilc1000: remove unused hif_drv in host_int_get_assoc_res_info

[Chaehyun Lim]

This patch removes unused hif_drv in host_int_get_assoc_res_info.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 7b28ae5..d23c8ba 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3106,12 +3106,6 @@ static s32 host_int_get_assoc_res_info(struct wilc_vif 
*vif,
 {
s32 result = 0;
struct wid wid;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "Driver is null\n");
-   return -EFAULT;
-   }
 
wid.id = (u16)WID_ASSOC_RES_INFO;
wid.type = WID_STR;
-- 
2.8.0

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

[PATCH 05/14] staging: wilc1000: remove unused hif_drv in wilc_edit_station

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_edit_station.
There is no need to checku null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index bfb738a..3222a5d 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3889,12 +3889,6 @@ int wilc_edit_station(struct wilc_vif *vif,
int result = 0;
struct host_if_msg msg;
struct add_sta_param *add_sta_info = _sta_info;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
 
-- 
2.8.0

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

[PATCH 07/14] staging: wilc1000: remove unused hif_drv in wilc_del_station

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_del_station.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 4433f99..0c4a74e 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3820,12 +3820,6 @@ int wilc_del_station(struct wilc_vif *vif, const u8 
*mac_addr)
int result = 0;
struct host_if_msg msg;
struct del_sta *del_sta_info = _sta_info;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
 
-- 
2.8.0

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

[PATCH 01/14] staging: wilc1000: remove unused hif_drv in host_int_get_ipaddress

[Chaehyun Lim]

This patch removes unused hif_drv in host_int_get_ipaddress.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 1fe811f..168c823 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -4157,12 +4157,6 @@ static int host_int_get_ipaddress(struct wilc_vif *vif, 
u8 *ip_addr, u8 idx)
 {
int result = 0;
struct host_if_msg msg;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
 
-- 
2.8.0

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

[PATCH 02/14] staging: wilc1000: remove unused hif_drv in wilc_setup_ipaddress

[Chaehyun Lim]

This patch removes unused hif_drv in wilc_setup_ipaddress.
There is no need to check null and print debug log.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 168c823..5cda382 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -4131,12 +4131,6 @@ int wilc_setup_ipaddress(struct wilc_vif *vif, u8 
*ip_addr, u8 idx)
 {
int result = 0;
struct host_if_msg msg;
-   struct host_if_drv *hif_drv = vif->hif_drv;
-
-   if (!hif_drv) {
-   netdev_err(vif->ndev, "driver is null\n");
-   return -EFAULT;
-   }
 
memset(, 0, sizeof(struct host_if_msg));
 
-- 
2.8.0

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