[PATCH] mac80211: support A-MSDU in fast-rx

[Felix Fietkau]

Only works if the IV was stripped from packets. Create a smaller
variant of ieee80211_rx_h_amsdu, which bypasses checks already done
within the fast-rx context.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rx.c | 122 --
 1 file changed, 73 insertions(+), 49 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 5be957af4b0e..5ae1414ca550 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2353,39 +2353,17 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
 }
 
 static ieee80211_rx_result debug_noinline
-ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
+__ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
 {
struct net_device *dev = rx->sdata->dev;
struct sk_buff *skb = rx->skb;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
__le16 fc = hdr->frame_control;
struct sk_buff_head frame_list;
-   struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
struct ethhdr ethhdr;
const u8 *check_da = ethhdr.h_dest, *check_sa = ethhdr.h_source;
 
-   if (unlikely(!ieee80211_is_data(fc)))
-   return RX_CONTINUE;
-
-   if (unlikely(!ieee80211_is_data_present(fc)))
-   return RX_DROP_MONITOR;
-
-   if (!(status->rx_flags & IEEE80211_RX_AMSDU))
-   return RX_CONTINUE;
-
if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
-   switch (rx->sdata->vif.type) {
-   case NL80211_IFTYPE_AP_VLAN:
-   if (!rx->sdata->u.vlan.sta)
-   return RX_DROP_UNUSABLE;
-   break;
-   case NL80211_IFTYPE_STATION:
-   if (!rx->sdata->u.mgd.use_4addr)
-   return RX_DROP_UNUSABLE;
-   break;
-   default:
-   return RX_DROP_UNUSABLE;
-   }
check_da = NULL;
check_sa = NULL;
} else switch (rx->sdata->vif.type) {
@@ -2405,9 +2383,6 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
break;
}
 
-   if (is_multicast_ether_addr(hdr->addr1))
-   return RX_DROP_UNUSABLE;
-
skb->dev = dev;
__skb_queue_head_init(_list);
 
@@ -2435,6 +2410,44 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
return RX_QUEUED;
 }
 
+static ieee80211_rx_result debug_noinline
+ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
+{
+   struct sk_buff *skb = rx->skb;
+   struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
+   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+   __le16 fc = hdr->frame_control;
+
+   if (!(status->rx_flags & IEEE80211_RX_AMSDU))
+   return RX_CONTINUE;
+
+   if (unlikely(!ieee80211_is_data(fc)))
+   return RX_CONTINUE;
+
+   if (unlikely(!ieee80211_is_data_present(fc)))
+   return RX_DROP_MONITOR;
+
+   if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
+   switch (rx->sdata->vif.type) {
+   case NL80211_IFTYPE_AP_VLAN:
+   if (!rx->sdata->u.vlan.sta)
+   return RX_DROP_UNUSABLE;
+   break;
+   case NL80211_IFTYPE_STATION:
+   if (!rx->sdata->u.mgd.use_4addr)
+   return RX_DROP_UNUSABLE;
+   break;
+   default:
+   return RX_DROP_UNUSABLE;
+   }
+   }
+
+   if (is_multicast_ether_addr(hdr->addr1))
+   return RX_DROP_UNUSABLE;
+
+   return __ieee80211_rx_h_amsdu(rx);
+}
+
 #ifdef CONFIG_MAC80211_MESH
 static ieee80211_rx_result
 ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
@@ -3908,6 +3921,7 @@ static bool ieee80211_invoke_fast_rx(struct 
ieee80211_rx_data *rx,
u8 sa[ETH_ALEN];
} addrs __aligned(2);
struct ieee80211_sta_rx_stats *stats = >rx_stats;
+   int res;
 
if (fast_rx->uses_rss)
stats = this_cpu_ptr(sta->pcpu_rx_stats);
@@ -3929,10 +3943,6 @@ static bool ieee80211_invoke_fast_rx(struct 
ieee80211_rx_data *rx,
(status->flag & FAST_RX_CRYPT_FLAGS) != FAST_RX_CRYPT_FLAGS)
return false;
 
-   /* we don't deal with A-MSDU deaggregation here */
-   if (status->rx_flags & IEEE80211_RX_AMSDU)
-   return false;
-
if (unlikely(!ieee80211_is_data_present(hdr->frame_control)))
return false;
 
@@ -3960,25 +3970,31 @@ static bool ieee80211_invoke_fast_rx(struct 
ieee80211_rx_data *rx,
 * and strip the IV/MIC if necessary
 */
if (fast_rx->key && !(status->flag & RX_FLAG_IV_STRIPPED)) {
+   if (status->rx_flags & IEEE80211_RX_AMSDU)
+   return false;
+

Re: [PATCH v2] ath10k: debugfs support to get final TPC stats for 10.4 variants

[Maharaja Kennadyrajan]

On 2018-02-27 1:19 am, Joshua Zhao wrote:

as you said:
The existing tpc_stats debugfs file provides the dump which is
minimum of target power and regulatory domain.
cat 
/sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats


I’m curious what’s exact difference w/ this new addition:
Export the final Transmit Power Control (TPC) value, which is
the minimum of control power and existing TPC value to user space via
a new debugfs file "tpc_stats_final" to help with debugging.

Can you clarify or give examples on the difference?

Thanks!


The existing tpc_stats is the minimum of "target power and regulatory 
domain".
The new addition is the minimum of "existing tpc_stats and control 
power" which means minimum of "control power, target power and 
regulatory domain".


--
Regards,
Maha

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

[periyasa]

Hi,

This is not a bug, Firmware treats every WMI_PEER_ASSOC_CMDID as a new 
peer assoc. so driver should not give WMI_PEER_ASSOC_CMDID for the 
already associated peer.
For the NSS update, wmi_peer_set_param is enough to update the new NSS 
value.


Regards,
Karthikeyan P.

On 2018-02-27 00:51, Adrian Chadd wrote:

hi,

so it's going to eventually leak? Can we fix the firmware bug too? :)


-a


On 26 February 2018 at 09:06,   wrote:

Hi,


Can you share exactly which resource the firmware ran out of?  It 
would

seem to
be a FW bug if it is leaking, so maybe it can be fixed as well...



Firmware have total user_id = 528 (512 clients + 16 VAPs). Each 
user_id is
allocated to peer when Firmware receive the WMI_PEER_ASSOC_CMDID 
request

from host driver. Firmware free the user_id in peer delete operation.

Regards,
Karthikeyan P.

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] mt7601u: Fix system freeze after resuming from hibernation

[Jakub Kicinski]

On Sun, 25 Feb 2018 17:54:25 +, Luis R. Rodriguez wrote:
> On Mon, Feb 19, 2018 at 05:01:27PM +0200, cantabile wrote:
> > On 19/02/18 07:55, Jakub Kicinski wrote:  
> > > On Sat, 17 Feb 2018 13:23:29 +0200, cantabile wrote:  
> > > > > Thanks for the info.  Would it be cleaner to EXPORT fw_add_devm_name()
> > > > > and just call that in case driver sees FW is already loaded?  That
> > > > > should inform the fw subsystem that we want the image around in case 
> > > > > of
> > > > > hibernation, but there is no need to load it immediately?  
> > > > 
> > > > No, I don't believe it's cleaner to expose a private function that you
> > > > don't even really need. Remember that calling request_firmware every
> > > > time your driver's probe and resume functions are called is normal. It's
> > > > the expected behaviour.  
> > > 
> > > I'm asking you the extend functionality of a subsystem to be able to
> > > cleanly communicate the intent.  Not export internal functions.
> > > 
> > > Requesting firmware you don't need and risking failing probe even if FW
> > > is already pre-loaded is not correct.  Reordering you suggest is
> > > brittle and makes little logical sense unless someone guesses your use
> > > case.
> > > 
> > > Please at least try to do as advised.  Otherwise:
> > > 
> > > Nacked-by: Jakub Kicinski 
> > >   
> > 
> > You're right about the reordering not making sense to someone unfamiliar
> > with the problem. I can fix that with a comment.
> > 
> > I can change the patch so that request_firmware will only make the probe
> > function fail if the firmware is not already running.  
> 
> Note that using request_firmware() on probe typically is also not an
> outstanding idea given it delays boot. Not because looking for the firmware
> takes time, but instead because processing firmware typically does on
> the device. For instance cxgb4 is an example device where processing
> firmware takes a long time.
> 
> Delays on probe may mean the "feel good" immediate desktop coming up is 
> delyed.
> 
> Specially if its networking... I see no reason why to process firmware on 
> probe.
> 
> If one can use a workqueue to process verifying if it needs firmware and 
> loading
> later, that's more advisable.

Quite true, more advanced the FW the longer FW load takes :(  Although
I would be cautious not to cause issues for network/NFS boot...  Perhaps
it can wait for such workqueue to finish?

> Now, that's all a side topic.
> 
> I will for now agree that it seems pointless to request for firmware always
> even if you don't need to, and all you want is to just cache the firmware
> on suspend. So I welcome a patch but the justification for it really needs to
> be documented very well, and the documentation extended as such. In fact
> maybe rename the function to something more sensible.
> 
> Another use case for the firmware cache (which we need to add the 
> documentation)
> is that for hibernation we suspend all devices first, get a snapshot, and then
> resume devices so we can then write the snapshot to disk. On that resume step
> I don't think devices have access to the hard drive for firmware, so cache is
> all we have. This may need some confirmation but I suspect this is the case.
> Drivers needing firmware on resume for hibernation may need to cache their
> firmware.
> 
> I want to understand the case where the firmware is *not* available on resume?
> Why did that happen? I seem to have read that on a fresh reboot the firmware
> was not needed, and so on probe request_firmware() was not called? Why would
> firmware not be required on a reboot?

Yes, that is a good question..  John, do you have a theory?  My initial
thought was that the UEFI/BIOS loads it during pre-boot, but this is a
USB card, so it's a bit unlikely that UEFI will have a driver for it...
Does this happen when rebooting maybe?

[PATCH] rtlwifi: btcoex: fix argument typo of if-statement found by Coccinelle

[pkshih]

From: Ping-Ke Shih 

This was detected with static analysis using Coccinelle:

./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:1107:5-18:
duplicated argument to && or ||

Reported-by: Colin Ian King 
Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index fd3b1fb35dff..05beb16f0a0a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -1104,7 +1104,7 @@ static void halbtc8723b1ant_ps_tdma(struct btc_coexist 
*btcoexist,
}
 
if ((type == 1) || (type == 2) || (type == 9) || (type == 11) ||
-   (type == 101) || (type == 102) || (type == 109) || (type == 101)) {
+   (type == 101) || (type == 102) || (type == 109) || (type == 111)) {
if (!coex_sta->force_lps_on) {
/* Native power save TDMA, only for A2DP-only case
 * 1/2/9/11 while wifi noisy threshold > 30
-- 
2.15.1

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

[Arend van Spriel]

On 2/26/2018 12:22 PM, Hans de Goede wrote:

Hi,

On 26-02-18 12:01, Arend van Spriel wrote:

On 2/26/2018 11:29 AM, Hans de Goede wrote:

Hi,

On 26-02-18 11:22, Arend van Spriel wrote:

On 2/25/2018 3:52 PM, Hans de Goede wrote:

Hi,

On 26-05-17 12:57, Hans de Goede wrote:

The firmware responding with -EBUSY when trying to add an extra
virtual-if
is a normal thing, do not print an error for this.

Signed-off-by: Hans de Goede 


I'm now seeing this on another device too, but this time the error
thrown is -EBADE, this seems to be new with recent kernels:


Yup. Before we were passing firmware errors up to user-space, which
was confusing and potentially be misinterpreted. However, looking at
the output below it would have been good to log the firmware error as
well. And staring at it some more I suddenly realize I broke the
feature detection module with this change. Actually only the GSCAN
feature detection.


[root@localhost ~]# dmesg | grep brcmfmac
[   34.265950] usbcore: registered new interface driver brcmfmac
[   34.266059] brcmfmac :01:00.0: enabling device ( -> 0002)
[   34.376468] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x02
[   34.855143] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac4356-pcie.clm_blob failed with error -2
[   34.855147] brcmfmac: brcmf_c_process_clm_blob: no clm_blob
available(err=-2), device may have limited channels available
[   34.857029] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
wl0:
Jun  4 2017 16:50:07 version 7.35.101.6 (r702795) FWID 01-5e8eb735
[   34.938854] brcmfmac :01:00.0 wlp1s0: renamed from wlan0
[   37.086420] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[   37.086431] brcmfmac: brcmf_cfg80211_add_iface: add iface
p2p-dev-wlp1s0 type 10 failed: err=-52

[root@localhost ~]# strings /lib/firmware/brcm/brcmfmac4356-pcie.bin |
tail -n 1
4356a2-roml/pcie-ag-msgbuf-splitrx-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wl11u-mfp-tdls-amsdutx-sarctrl-proxd-hs20sta-rcc-wepso-ndoe-linkstat-gscan-hchk-logtrace-roamexp-rmon


Version: 7.35.101.6 (r702795) CRC: 4f3f65c5 Date: Sun 2017-06-04
16:51:38 PDT Ucode Ver: 963.316 FWID: 01-5e8eb735

It would be good if we can silence these errors, or maybe at a
minimum lower their log-level from error to warning?


I had a look at it and it seems to be a difference in firmware api
that we need to support in the driver. Need to do a bit more digging,
but it seems an actual issue. You could silence it for now, but I
prefer to wait for the fix.


Ok, what is the ETA of a fix for this?


Actually went back to an old log you sent and noticed:

[   15.714569] brcmfmac: brcmf_attach Enter
[   15.714756] brcmfmac: brcmf_fweh_register event handler registered
for PSM_WATCHDOG
[   15.714757] brcmfmac: brcmf_proto_attach Enter
[   15.716598] brcmfmac: brcmf_bus_started
[   15.716603] brcmfmac: brcmf_add_if Enter, bsscfgidx=0, ifidx=0
[   15.716604] brcmfmac: brcmf_add_if allocate netdev interface
[   15.716622] brcmfmac: brcmf_add_if   pid:2a, if:wlan%d
(00:00:00:00:00:00) created ===
[   15.716624] brcmfmac: brcmf_bus_change_state 0 -> 1
[   15.717841] brcmfmac: brcmf_fil_iovar_data_get ifidx=0,
name=cur_etheraddr, len=6
[   15.717843] brcmutil: data
[   15.717847] : 44 2c 05 9e c9 02   D,

So mac address of the device is 44:2c:05:9e:c9. However, further down
I see:

[   17.819113] brcmfmac: brcmf_netdev_set_mac_address Enter, bsscfgidx=0
[   17.819122] brcmfmac: brcmf_fil_iovar_data_set ifidx=0,
name=cur_etheraddr, len=6
[   17.819127] brcmutil: data
[   17.819135] : aa 3e 81 77 bc 40   .>.w.@
[   17.819864] brcmfmac: brcmf_netdev_set_mac_address updated to
aa:3e:81:77:bc:40

So the mac address in a local admin variant.


Right, this is likely NetworkManager randomizing the mac for privacy
reasons.


Now our firmware has a requirement for the p2p-dev interface that it
should be different from the mac address of the primary interface, ie.
wlp1s0 in this log. In brcmfmac we try to do that by setting the local
admin bit, but... as it is already set we end up using the same mac
address hence the -EBUSY.


Ah, that is good to know, so how can we fix this? Can userspace specify a
different mac-address when it asks for the p2p-dev intf to be created? Or
should we do something about this in the kernel?


So this is the patch I tested. Maybe you can verify it works for you as 
well.


Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c

index 2ee5413..ddbb386 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -462,8 +462,8 @@ static int brcmf_p2p_set_firmware(struct brcmf_if 
*ifp, u8 *p2p_mac)

  * @dev_addr: optional device address.
  *
  * P2P needs mac addresses for P2P 

Re: [PATCH] ath9k: break out of irq handler after 5 jiffies

[Ben Greear]

On 02/26/2018 02:08 PM, Arend van Spriel wrote:

On 2/26/2018 10:39 PM, Ben Greear wrote:

On 02/07/2018 07:39 AM, Ben Greear wrote:



On 02/07/2018 02:55 AM, Johannes Berg wrote:

On Wed, 2018-02-07 at 10:16 +0100, Felix Fietkau wrote:

On 2018-02-07 00:05, gree...@candelatech.com wrote:

From: Ben Greear 

In case where the system is sluggish, we should probably break out
early.  Maybe this will fix issues where the OS thinks the IRQ handler
is not responding and disables the IRQ because 'nobody cared'

Signed-off-by: Ben Greear 


5 jiffies as a hardcoded value is a bad idea, since it produces
different behavior based on CONFIG_HZ.


I figured that was a benefit since it would run shorter duration on
systems with
a faster HZ clock.



Also, err, NAPI? Or is something else is going on here?


I don't really know, but part of my test was running traffic while
creating
1200 stations, so likely there were lots of higher-level lock
contention that
slowed down sending pkts up the stack.

I got a bunch of errors about IRQs being ignored because nobody
cared.  I noticed
that the ath9k loop could handle up to 500 or so frames, and that
seemed like too
many for my particular test case.

Once I put in this patch, I did not see the 'nobody cared' error again.

There could easily be a better fix.  If you all want me to use a fixed
time instead
of HZ, then please suggest a value.  I was testing with HZ of 1000, btw.


Hello,

I don't mind changing this patch, but I could use some guidance as to what
values you all want me to use.

Should I use a millisecond based clock instead of jiffies?

What time duration do you want if 5 Jiffies (or 5ms) is not desired?


Hi Ben,

Instead of using some time unit you could consider breaking out after handing 
'x' number of frames and make 'x' configurable through debugfs.


I don't see why you would care about number of pkts...it is just a proxy for 
time, right?

So, in that case, then using jiffies (or some other fast timer) seems the most 
useful.

Thanks,
Ben



Regards,
Arend




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

Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

[Arend van Spriel]

On 2/26/2018 11:06 PM, Brian Norris wrote:

Hi,

On Fri, Feb 23, 2018 at 2:51 AM, Johannes Berg
 wrote:

On Fri, 2018-02-23 at 11:39 +0100, Arend van Spriel wrote:


Well, that depends on the eye of the beholder I guess. From user-space
perspective it is asynchronous regardless. A write access to the coredump
sysfs file eventually results in a uevent when the devcoredump entry is
created, ie. after driver has made a dev_coredump API call. Whether the
driver does that synchronously or asynchronously is irrelevant as far as
user-space is concerned.


Is it really? The driver infrastructure seems to guarantee that the
entirety of a driver's ->coredump() will complete before returning from
the write. So it might be reasonable for some user to assume (based on
implementation details, e.g., of brcmfmac) that the devcoredump will be
ready by the time the write() syscall returns, absent documentation that
says otherwise. But then, that's not how mwifiex works right now, so
they might be surprised if they switch drivers.


I can see how you might want to have that kind of behaviour, but you'd
have to jump through some hoops to see if the coredump you saw is
actually the right one - you probably want an asynchronous coredump
"collector" and then wait for it to show up (with some reasonable
timeout) on the actual filesystem, not on sysfs?

Otherwise you have to trawl sysfs for the right coredump I guess, which
too is possible.


It's not that I want that interface. It's that I want the *lack* of
such an interface to be guaranteed in the documentation. When the
questions like "where? when?" are not answered in the doc, users are
totally allowed to speculate ;) Perhaps the "where" can be deferred to
other documentation (which should probably exist someday), but the
"when" should be listed as "eventually; or not at all; listen for a
uevent."


Agree. Will extend/improve the ABI documentation.


You are right. Clearly I did not reach the end my learning curve here. I
assumed referring to the existing dev_coredump facility was sufficient, but
maybe it is worth a patch to be more explicit and mention the uevent
behavior. Also dev_coredump facility may be disabled upon which the trigger
will have no effect in sysfs. In the kernel the data passed by the driver is
simply freed by dev_coredump facility.


Is there any other documentation for the coredump feature? I don't
really see much.


Any other than the code itself you mean? I am not sure. Maybe Johannes
knows.


There isn't really, it originally was really simple, but then somebody
(Kees perhaps?) requested a way to turn it off forever for security or
privacy concerns and it became more complicated.


Then I don't think when adding a new sysfs ABI, we should be deferring
to "existing dev_coredump facility [documentation]" (which doesn't
exist). And just a few words about the user-facing interface would be
nice for the documentation. There previously wasn't any official way
to trigger a dump from userspace -- only from random debugfs files, I
think, or from unspecified device failures.


That was my main motivation to have this. The debugfs method did not 
feel quite right as there is no kconfig dependency between dev_coredump 
and debugfs. Now I discussed with Johannes about adding code into the 
dev_coredump facility, but that seemed to add a lot of complexity. So I 
looking into the device driver core and found it to be the simpler solution.



static ssize_t coredump_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t count)
{
 device_lock(dev);
 if (dev->driver->coredump)
 dev->driver->coredump(dev);
 device_unlock(dev);

 return count;
}
static DEVICE_ATTR_WO(coredump);

Is that a bug or a feature?


Yeah. Let's call it a bug. Just not sure what to go for. Return the
error or change coredump callback to void return type.


I'm not sure it matters all that much - the underlying devcoredump
calls all have no return value (void), and given the above complexities
with the ability to turn off devcoredumping entirely you cannot rely on
this return value to tell you if a dump was created or not, at least
not without much more infrastructure work.


Then perhaps it makes sense to remove the return code before you
create users of it.


Yup. Will sent out a patch for that as well.

Thanks,
Arend

Re: [PATCH] ath9k: break out of irq handler after 5 jiffies

[Arend van Spriel]

On 2/26/2018 10:39 PM, Ben Greear wrote:

On 02/07/2018 07:39 AM, Ben Greear wrote:



On 02/07/2018 02:55 AM, Johannes Berg wrote:

On Wed, 2018-02-07 at 10:16 +0100, Felix Fietkau wrote:

On 2018-02-07 00:05, gree...@candelatech.com wrote:

From: Ben Greear 

In case where the system is sluggish, we should probably break out
early.  Maybe this will fix issues where the OS thinks the IRQ handler
is not responding and disables the IRQ because 'nobody cared'

Signed-off-by: Ben Greear 


5 jiffies as a hardcoded value is a bad idea, since it produces
different behavior based on CONFIG_HZ.


I figured that was a benefit since it would run shorter duration on
systems with
a faster HZ clock.



Also, err, NAPI? Or is something else is going on here?


I don't really know, but part of my test was running traffic while
creating
1200 stations, so likely there were lots of higher-level lock
contention that
slowed down sending pkts up the stack.

I got a bunch of errors about IRQs being ignored because nobody
cared.  I noticed
that the ath9k loop could handle up to 500 or so frames, and that
seemed like too
many for my particular test case.

Once I put in this patch, I did not see the 'nobody cared' error again.

There could easily be a better fix.  If you all want me to use a fixed
time instead
of HZ, then please suggest a value.  I was testing with HZ of 1000, btw.


Hello,

I don't mind changing this patch, but I could use some guidance as to what
values you all want me to use.

Should I use a millisecond based clock instead of jiffies?

What time duration do you want if 5 Jiffies (or 5ms) is not desired?


Hi Ben,

Instead of using some time unit you could consider breaking out after 
handing 'x' number of frames and make 'x' configurable through debugfs.


Regards,
Arend

Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

[Brian Norris]

Hi,

On Fri, Feb 23, 2018 at 2:51 AM, Johannes Berg
 wrote:
> On Fri, 2018-02-23 at 11:39 +0100, Arend van Spriel wrote:
>
> > > > Well, that depends on the eye of the beholder I guess. From user-space
> > > > perspective it is asynchronous regardless. A write access to the 
> > > > coredump
> > > > sysfs file eventually results in a uevent when the devcoredump entry is
> > > > created, ie. after driver has made a dev_coredump API call. Whether the
> > > > driver does that synchronously or asynchronously is irrelevant as far as
> > > > user-space is concerned.
> > >
> > > Is it really? The driver infrastructure seems to guarantee that the
> > > entirety of a driver's ->coredump() will complete before returning from
> > > the write. So it might be reasonable for some user to assume (based on
> > > implementation details, e.g., of brcmfmac) that the devcoredump will be
> > > ready by the time the write() syscall returns, absent documentation that
> > > says otherwise. But then, that's not how mwifiex works right now, so
> > > they might be surprised if they switch drivers.
>
> I can see how you might want to have that kind of behaviour, but you'd
> have to jump through some hoops to see if the coredump you saw is
> actually the right one - you probably want an asynchronous coredump
> "collector" and then wait for it to show up (with some reasonable
> timeout) on the actual filesystem, not on sysfs?
>
> Otherwise you have to trawl sysfs for the right coredump I guess, which
> too is possible.

It's not that I want that interface. It's that I want the *lack* of
such an interface to be guaranteed in the documentation. When the
questions like "where? when?" are not answered in the doc, users are
totally allowed to speculate ;) Perhaps the "where" can be deferred to
other documentation (which should probably exist someday), but the
"when" should be listed as "eventually; or not at all; listen for a
uevent."

> > > > You are right. Clearly I did not reach the end my learning curve here. I
> > > > assumed referring to the existing dev_coredump facility was sufficient, 
> > > > but
> > > > maybe it is worth a patch to be more explicit and mention the uevent
> > > > behavior. Also dev_coredump facility may be disabled upon which the 
> > > > trigger
> > > > will have no effect in sysfs. In the kernel the data passed by the 
> > > > driver is
> > > > simply freed by dev_coredump facility.
> > >
> > > Is there any other documentation for the coredump feature? I don't
> > > really see much.
> >
> > Any other than the code itself you mean? I am not sure. Maybe Johannes
> > knows.
>
> There isn't really, it originally was really simple, but then somebody
> (Kees perhaps?) requested a way to turn it off forever for security or
> privacy concerns and it became more complicated.

Then I don't think when adding a new sysfs ABI, we should be deferring
to "existing dev_coredump facility [documentation]" (which doesn't
exist). And just a few words about the user-facing interface would be
nice for the documentation. There previously wasn't any official way
to trigger a dump from userspace -- only from random debugfs files, I
think, or from unspecified device failures.

> > > static ssize_t coredump_store(struct device *dev, struct device_attribute 
> > > *attr,
> > > const char *buf, size_t count)
> > > {
> > > device_lock(dev);
> > > if (dev->driver->coredump)
> > > dev->driver->coredump(dev);
> > > device_unlock(dev);
> > >
> > > return count;
> > > }
> > > static DEVICE_ATTR_WO(coredump);
> > >
> > > Is that a bug or a feature?
> >
> > Yeah. Let's call it a bug. Just not sure what to go for. Return the
> > error or change coredump callback to void return type.
>
> I'm not sure it matters all that much - the underlying devcoredump
> calls all have no return value (void), and given the above complexities
> with the ability to turn off devcoredumping entirely you cannot rely on
> this return value to tell you if a dump was created or not, at least
> not without much more infrastructure work.

Then perhaps it makes sense to remove the return code before you
create users of it.

Brian

Re: [PATCH] ath9k: introduce endian_check module parameter

[Bas Vermeulen]

On 26-2-2018 18:42, Dan Williams wrote:

On Mon, 2018-02-26 at 17:44 +0100, Bas Vermeulen wrote:

On 26-02-18 17:32, Larry Finger wrote:

On 02/26/2018 04:07 AM, Bas Vermeulen wrote:

On 26-02-18 10:54, Kalle Valo wrote:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on
my
PowerMac G5 without allowing the driver to byte-swap the
eeprom.

Introduce a module parameter endian_check to allow this to
happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
   drivers/net/wireless/ath/ath9k/init.c | 6 +-
   1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
   module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
   MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
+static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int,
0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness
compatibility");
   #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
   int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc
*sc)
   ether_addr_copy(common->macaddr, mac);
   ah->ah_flags &= ~AH_USE_EEPROM;
-ah->ah_flags |= AH_NO_EEP_SWAP;
+if (!ath9k_endian_check)
+ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any
automatic
way
to detect/try this? But on the other hand I guess this isn't a
common
problem as nobody has reported this before?

There is an automatic way to detect this, but that is disabled by
the
AH_NO_EEP_SWAP flag.
The platform initialisation does not set this flag if the
endian_check member of pdata is set
to true, but there is no way to not set this when using a device
tree. I used a module
parameter instead of a device tree variable because I don't know
of a
way to modify the
device tree my PowerMac boots with.

Shouldn't you be able to set ath9k_endian_check inside #ifdef
__BIG_ENDIAN ... #endif in the initialization? I think that would
achieve the same functionality without requiring the user to set a
module parameter.

I could have done that, but didn't want to change the default
behaviour.
This patch keeps the
current behaviour on all platforms if the module parameter is not
set. I
don't have the means
to test mips and other platforms this could be used on. I don't mind
having to set a module
parameter, I mind not being able to change the behaviour

Still, module parameters are an awful user experience because you need
to know that they exist, what they do, and whether you need it or not.
It doesn't just work.

Is there no way to autodetect the endian-ness of the firmware itself,
and if the known machine endian-ness isn't the same then swap?  This
seems like a solvable problem.


The problem is already solved, but the solution is disabled by the 
AH_NO_EEP_SWAP
flag set in both initialization functions. See ath9k/init.c and 
ath9k/eeprom.c.
My patch just disables the flag when a module parameter is set, which 
enables the solution.


I can disable the flag without a problem, but that might have unintended 
side effects
on some platforms. If the consensus is that's the better solution I can 
prepare a patch,

but that would have to come from someone more knowledgeable than me.

Bas Vermeulen

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [PATCH] ath9k: break out of irq handler after 5 jiffies

[Ben Greear]

On 02/07/2018 07:39 AM, Ben Greear wrote:



On 02/07/2018 02:55 AM, Johannes Berg wrote:

On Wed, 2018-02-07 at 10:16 +0100, Felix Fietkau wrote:

On 2018-02-07 00:05, gree...@candelatech.com wrote:

From: Ben Greear 

In case where the system is sluggish, we should probably break out
early.  Maybe this will fix issues where the OS thinks the IRQ handler
is not responding and disables the IRQ because 'nobody cared'

Signed-off-by: Ben Greear 


5 jiffies as a hardcoded value is a bad idea, since it produces
different behavior based on CONFIG_HZ.


I figured that was a benefit since it would run shorter duration on systems with
a faster HZ clock.



Also, err, NAPI? Or is something else is going on here?


I don't really know, but part of my test was running traffic while creating
1200 stations, so likely there were lots of higher-level lock contention that
slowed down sending pkts up the stack.

I got a bunch of errors about IRQs being ignored because nobody cared.  I 
noticed
that the ath9k loop could handle up to 500 or so frames, and that seemed like 
too
many for my particular test case.

Once I put in this patch, I did not see the 'nobody cared' error again.

There could easily be a better fix.  If you all want me to use a fixed time 
instead
of HZ, then please suggest a value.  I was testing with HZ of 1000, btw.


Hello,

I don't mind changing this patch, but I could use some guidance as to what
values you all want me to use.

Should I use a millisecond based clock instead of jiffies?

What time duration do you want if 5 Jiffies (or 5ms) is not desired?

Thanks,
Ben


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

Re: [PATCH v2] ath10k: debugfs support to get final TPC stats for 10.4 variants

[Joshua Zhao]

as you said:
The existing tpc_stats debugfs file provides the dump which is
minimum of target power and regulatory domain.
cat /sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats

I’m curious what’s exact difference w/ this new addition:
Export the final Transmit Power Control (TPC) value, which is
the minimum of control power and existing TPC value to user space via
a new debugfs file "tpc_stats_final" to help with debugging.

Can you clarify or give examples on the difference?

Thanks!

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

[Adrian Chadd]

hi,

so it's going to eventually leak? Can we fix the firmware bug too? :)


-a


On 26 February 2018 at 09:06,   wrote:
> Hi,
>
>
>> Can you share exactly which resource the firmware ran out of?  It would
>> seem to
>> be a FW bug if it is leaking, so maybe it can be fixed as well...
>>
>
> Firmware have total user_id = 528 (512 clients + 16 VAPs). Each user_id is
> allocated to peer when Firmware receive the WMI_PEER_ASSOC_CMDID request
> from host driver. Firmware free the user_id in peer delete operation.
>
> Regards,
> Karthikeyan P.
>
> ___
> ath10k mailing list
> ath...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

[Peter Oh]

This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159.

When Ath10k is in AP mode and an unassociated STA sends a VHT action frame
(Operating Mode Notification for the NSS change) periodically to AP this causes
ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID during
NSS update. Over the time (with a certain client it can happen within 15 mins
when there are over 500 of these VHT action frames) continuous calls of
WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust.

Can you include the FW assert message in this commit?

Thanks,
Peter

[PATCH v2 4/8] wil6210: add support for adding and removing virtual interfaces

[Maya Erez]

From: Lior David 

Add generic support in cfg80211 operations add_virtual_intf
and del_virtual_intf for adding/removing VIFs of any
interface type, and fix change_virtual_intf to allow changing
the interface type of a VIF. Previously these operations
only worked for the P2P_DEVICE interface which is not a real
VIF(it is management-only and shares radio with the main
interface).
Currently the interface combination is validated, the VIF is
added/removed in the firmware and the appropriate net/wireless
device is also added/removed.
Added minimal support for proper interface up/down and module
unload but most operations still work only on the main interface.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 209 
 drivers/net/wireless/ath/wil6210/main.c |  34 +
 drivers/net/wireless/ath/wil6210/netdev.c   | 163 +++---
 drivers/net/wireless/ath/wil6210/pcie_bus.c |  39 +-
 drivers/net/wireless/ath/wil6210/wil6210.h  |  21 ++-
 drivers/net/wireless/ath/wil6210/wmi.c  | 111 ++-
 6 files changed, 518 insertions(+), 59 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 2fd4af8..ce20ee4 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "wil6210.h"
 #include "wmi.h"
 #include "fw.h"
@@ -418,6 +419,53 @@ static void wil_cfg80211_stop_p2p_device(struct wiphy 
*wiphy,
mutex_unlock(>mutex);
 }
 
+static int wil_cfg80211_validate_add_iface(struct wil6210_priv *wil,
+  enum nl80211_iftype new_type)
+{
+   int i;
+   struct wireless_dev *wdev;
+   struct iface_combination_params params = {
+   .num_different_channels = 1,
+   };
+
+   for (i = 0; i < wil->max_vifs; i++) {
+   if (wil->vifs[i]) {
+   wdev = vif_to_wdev(wil->vifs[i]);
+   params.iftype_num[wdev->iftype]++;
+   }
+   }
+   params.iftype_num[new_type]++;
+   return cfg80211_check_combinations(wil->wiphy, );
+}
+
+static int wil_cfg80211_validate_change_iface(struct wil6210_priv *wil,
+ struct wil6210_vif *vif,
+ enum nl80211_iftype new_type)
+{
+   int i, ret = 0;
+   struct wireless_dev *wdev;
+   struct iface_combination_params params = {
+   .num_different_channels = 1,
+   };
+   bool check_combos = false;
+
+   for (i = 0; i < wil->max_vifs; i++) {
+   struct wil6210_vif *vif_pos = wil->vifs[i];
+
+   if (vif_pos && vif != vif_pos) {
+   wdev = vif_to_wdev(vif_pos);
+   params.iftype_num[wdev->iftype]++;
+   check_combos = true;
+   }
+   }
+
+   if (check_combos) {
+   params.iftype_num[new_type]++;
+   ret = cfg80211_check_combinations(wil->wiphy, );
+   }
+   return ret;
+}
+
 static struct wireless_dev *
 wil_cfg80211_add_iface(struct wiphy *wiphy, const char *name,
   unsigned char name_assign_type,
@@ -425,53 +473,136 @@ static void wil_cfg80211_stop_p2p_device(struct wiphy 
*wiphy,
   struct vif_params *params)
 {
struct wil6210_priv *wil = wiphy_to_wil(wiphy);
-   struct net_device *ndev = wil->main_ndev;
+   struct net_device *ndev_main = wil->main_ndev, *ndev;
struct wil6210_vif *vif;
-   struct wireless_dev *p2p_wdev;
+   struct wireless_dev *p2p_wdev, *wdev;
+   int rc;
 
-   wil_dbg_misc(wil, "add_iface\n");
+   wil_dbg_misc(wil, "add_iface, type %d\n", type);
 
-   if (type != NL80211_IFTYPE_P2P_DEVICE) {
-   wil_err(wil, "unsupported iftype %d\n", type);
-   return ERR_PTR(-EINVAL);
+   /* P2P device is not a real virtual interface, it is a management-only
+* interface that shares the main interface.
+* Skip concurrency checks here.
+*/
+   if (type == NL80211_IFTYPE_P2P_DEVICE) {
+   if (wil->p2p_wdev) {
+   wil_err(wil, "P2P_DEVICE interface already created\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   vif = kzalloc(sizeof(*vif), GFP_KERNEL);
+   if (!vif)
+   return ERR_PTR(-ENOMEM);
+
+   p2p_wdev = vif_to_wdev(vif);
+   p2p_wdev->iftype = type;
+   p2p_wdev->wiphy = wiphy;
+   /* use our primary ethernet address */
+   ether_addr_copy(p2p_wdev->address, ndev_main->perm_addr);
+
+   wil->p2p_wdev = p2p_wdev;
+
+  

[PATCH v2 2/8] wil6210: support concurrency record in FW file

[Maya Erez]

From: Lior David 

New FW which supports multiple virtual interfaces, reports
its allowed interface combinations using a special comment
record in the FW file. The format of the interface combinations
is similar to the kernel wiphy->iface_combinations.
When parsing FW file during module initialization, also parse
and validate the concurrency record, and initialize
wiphy->n_iface_combinations and wiphy->iface_combinations
accordingly.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 69 +
 drivers/net/wireless/ath/wil6210/fw.h   | 38 +++-
 drivers/net/wireless/ath/wil6210/fw_inc.c   | 52 --
 drivers/net/wireless/ath/wil6210/wil6210.h  |  4 ++
 4 files changed, 158 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index eeed85c..c959f15 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -20,6 +20,7 @@
 #include 
 #include "wil6210.h"
 #include "wmi.h"
+#include "fw.h"
 
 #define WIL_MAX_ROC_DURATION_MS 5000
 
@@ -1896,6 +1897,71 @@ static void wil_wiphy_init(struct wiphy *wiphy)
 #endif
 }
 
+int wil_cfg80211_iface_combinations_from_fw(
+   struct wil6210_priv *wil, const struct wil_fw_record_concurrency *conc)
+{
+   struct wiphy *wiphy = wil_to_wiphy(wil);
+   u32 total_limits = 0;
+   u16 n_combos;
+   const struct wil_fw_concurrency_combo *combo;
+   const struct wil_fw_concurrency_limit *limit;
+   struct ieee80211_iface_combination *iface_combinations;
+   struct ieee80211_iface_limit *iface_limit;
+   int i, j;
+
+   if (wiphy->iface_combinations) {
+   wil_dbg_misc(wil, "iface_combinations already set, skipping\n");
+   return 0;
+   }
+
+   combo = conc->combos;
+   n_combos = le16_to_cpu(conc->n_combos);
+   for (i = 0; i < n_combos; i++) {
+   total_limits += combo->n_limits;
+   limit = combo->limits + combo->n_limits;
+   combo = (struct wil_fw_concurrency_combo *)limit;
+   }
+
+   iface_combinations =
+   kzalloc(n_combos * sizeof(struct ieee80211_iface_combination) +
+   total_limits * sizeof(struct ieee80211_iface_limit),
+   GFP_KERNEL);
+   if (!iface_combinations)
+   return -ENOMEM;
+   iface_limit = (struct ieee80211_iface_limit *)(iface_combinations +
+  n_combos);
+   combo = conc->combos;
+   for (i = 0; i < n_combos; i++) {
+   iface_combinations[i].max_interfaces = combo->max_interfaces;
+   iface_combinations[i].num_different_channels =
+   combo->n_diff_channels;
+   iface_combinations[i].beacon_int_infra_match =
+   combo->same_bi;
+   iface_combinations[i].n_limits = combo->n_limits;
+   wil_dbg_misc(wil,
+"iface_combination %d: max_if %d, num_ch %d, 
bi_match %d\n",
+i, iface_combinations[i].max_interfaces,
+iface_combinations[i].num_different_channels,
+iface_combinations[i].beacon_int_infra_match);
+   limit = combo->limits;
+   for (j = 0; j < combo->n_limits; j++) {
+   iface_limit[j].max = le16_to_cpu(limit[j].max);
+   iface_limit[j].types = le16_to_cpu(limit[j].types);
+   wil_dbg_misc(wil,
+"limit %d: max %d types 0x%x\n", j,
+iface_limit[j].max, iface_limit[j].types);
+   }
+   iface_combinations[i].limits = iface_limit;
+   iface_limit += combo->n_limits;
+   limit += combo->n_limits;
+   combo = (struct wil_fw_concurrency_combo *)limit;
+   }
+
+   wiphy->n_iface_combinations = n_combos;
+   wiphy->iface_combinations = iface_combinations;
+   return 0;
+}
+
 struct wil6210_priv *wil_cfg80211_init(struct device *dev)
 {
struct wiphy *wiphy;
@@ -1934,6 +2000,9 @@ void wil_cfg80211_deinit(struct wil6210_priv *wil)
if (!wiphy)
return;
 
+   kfree(wiphy->iface_combinations);
+   wiphy->iface_combinations = NULL;
+
wiphy_free(wiphy);
/* do not access wil6210_priv after returning from here */
 }
diff --git a/drivers/net/wireless/ath/wil6210/fw.h 
b/drivers/net/wireless/ath/wil6210/fw.h
index 2c7b24f..3e7a280 100644
--- a/drivers/net/wireless/ath/wil6210/fw.h
+++ b/drivers/net/wireless/ath/wil6210/fw.h
@@ -14,6 +14,8 @@
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  * OR IN 

[PATCH v2 6/8] wil6210: rename p2p_wdev_mutex to vif_mutex

[Maya Erez]

From: Lior David 

As more support is added for multiple VIFs, there is a need
to protect the wil6210_vif structure from access while it is
deleted (mainly from del_virtual_intf operation).
Instead of adding another mutex, use p2p_wdev_mutex and rename
it to vif_mutex to reflect the added role. Its existing roles
are similar so it extends nicely (for example it protects the
scan_request member which is also a member of wil6210_vif).

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 22 +--
 drivers/net/wireless/ath/wil6210/main.c | 16 +++---
 drivers/net/wireless/ath/wil6210/p2p.c  | 34 ++---
 drivers/net/wireless/ath/wil6210/wil6210.h  |  2 +-
 drivers/net/wireless/ath/wil6210/wmi.c  |  8 +++
 5 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index a3ad3f4..4afb38f 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -412,10 +412,10 @@ static void wil_cfg80211_stop_p2p_device(struct wiphy 
*wiphy,
 
wil_dbg_misc(wil, "stop_p2p_device: entered\n");
mutex_lock(>mutex);
-   mutex_lock(>p2p_wdev_mutex);
+   mutex_lock(>vif_mutex);
wil_p2p_stop_radio_operations(wil);
wil->p2p_dev_started = 0;
-   mutex_unlock(>p2p_wdev_mutex);
+   mutex_unlock(>vif_mutex);
mutex_unlock(>mutex);
 }
 
@@ -706,14 +706,14 @@ static int wil_cfg80211_scan(struct wiphy *wiphy,
 
mutex_lock(>mutex);
 
-   mutex_lock(>p2p_wdev_mutex);
+   mutex_lock(>vif_mutex);
if (vif->scan_request || vif->p2p.discovery_started) {
wil_err(wil, "Already scanning\n");
-   mutex_unlock(>p2p_wdev_mutex);
+   mutex_unlock(>vif_mutex);
rc = -EAGAIN;
goto out;
}
-   mutex_unlock(>p2p_wdev_mutex);
+   mutex_unlock(>vif_mutex);
 
if (wdev->iftype == NL80211_IFTYPE_P2P_DEVICE) {
if (!wil->p2p_dev_started) {
@@ -825,7 +825,7 @@ static void wil_cfg80211_abort_scan(struct wiphy *wiphy,
wil_dbg_misc(wil, "wdev=0x%p iftype=%d\n", wdev, wdev->iftype);
 
mutex_lock(>mutex);
-   mutex_lock(>p2p_wdev_mutex);
+   mutex_lock(>vif_mutex);
 
if (!vif->scan_request)
goto out;
@@ -841,7 +841,7 @@ static void wil_cfg80211_abort_scan(struct wiphy *wiphy,
wil_abort_scan(vif, true);
 
 out:
-   mutex_unlock(>p2p_wdev_mutex);
+   mutex_unlock(>vif_mutex);
mutex_unlock(>mutex);
 }
 
@@ -1944,10 +1944,10 @@ static int wil_cfg80211_suspend(struct wiphy *wiphy,
wil_dbg_pm(wil, "suspending\n");
 
mutex_lock(>mutex);
-   mutex_lock(>p2p_wdev_mutex);
+   mutex_lock(>vif_mutex);
wil_p2p_stop_radio_operations(wil);
wil_abort_scan(ndev_to_vif(wil->main_ndev), true);
-   mutex_unlock(>p2p_wdev_mutex);
+   mutex_unlock(>vif_mutex);
mutex_unlock(>mutex);
 
 out:
@@ -2236,11 +2236,11 @@ void wil_p2p_wdev_free(struct wil6210_priv *wil)
struct wireless_dev *p2p_wdev;
struct wil6210_vif *vif;
 
-   mutex_lock(>p2p_wdev_mutex);
+   mutex_lock(>vif_mutex);
p2p_wdev = wil->p2p_wdev;
wil->p2p_wdev = NULL;
wil->radio_wdev = wil->main_ndev->ieee80211_ptr;
-   mutex_unlock(>p2p_wdev_mutex);
+   mutex_unlock(>vif_mutex);
if (p2p_wdev) {
cfg80211_unregister_wdev(p2p_wdev);
vif = wdev_to_vif(wil, p2p_wdev);
diff --git a/drivers/net/wireless/ath/wil6210/main.c 
b/drivers/net/wireless/ath/wil6210/main.c
index 5aeaf9b..9a2a866 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -536,8 +536,8 @@ int wil_priv_init(struct wil6210_priv *wil)
spin_lock_init(>vring_tx_data[i].lock);
 
mutex_init(>mutex);
+   mutex_init(>vif_mutex);
mutex_init(>wmi_mutex);
-   mutex_init(>p2p_wdev_mutex);
mutex_init(>halp.lock);
 
init_completion(>wmi_ready);
@@ -1066,21 +1066,21 @@ void wil_abort_scan(struct wil6210_vif *vif, bool sync)
.aborted = true,
};
 
-   lockdep_assert_held(>p2p_wdev_mutex);
+   lockdep_assert_held(>vif_mutex);
 
if (!vif->scan_request)
return;
 
wil_dbg_misc(wil, "Abort scan_request 0x%p\n", vif->scan_request);
del_timer_sync(>scan_timer);
-   mutex_unlock(>p2p_wdev_mutex);
+   mutex_unlock(>vif_mutex);
rc = wmi_abort_scan(vif);
if (!rc && sync)
wait_event_interruptible_timeout(wil->wq, !vif->scan_request,
 msecs_to_jiffies(
 

[PATCH v2 1/8] wil6210: add wil6210_vif structure for per-VIF data

[Maya Erez]

From: Lior David 

For supporting multiple virtual interfaces in the future,
introduce a wil6210_vif structure which will hold per-VIF
data. Change the module initialization so wil6210_vif will
be part of net_device structure, and wireless_dev will be
embedded inside the wil6210_vif structure. This will allow
us to find the appropriate wil6210_vif structure when we
only have access to wireless_dev or net_device.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 57 ++
 drivers/net/wireless/ath/wil6210/netdev.c   | 93 ++---
 drivers/net/wireless/ath/wil6210/wil6210.h  | 22 +--
 3 files changed, 107 insertions(+), 65 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index b799a53..eeed85c 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2012-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -418,6 +419,7 @@ static void wil_cfg80211_stop_p2p_device(struct wiphy 
*wiphy,
 {
struct wil6210_priv *wil = wiphy_to_wil(wiphy);
struct net_device *ndev = wil_to_ndev(wil);
+   struct wil6210_vif *vif;
struct wireless_dev *p2p_wdev;
 
wil_dbg_misc(wil, "add_iface\n");
@@ -432,10 +434,11 @@ static void wil_cfg80211_stop_p2p_device(struct wiphy 
*wiphy,
return ERR_PTR(-EINVAL);
}
 
-   p2p_wdev = kzalloc(sizeof(*p2p_wdev), GFP_KERNEL);
-   if (!p2p_wdev)
+   vif = kzalloc(sizeof(*vif), GFP_KERNEL);
+   if (!vif)
return ERR_PTR(-ENOMEM);
 
+   p2p_wdev = >wdev;
p2p_wdev->iftype = type;
p2p_wdev->wiphy = wiphy;
/* use our primary ethernet address */
@@ -1893,51 +1896,52 @@ static void wil_wiphy_init(struct wiphy *wiphy)
 #endif
 }
 
-struct wireless_dev *wil_cfg80211_init(struct device *dev)
+struct wil6210_priv *wil_cfg80211_init(struct device *dev)
 {
-   int rc = 0;
-   struct wireless_dev *wdev;
+   struct wiphy *wiphy;
+   struct wil6210_priv *wil;
+   struct ieee80211_channel *ch;
 
dev_dbg(dev, "%s()\n", __func__);
 
-   wdev = kzalloc(sizeof(*wdev), GFP_KERNEL);
-   if (!wdev)
+   /* Note: the wireless_dev structure is no longer allocated here.
+* Instead, it is allocated as part of the net_device structure
+* for main interface and each VIF.
+*/
+   wiphy = wiphy_new(_cfg80211_ops, sizeof(struct wil6210_priv));
+   if (!wiphy)
return ERR_PTR(-ENOMEM);
 
-   wdev->wiphy = wiphy_new(_cfg80211_ops,
-   sizeof(struct wil6210_priv));
-   if (!wdev->wiphy) {
-   rc = -ENOMEM;
-   goto out;
-   }
-
-   set_wiphy_dev(wdev->wiphy, dev);
-   wil_wiphy_init(wdev->wiphy);
+   set_wiphy_dev(wiphy, dev);
+   wil_wiphy_init(wiphy);
 
-   return wdev;
+   wil = wiphy_to_wil(wiphy);
+   wil->wiphy = wiphy;
 
-out:
-   kfree(wdev);
+   /* default monitor channel */
+   ch = wiphy->bands[NL80211_BAND_60GHZ]->channels;
+   cfg80211_chandef_create(>monitor_chandef, ch, NL80211_CHAN_NO_HT);
 
-   return ERR_PTR(rc);
+   return wil;
 }
 
-void wil_wdev_free(struct wil6210_priv *wil)
+void wil_cfg80211_deinit(struct wil6210_priv *wil)
 {
-   struct wireless_dev *wdev = wil_to_wdev(wil);
+   struct wiphy *wiphy = wil_to_wiphy(wil);
 
dev_dbg(wil_to_dev(wil), "%s()\n", __func__);
 
-   if (!wdev)
+   if (!wiphy)
return;
 
-   wiphy_free(wdev->wiphy);
-   kfree(wdev);
+   wiphy_free(wiphy);
+   /* do not access wil6210_priv after returning from here */
 }
 
 void wil_p2p_wdev_free(struct wil6210_priv *wil)
 {
struct wireless_dev *p2p_wdev;
+   struct wil6210_vif *vif;
 
mutex_lock(>p2p_wdev_mutex);
p2p_wdev = wil->p2p_wdev;
@@ -1946,7 +1950,8 @@ void wil_p2p_wdev_free(struct wil6210_priv *wil)
mutex_unlock(>p2p_wdev_mutex);
if (p2p_wdev) {
cfg80211_unregister_wdev(p2p_wdev);
-   kfree(p2p_wdev);
+   vif = wdev_to_vif(p2p_wdev);
+   kfree(vif);
}
 }
 
diff --git a/drivers/net/wireless/ath/wil6210/netdev.c 
b/drivers/net/wireless/ath/wil6210/netdev.c
index 7ba4e0a..648f636 100644
--- a/drivers/net/wireless/ath/wil6210/netdev.c
+++ b/drivers/net/wireless/ath/wil6210/netdev.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2012-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, 

[PATCH v2 7/8] wil6210: multiple VIFs support for connections and data path

[Maya Erez]

From: Lior David 

Track the connection status per-VIF.
The data path code is also updated to support multiple VIFs.
This includes RX and TX VRING management, NAPI poll loops,
RX reordering and related code.
Power management code used to check if the main interface
is up or based on connection state of the main interface,
adapt this code to take all VIFs into account.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c   |  32 +++
 drivers/net/wireless/ath/wil6210/debugfs.c|  20 +++-
 drivers/net/wireless/ath/wil6210/interrupt.c  |   2 +-
 drivers/net/wireless/ath/wil6210/main.c   |  78 ++-
 drivers/net/wireless/ath/wil6210/netdev.c |  46 -
 drivers/net/wireless/ath/wil6210/pcie_bus.c   |  18 ++--
 drivers/net/wireless/ath/wil6210/pm.c | 131 ++
 drivers/net/wireless/ath/wil6210/rx_reorder.c |  36 ---
 drivers/net/wireless/ath/wil6210/txrx.c   |  79 ++--
 drivers/net/wireless/ath/wil6210/txrx.h   |  22 -
 drivers/net/wireless/ath/wil6210/wil6210.h|  25 +++--
 drivers/net/wireless/ath/wil6210/wmi.c|   9 +-
 12 files changed, 347 insertions(+), 151 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 4afb38f..cdbb393 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -319,7 +319,7 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
sinfo->tx_packets = stats->tx_packets;
sinfo->tx_failed = stats->tx_errors;
 
-   if (test_bit(wil_status_fwconnected, wil->status)) {
+   if (test_bit(wil_vif_fwconnected, vif->status)) {
sinfo->filled |= BIT(NL80211_STA_INFO_SIGNAL);
if (test_bit(WMI_FW_CAPABILITY_RSSI_REPORTING,
 wil->fw_capabilities))
@@ -490,11 +490,10 @@ static int wil_cfg80211_validate_change_iface(struct 
wil6210_priv *wil,
return ERR_PTR(-EINVAL);
}
 
-   vif = kzalloc(sizeof(*vif), GFP_KERNEL);
-   if (!vif)
+   p2p_wdev = kzalloc(sizeof(*p2p_wdev), GFP_KERNEL);
+   if (!p2p_wdev)
return ERR_PTR(-ENOMEM);
 
-   p2p_wdev = vif_to_wdev(vif);
p2p_wdev->iftype = type;
p2p_wdev->wiphy = wiphy;
/* use our primary ethernet address */
@@ -904,8 +903,8 @@ static int wil_cfg80211_connect(struct wiphy *wiphy,
wil_dbg_misc(wil, "connect, mid=%d\n", vif->mid);
wil_print_connect_params(wil, sme);
 
-   if (test_bit(wil_status_fwconnecting, wil->status) ||
-   test_bit(wil_status_fwconnected, wil->status))
+   if (test_bit(wil_vif_fwconnecting, vif->status) ||
+   test_bit(wil_vif_fwconnected, vif->status))
return -EALREADY;
 
if (sme->ie_len > WMI_MAX_IE_LEN) {
@@ -1009,18 +1008,19 @@ static int wil_cfg80211_connect(struct wiphy *wiphy,
ether_addr_copy(conn.bssid, bss->bssid);
ether_addr_copy(conn.dst_mac, bss->bssid);
 
-   set_bit(wil_status_fwconnecting, wil->status);
+   set_bit(wil_vif_fwconnecting, vif->status);
 
rc = wmi_send(wil, WMI_CONNECT_CMDID, vif->mid, , sizeof(conn));
if (rc == 0) {
netif_carrier_on(ndev);
-   wil6210_bus_request(wil, WIL_MAX_BUS_REQUEST_KBPS);
+   if (!wil_has_other_active_ifaces(wil, ndev, false, true))
+   wil6210_bus_request(wil, WIL_MAX_BUS_REQUEST_KBPS);
vif->bss = bss;
/* Connect can take lots of time */
mod_timer(>connect_timer,
  jiffies + msecs_to_jiffies(5000));
} else {
-   clear_bit(wil_status_fwconnecting, wil->status);
+   clear_bit(wil_vif_fwconnecting, vif->status);
}
 
  out:
@@ -1040,8 +1040,8 @@ static int wil_cfg80211_disconnect(struct wiphy *wiphy,
wil_dbg_misc(wil, "disconnect: reason=%d, mid=%d\n",
 reason_code, vif->mid);
 
-   if (!(test_bit(wil_status_fwconnecting, wil->status) ||
- test_bit(wil_status_fwconnected, wil->status))) {
+   if (!(test_bit(wil_vif_fwconnecting, vif->status) ||
+ test_bit(wil_vif_fwconnected, vif->status))) {
wil_err(wil, "Disconnect was called while disconnected\n");
return 0;
}
@@ -1946,7 +1946,7 @@ static int wil_cfg80211_suspend(struct wiphy *wiphy,
mutex_lock(>mutex);
mutex_lock(>vif_mutex);
wil_p2p_stop_radio_operations(wil);
-   wil_abort_scan(ndev_to_vif(wil->main_ndev), true);
+   wil_abort_scan_all_vifs(wil, true);
mutex_unlock(>vif_mutex);
mutex_unlock(>mutex);
 
@@ -2234,7 +2234,6 @@ void 

[PATCH v2 5/8] wil6210: multiple VIFs support for start/stop AP

[Maya Erez]

From: Lior David 

Add support for multiple VIFs in the cfg80211 operations start_ap,
stop_ap and change_beacon. This change allows starting multiple APs
using virtual interfaces.
The data path and most other operations are still working only
on the main interface.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 49 +++--
 drivers/net/wireless/ath/wil6210/main.c | 14 -
 drivers/net/wireless/ath/wil6210/netdev.c   | 22 +++--
 drivers/net/wireless/ath/wil6210/pcie_bus.c |  2 +-
 drivers/net/wireless/ath/wil6210/wil6210.h  |  9 +++---
 drivers/net/wireless/ath/wil6210/wmi.c  |  8 +
 6 files changed, 71 insertions(+), 33 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index ce20ee4..a3ad3f4 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -544,8 +544,9 @@ static int wil_cfg80211_validate_change_iface(struct 
wil6210_priv *wil,
return ERR_PTR(rc);
 }
 
-int wil_vif_prepare_stop(struct wil6210_priv *wil, struct wil6210_vif *vif)
+int wil_vif_prepare_stop(struct wil6210_vif *vif)
 {
+   struct wil6210_priv *wil = vif_to_wil(vif);
struct wireless_dev *wdev = vif_to_wdev(vif);
struct net_device *ndev;
int rc;
@@ -561,6 +562,7 @@ int wil_vif_prepare_stop(struct wil6210_priv *wil, struct 
wil6210_vif *vif)
 rc);
/* continue */
}
+   wil_bcast_fini(vif);
netif_carrier_off(ndev);
}
 
@@ -593,7 +595,7 @@ static int wil_cfg80211_del_iface(struct wiphy *wiphy,
return -EINVAL;
}
 
-   rc = wil_vif_prepare_stop(wil, vif);
+   rc = wil_vif_prepare_stop(vif);
if (rc)
goto out;
 
@@ -614,6 +616,7 @@ static int wil_cfg80211_change_iface(struct wiphy *wiphy,
struct wil6210_vif *vif = ndev_to_vif(ndev);
struct wireless_dev *wdev = vif_to_wdev(vif);
int rc;
+   bool fw_reset = false;
 
wil_dbg_misc(wil, "change_iface: type=%d\n", type);
 
@@ -628,7 +631,7 @@ static int wil_cfg80211_change_iface(struct wiphy *wiphy,
/* do not reset FW when there are active VIFs,
 * because it can cause significant disruption
 */
-   if (!wil_has_other_up_ifaces(wil, ndev) &&
+   if (!wil_has_other_active_ifaces(wil, ndev, true, false) &&
netif_running(ndev) && !wil_is_recovery_blocked(wil)) {
wil_dbg_misc(wil, "interface is up. resetting...\n");
mutex_lock(>mutex);
@@ -638,6 +641,7 @@ static int wil_cfg80211_change_iface(struct wiphy *wiphy,
 
if (rc)
return rc;
+   fw_reset = true;
}
 
switch (type) {
@@ -654,8 +658,9 @@ static int wil_cfg80211_change_iface(struct wiphy *wiphy,
return -EOPNOTSUPP;
}
 
-   if (vif->mid != 0 && wil_has_up_ifaces(wil)) {
-   wil_vif_prepare_stop(wil, vif);
+   if (vif->mid != 0 && wil_has_active_ifaces(wil, true, false)) {
+   if (!fw_reset)
+   wil_vif_prepare_stop(vif);
rc = wmi_port_delete(wil, vif->mid);
if (rc)
return rc;
@@ -1530,10 +1535,12 @@ static int _wil_cfg80211_start_ap(struct wiphy *wiphy,
 
mutex_lock(>mutex);
 
-   __wil_down(wil);
-   rc = __wil_up(wil);
-   if (rc)
-   goto out;
+   if (!wil_has_other_active_ifaces(wil, ndev, true, false)) {
+   __wil_down(wil);
+   rc = __wil_up(wil);
+   if (rc)
+   goto out;
+   }
 
rc = wmi_set_ssid(vif, ssid_len, ssid);
if (rc)
@@ -1549,7 +1556,8 @@ static int _wil_cfg80211_start_ap(struct wiphy *wiphy,
vif->pbss = pbss;
 
netif_carrier_on(ndev);
-   wil6210_bus_request(wil, WIL_MAX_BUS_REQUEST_KBPS);
+   if (!wil_has_other_active_ifaces(wil, ndev, false, true))
+   wil6210_bus_request(wil, WIL_MAX_BUS_REQUEST_KBPS);
 
rc = wmi_pcp_start(vif, bi, wmi_nettype, chan, hidden_ssid, is_go);
if (rc)
@@ -1565,7 +1573,8 @@ static int _wil_cfg80211_start_ap(struct wiphy *wiphy,
wmi_pcp_stop(vif);
 err_pcp_start:
netif_carrier_off(ndev);
-   wil6210_bus_request(wil, WIL_DEFAULT_BUS_REQUEST_KBPS);
+   if (!wil_has_other_active_ifaces(wil, ndev, false, true))
+   wil6210_bus_request(wil, WIL_DEFAULT_BUS_REQUEST_KBPS);
 out:
mutex_unlock(>mutex);
return rc;
@@ -1670,20 +1679,26 @@ static int wil_cfg80211_stop_ap(struct wiphy *wiphy,
 {
struct wil6210_priv *wil = wiphy_to_wil(wiphy);
struct wil6210_vif *vif = ndev_to_vif(ndev);
+   bool 

[PATCH v2 8/8] wil6210: add debugfs 'mids' file

[Maya Erez]

From: Lior David 

Added a new debugfs file 'mids' to print the list of
virtual interfaces by MAC ID (MID). Allows mapping
between the internal MID used by FW and the actual
network interface used by the VIF. This is needed by
debugging tools.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/debugfs.c | 37 ++
 1 file changed, 37 insertions(+)

diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 93a99a1..8c90b31 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1495,6 +1495,42 @@ static int wil_sta_seq_open(struct inode *inode, struct 
file *file)
.llseek = seq_lseek,
 };
 
+static int wil_mids_debugfs_show(struct seq_file *s, void *data)
+{
+   struct wil6210_priv *wil = s->private;
+   struct wil6210_vif *vif;
+   struct net_device *ndev;
+   int i;
+
+   mutex_lock(>vif_mutex);
+   for (i = 0; i < wil->max_vifs; i++) {
+   vif = wil->vifs[i];
+
+   if (vif) {
+   ndev = vif_to_ndev(vif);
+   seq_printf(s, "[%d] %pM %s\n", i, ndev->dev_addr,
+  ndev->name);
+   } else {
+   seq_printf(s, "[%d] unused\n", i);
+   }
+   }
+   mutex_unlock(>vif_mutex);
+
+   return 0;
+}
+
+static int wil_mids_seq_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, wil_mids_debugfs_show, inode->i_private);
+}
+
+static const struct file_operations fops_mids = {
+   .open   = wil_mids_seq_open,
+   .release= single_release,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+};
+
 static ssize_t wil_read_file_led_cfg(struct file *file, char __user *user_buf,
 size_t count, loff_t *ppos)
 {
@@ -1749,6 +1785,7 @@ static void wil6210_debugfs_init_blobs(struct 
wil6210_priv *wil,
{"mbox",0444,   _mbox},
{"vrings",  0444,   _vring},
{"stations", 0444,  _sta},
+   {"mids",0444,   _mids},
{"desc",0444,   _txdesc},
{"bf",  0444,   _bf},
{"mem_val", 0644,   _memread},
-- 
1.9.1

[PATCH v2 0/8] wil6210 patches

[Maya Erez]

Changes from v1:
Rebase patches

Support for multiple virtual interfaces (MultiVIF)

This series of patches add MultiVIF support to the wil6210 driver.
It makes it possible to start multiple interfaces where each interface
is an independent WIFI entity such as station, AP and so on.

Each virtual interface (VIF) is mapped so a separate network interface
(such as wlan0, wlan1, …) so it can also be treated separately for
routing and other network operations.

MultiVIF requires support in the FW. The FW will report whether it
supports MultiVIF and the allowed concurrency combinations. The driver
will export this information to user space and enforce it so it will
only be possible to start a combination of VIFs supported by the FW.

Initially our FW only supports multiple access points (APs) so it is
possible for example to have a secure and guest network. The code was
only validated with this scenario and we will improve the support for
other concurrency combinations with future patches, as it becomes
available in the FW.

Lior David (8):
  wil6210: add wil6210_vif structure for per-VIF data
  wil6210: support concurrency record in FW file
  wil6210: infrastructure for multiple virtual interfaces
  wil6210: add support for adding and removing virtual interfaces
  wil6210: multiple VIFs support for start/stop AP
  wil6210: rename p2p_wdev_mutex to vif_mutex
  wil6210: multiple VIFs support for connections and data path
  wil6210: add debugfs 'mids' file

 drivers/net/wireless/ath/wil6210/cfg80211.c   | 741 ++
 drivers/net/wireless/ath/wil6210/debug.c  |   9 +-
 drivers/net/wireless/ath/wil6210/debugfs.c| 117 +++-
 drivers/net/wireless/ath/wil6210/ethtool.c|   4 +-
 drivers/net/wireless/ath/wil6210/fw.h |  38 +-
 drivers/net/wireless/ath/wil6210/fw_inc.c |  52 +-
 drivers/net/wireless/ath/wil6210/interrupt.c  |   8 +-
 drivers/net/wireless/ath/wil6210/main.c   | 331 +++-
 drivers/net/wireless/ath/wil6210/netdev.c | 382 ++---
 drivers/net/wireless/ath/wil6210/p2p.c| 175 +++---
 drivers/net/wireless/ath/wil6210/pcie_bus.c   |  57 +-
 drivers/net/wireless/ath/wil6210/pm.c | 132 +++--
 drivers/net/wireless/ath/wil6210/pmc.c|   8 +-
 drivers/net/wireless/ath/wil6210/rx_reorder.c |  45 +-
 drivers/net/wireless/ath/wil6210/txrx.c   | 177 +++---
 drivers/net/wireless/ath/wil6210/txrx.h   |  22 +-
 drivers/net/wireless/ath/wil6210/wil6210.h| 217 +---
 drivers/net/wireless/ath/wil6210/wmi.c| 460 +++-
 18 files changed, 2081 insertions(+), 894 deletions(-)

-- 
1.9.1

Re: [PATCH] ath9k: introduce endian_check module parameter

[Dan Williams]

On Mon, 2018-02-26 at 17:44 +0100, Bas Vermeulen wrote:
> On 26-02-18 17:32, Larry Finger wrote:
> > On 02/26/2018 04:07 AM, Bas Vermeulen wrote:
> > > On 26-02-18 10:54, Kalle Valo wrote:
> > > > Bas Vermeulen  writes:
> > > > 
> > > > > A random (little endian eeprom'd) ar9278 card didn't work on
> > > > > my
> > > > > PowerMac G5 without allowing the driver to byte-swap the
> > > > > eeprom.
> > > > > 
> > > > > Introduce a module parameter endian_check to allow this to
> > > > > happen,
> > > > > and the PCIe card to function correctly on BE powerpc.
> > > > > 
> > > > > Signed-off-by: Bas Vermeulen 
> > > > > ---
> > > > >   drivers/net/wireless/ath/ath9k/init.c | 6 +-
> > > > >   1 file changed, 5 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/net/wireless/ath/ath9k/init.c 
> > > > > b/drivers/net/wireless/ath/ath9k/init.c
> > > > > index fa58a32227f5..421039dc060a 100644
> > > > > --- a/drivers/net/wireless/ath/ath9k/init.c
> > > > > +++ b/drivers/net/wireless/ath/ath9k/init.c
> > > > > @@ -67,6 +67,9 @@ static int ath9k_ps_enable;
> > > > >   module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
> > > > >   MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
> > > > > +static int ath9k_endian_check;
> > > > > +module_param_named(endian_check, ath9k_endian_check, int,
> > > > > 0444);
> > > > > +MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness 
> > > > > compatibility");
> > > > >   #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
> > > > >   int ath9k_use_chanctx;
> > > > > @@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc
> > > > > *sc)
> > > > >   ether_addr_copy(common->macaddr, mac);
> > > > >   ah->ah_flags &= ~AH_USE_EEPROM;
> > > > > -ah->ah_flags |= AH_NO_EEP_SWAP;
> > > > > +if (!ath9k_endian_check)
> > > > > +ah->ah_flags |= AH_NO_EEP_SWAP;
> > > > 
> > > > A bit annoying to have a module parameter, isn't there any
> > > > automatic 
> > > > way
> > > > to detect/try this? But on the other hand I guess this isn't a
> > > > common
> > > > problem as nobody has reported this before?
> > > 
> > > There is an automatic way to detect this, but that is disabled by
> > > the 
> > > AH_NO_EEP_SWAP flag.
> > > The platform initialisation does not set this flag if the 
> > > endian_check member of pdata is set
> > > to true, but there is no way to not set this when using a device 
> > > tree. I used a module
> > > parameter instead of a device tree variable because I don't know
> > > of a 
> > > way to modify the
> > > device tree my PowerMac boots with.
> > 
> > Shouldn't you be able to set ath9k_endian_check inside #ifdef 
> > __BIG_ENDIAN ... #endif in the initialization? I think that would 
> > achieve the same functionality without requiring the user to set a 
> > module parameter.
> 
> I could have done that, but didn't want to change the default
> behaviour. 
> This patch keeps the
> current behaviour on all platforms if the module parameter is not
> set. I 
> don't have the means
> to test mips and other platforms this could be used on. I don't mind 
> having to set a module
> parameter, I mind not being able to change the behaviour

Still, module parameters are an awful user experience because you need
to know that they exist, what they do, and whether you need it or not. 
It doesn't just work.

Is there no way to autodetect the endian-ness of the firmware itself,
and if the known machine endian-ness isn't the same then swap?  This
seems like a solvable problem.

Dan

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

[periyasa]

Hi,


Can you share exactly which resource the firmware ran out of?  It would 
seem to

be a FW bug if it is leaking, so maybe it can be fixed as well...



Firmware have total user_id = 528 (512 clients + 16 VAPs). Each user_id 
is allocated to peer when Firmware receive the WMI_PEER_ASSOC_CMDID 
request from host driver. Firmware free the user_id in peer delete 
operation.


Regards,
Karthikeyan P.

Re: [PATCH] ath9k: introduce endian_check module parameter

[Bas Vermeulen]

On 26-02-18 17:32, Larry Finger wrote:

On 02/26/2018 04:07 AM, Bas Vermeulen wrote:

On 26-02-18 10:54, Kalle Valo wrote:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c

index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
+static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness 
compatibility");

  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
  int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
  ether_addr_copy(common->macaddr, mac);
  ah->ah_flags &= ~AH_USE_EEPROM;
-    ah->ah_flags |= AH_NO_EEP_SWAP;
+    if (!ath9k_endian_check)
+    ah->ah_flags |= AH_NO_EEP_SWAP;
A bit annoying to have a module parameter, isn't there any automatic 
way

to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?
There is an automatic way to detect this, but that is disabled by the 
AH_NO_EEP_SWAP flag.
The platform initialisation does not set this flag if the 
endian_check member of pdata is set
to true, but there is no way to not set this when using a device 
tree. I used a module
parameter instead of a device tree variable because I don't know of a 
way to modify the

device tree my PowerMac boots with.


Shouldn't you be able to set ath9k_endian_check inside #ifdef 
__BIG_ENDIAN ... #endif in the initialization? I think that would 
achieve the same functionality without requiring the user to set a 
module parameter.


I could have done that, but didn't want to change the default behaviour. 
This patch keeps the
current behaviour on all platforms if the module parameter is not set. I 
don't have the means
to test mips and other platforms this could be used on. I don't mind 
having to set a module

parameter, I mind not being able to change the behaviour.

Bas Vermeulen

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[PATCH 7/8] staging: wilc1000: fix line over 80 char in wilc_wlan_cfg_set()

[Ajay Singh]

Fix 'line over 80 character' issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 223bf8b..acf7591 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -1230,6 +1230,8 @@ int wilc_wlan_cfg_set(struct wilc_vif *vif, int start, 
u16 wid, u8 *buffer,
wilc->cfg_frame_offset = offset;
 
if (commit) {
+   unsigned long tmp = msecs_to_jiffies(CFG_PKTS_TIMEOUT);
+
netdev_dbg(vif->ndev,
   "[WILC]PACKET Commit with sequence number %d\n",
   wilc->cfg_seq_no);
@@ -1239,8 +1241,7 @@ int wilc_wlan_cfg_set(struct wilc_vif *vif, int start, 
u16 wid, u8 *buffer,
if (wilc_wlan_cfg_commit(vif, WILC_CFG_SET, drv_handler))
ret_size = 0;
 
-   if (!wait_for_completion_timeout(>cfg_event,
-
msecs_to_jiffies(CFG_PKTS_TIMEOUT))) {
+   if (!wait_for_completion_timeout(>cfg_event, tmp)) {
netdev_dbg(vif->ndev, "Set Timed Out\n");
ret_size = 0;
}
-- 
2.7.4

[PATCH 2/8] staging: wilc1000: rename label _end_ in wilc_wlan_handle_txq()

[Ajay Singh]

Rename label name starting with '_' to follow as per linux coding style.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 37d6d87..5422359 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -648,7 +648,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 
*txq_count)
} while (!wilc->quit);
 
if (!ret)
-   goto _end_;
+   goto out_release_bus;
 
timeout = 200;
do {
@@ -695,11 +695,11 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 
*txq_count)
} while (1);
 
if (!ret)
-   goto _end_;
+   goto out_release_bus;
 
if (entries == 0) {
ret = WILC_TX_ERR_NO_BUF;
-   goto _end_;
+   goto out_release_bus;
}
 
release_bus(wilc, RELEASE_ALLOW_SLEEP);
@@ -756,11 +756,11 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 
*txq_count)
 
ret = func->hif_clear_int_ext(wilc, ENABLE_TX_VMM);
if (!ret)
-   goto _end_;
+   goto out_release_bus;
 
ret = func->hif_block_tx_ext(wilc, 0, txb, offset);
 
-_end_:
+out_release_bus:
release_bus(wilc, RELEASE_ALLOW_SLEEP);
 
 out:
-- 
2.7.4

[PATCH 8/8] staging: wilc1000: fix open parenthesis mismatch issue in wilc_wlan_cfg_set()

[Ajay Singh]

Fix 'Alignment should match open parenthesis' issue found by
checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index acf7591..971e61d2 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -1273,13 +1273,14 @@ int wilc_wlan_cfg_get(struct wilc_vif *vif, int start, 
u16 wid, int commit,
wilc->cfg_frame_offset = offset;
 
if (commit) {
+   unsigned long tmp = msecs_to_jiffies(CFG_PKTS_TIMEOUT);
+
wilc->cfg_frame_in_use = 1;
 
if (wilc_wlan_cfg_commit(vif, WILC_CFG_QUERY, drv_handler))
ret_size = 0;
 
-   if (!wait_for_completion_timeout(>cfg_event,
-   msecs_to_jiffies(CFG_PKTS_TIMEOUT))) {
+   if (!wait_for_completion_timeout(>cfg_event, tmp)) {
netdev_dbg(vif->ndev, "Get Timed Out\n");
ret_size = 0;
}
-- 
2.7.4

[PATCH 5/8] staging: wilc1000: rename WILC_WFI_mgmt_rx() to avoid camelCase

[Ajay Singh]

Fix "Avoid camelCase" issue found by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/linux_wlan.c | 2 +-
 drivers/staging/wilc1000/wilc_wfi_netdevice.h | 2 +-
 drivers/staging/wilc1000/wilc_wlan.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index cf746f2..fe19bf3 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1149,7 +1149,7 @@ void wilc_frmw_to_linux(struct wilc *wilc, u8 *buff, u32 
size, u32 pkt_offset)
}
 }
 
-void WILC_WFI_mgmt_rx(struct wilc *wilc, u8 *buff, u32 size)
+void wilc_wfi_mgmt_rx(struct wilc *wilc, u8 *buff, u32 size)
 {
int i = 0;
struct wilc_vif *vif;
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h 
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index 3337fb2..d62c4f1 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -230,7 +230,7 @@ void wilc_netdev_cleanup(struct wilc *wilc);
 int wilc_netdev_init(struct wilc **wilc, struct device *dev, int io_type,
 int gpio, const struct wilc_hif_func *ops);
 void wilc1000_wlan_deinit(struct net_device *dev);
-void WILC_WFI_mgmt_rx(struct wilc *wilc, u8 *buff, u32 size);
+void wilc_wfi_mgmt_rx(struct wilc *wilc, u8 *buff, u32 size);
 int wilc_wlan_get_firmware(struct net_device *dev);
 int wilc_wlan_set_bssid(struct net_device *wilc_netdev, u8 *bssid, u8 mode);
 
diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index f762785..74b80ad 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -815,7 +815,7 @@ static void wilc_wlan_handle_rxq(struct wilc *wilc)
IS_MANAGMEMENT_CALLBACK |
IS_MGMT_STATUS_SUCCES);
 
-   WILC_WFI_mgmt_rx(wilc, [offset + 
HOST_HDR_OFFSET], pkt_len);
+   wilc_wfi_mgmt_rx(wilc, [offset + 
HOST_HDR_OFFSET], pkt_len);
} else {
if (!is_cfg_packet) {
if (pkt_len > 0) {
-- 
2.7.4

[PATCH 4/8] staging: wilc1000: move multiple definition of same macro to common header

[Ajay Singh]

Move the same #define from multiple '.c' files to common header file.
Instead of having same macro in different '.c' files, now kept in
common '.h' file.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/linux_mon.c  | 3 ---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 ---
 drivers/staging/wilc1000/wilc_wlan.c  | 4 
 drivers/staging/wilc1000/wilc_wlan.h  | 5 +
 4 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_mon.c 
b/drivers/staging/wilc1000/linux_mon.c
index 91d49c4..bbdfc7a 100644
--- a/drivers/staging/wilc1000/linux_mon.c
+++ b/drivers/staging/wilc1000/linux_mon.c
@@ -40,9 +40,6 @@ static u8 broadcast[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
 
 #define IEEE80211_RADIOTAP_F_TX_RTS0x0004  /* used rts/cts handshake */
 #define IEEE80211_RADIOTAP_F_TX_FAIL   0x0001  /* failed due to excessive*/
-#define IS_MANAGMEMENT 0x100
-#define IS_MANAGMEMENT_CALLBACK0x080
-#define IS_MGMT_STATUS_SUCCES  0x040
 #define GET_PKT_OFFSET(a) (((a) >> 22) & 0x1ff)
 
 void WILC_WFI_monitor_rx(u8 *buff, u32 size)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 621810d..3f78abc 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -85,9 +85,6 @@ static const struct wiphy_wowlan_support wowlan_support = {
 #define TCP_ACK_FILTER_LINK_SPEED_THRESH   54
 #define DEFAULT_LINK_SPEED 72
 
-#define IS_MANAGMEMENT 0x100
-#define IS_MANAGMEMENT_CALLBACK0x080
-#define IS_MGMT_STATUS_SUCCES  0x040
 #define GET_PKT_OFFSET(a) (((a) >> 22) & 0x1ff)
 
 static struct network_info 
last_scanned_shadow[MAX_NUM_SCANNED_NETWORKS_SHADOW];
diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index ee7102d..f762785 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -810,10 +810,6 @@ static void wilc_wlan_handle_rxq(struct wilc *wilc)
if (pkt_len == 0 || tp_len == 0)
break;
 
-   #define IS_MANAGMEMENT  0x100
-   #define IS_MANAGMEMENT_CALLBACK 0x080
-   #define IS_MGMT_STATUS_SUCCES   0x040
-
if (pkt_offset & IS_MANAGMEMENT) {
pkt_offset &= ~(IS_MANAGMEMENT |
IS_MANAGMEMENT_CALLBACK |
diff --git a/drivers/staging/wilc1000/wilc_wlan.h 
b/drivers/staging/wilc1000/wilc_wlan.h
index da71731..fa157a6 100644
--- a/drivers/staging/wilc1000/wilc_wlan.h
+++ b/drivers/staging/wilc1000/wilc_wlan.h
@@ -195,6 +195,11 @@
 #define ENABLE_TX_VMM  (SEL_VMM_TBL0 | EN_VMM)
 /*time for expiring the completion of cfg packets*/
 #define CFG_PKTS_TIMEOUT   2000
+
+#define IS_MANAGMEMENT 0x100
+#define IS_MANAGMEMENT_CALLBACK0x080
+#define IS_MGMT_STATUS_SUCCES  0x040
+
 /
  *
  *  Debug Type
-- 
2.7.4

[PATCH 6/8] staging: wilc1000: fix line over 80 char in wilc_wlan_handle_rxq()

[Ajay Singh]

Fix 'line over 80 character' issue found by checkpatch.pl script.
Refactor wilc_wlan_handle_rxq() code to remove the checkpatch.pl
warnings.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan.c | 46 
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 74b80ad..223bf8b 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -798,6 +798,7 @@ static void wilc_wlan_handle_rxq(struct wilc *wilc)
u32 header;
u32 pkt_len, pkt_offset, tp_len;
int is_cfg_packet;
+   int tmp;
 
memcpy(, [offset], 4);
header = cpu_to_le32(header);
@@ -815,28 +816,31 @@ static void wilc_wlan_handle_rxq(struct wilc *wilc)
IS_MANAGMEMENT_CALLBACK |
IS_MGMT_STATUS_SUCCES);
 
-   wilc_wfi_mgmt_rx(wilc, [offset + 
HOST_HDR_OFFSET], pkt_len);
+   tmp = offset + HOST_HDR_OFFSET;
+   wilc_wfi_mgmt_rx(wilc, [tmp], pkt_len);
+   } else if (!is_cfg_packet) {
+   if (pkt_len > 0) {
+   wilc_frmw_to_linux(wilc,
+  [offset],
+  pkt_len,
+  pkt_offset);
+   }
} else {
-   if (!is_cfg_packet) {
-   if (pkt_len > 0) {
-   wilc_frmw_to_linux(wilc,
-  
[offset],
-  pkt_len,
-  pkt_offset);
-   }
-   } else {
-   struct wilc_cfg_rsp rsp;
-
-   wilc_wlan_cfg_indicate_rx(wilc, 
[pkt_offset + offset], pkt_len, );
-   if (rsp.type == WILC_CFG_RSP) {
-   if (wilc->cfg_seq_no == 
rsp.seq_no)
-   
complete(>cfg_event);
-   } else if (rsp.type == 
WILC_CFG_RSP_STATUS) {
-   wilc_mac_indicate(wilc, 
WILC_MAC_INDICATE_STATUS);
-
-   } else if (rsp.type == 
WILC_CFG_RSP_SCAN) {
-   wilc_mac_indicate(wilc, 
WILC_MAC_INDICATE_SCAN);
-   }
+   struct wilc_cfg_rsp rsp;
+
+   tmp = pkt_offset + offset;
+   wilc_wlan_cfg_indicate_rx(wilc, [tmp],
+ pkt_len, );
+   if (rsp.type == WILC_CFG_RSP) {
+   if (wilc->cfg_seq_no == rsp.seq_no)
+   complete(>cfg_event);
+   } else if (rsp.type == WILC_CFG_RSP_STATUS) {
+   tmp = WILC_MAC_INDICATE_STATUS;
+   wilc_mac_indicate(wilc, tmp);
+
+   } else if (rsp.type == WILC_CFG_RSP_SCAN) {
+   tmp = WILC_MAC_INDICATE_SCAN;
+   wilc_mac_indicate(wilc, tmp);
}
}
offset += tp_len;
-- 
2.7.4

[PATCH 3/8] staging: wilc1000: fix line over 80 char in wilc_wlan_handle_txq()

[Ajay Singh]

Refactor wilc_wlan_handle_txq() to fix 'line over 80 char' issue found
by checkpatch.pl script.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan.c | 76 ++--
 1 file changed, 39 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 5422359..ee7102d 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -707,49 +707,51 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 
*txq_count)
offset = 0;
i = 0;
do {
+   u32 header, buffer_offset;
+   char *bssid;
+
tqe = wilc_wlan_txq_remove_from_head(dev);
-   if (tqe && vmm_table[i] != 0) {
-   u32 header, buffer_offset;
+   if (!tqe)
+   break;
 
-   vmm_table[i] = cpu_to_le32(vmm_table[i]);
-   vmm_sz = (vmm_table[i] & 0x3ff);
-   vmm_sz *= 4;
-   header = (tqe->type << 31) |
-(tqe->buffer_size << 15) |
-vmm_sz;
-   if (tqe->type == WILC_MGMT_PKT)
-   header |= BIT(30);
-   else
-   header &= ~BIT(30);
+   if (vmm_table[i] == 0)
+   break;
 
-   header = cpu_to_le32(header);
-   memcpy([offset], , 4);
-   if (tqe->type == WILC_CFG_PKT) {
-   buffer_offset = ETH_CONFIG_PKT_HDR_OFFSET;
-   } else if (tqe->type == WILC_NET_PKT) {
-   char *bssid = ((struct tx_complete_data 
*)(tqe->priv))->bssid;
-
-   buffer_offset = ETH_ETHERNET_HDR_OFFSET;
-   memcpy([offset + 8], bssid, 6);
-   } else {
-   buffer_offset = HOST_HDR_OFFSET;
-   }
+   vmm_table[i] = cpu_to_le32(vmm_table[i]);
+   vmm_sz = (vmm_table[i] & 0x3ff);
+   vmm_sz *= 4;
+   header = (tqe->type << 31) |
+(tqe->buffer_size << 15) |
+vmm_sz;
+   if (tqe->type == WILC_MGMT_PKT)
+   header |= BIT(30);
+   else
+   header &= ~BIT(30);
 
-   memcpy([offset + buffer_offset],
-  tqe->buffer, tqe->buffer_size);
-   offset += vmm_sz;
-   i++;
-   tqe->status = 1;
-   if (tqe->tx_complete_func)
-   tqe->tx_complete_func(tqe->priv,
- tqe->status);
-   if (tqe->tcp_pending_ack_idx != NOT_TCP_ACK &&
-   tqe->tcp_pending_ack_idx < MAX_PENDING_ACKS)
-   
pending_acks_info[tqe->tcp_pending_ack_idx].txqe = NULL;
-   kfree(tqe);
+   header = cpu_to_le32(header);
+   memcpy([offset], , 4);
+   if (tqe->type == WILC_CFG_PKT) {
+   buffer_offset = ETH_CONFIG_PKT_HDR_OFFSET;
+   } else if (tqe->type == WILC_NET_PKT) {
+   bssid = ((struct tx_complete_data *)(tqe->priv))->bssid;
+
+   buffer_offset = ETH_ETHERNET_HDR_OFFSET;
+   memcpy([offset + 8], bssid, 6);
} else {
-   break;
+   buffer_offset = HOST_HDR_OFFSET;
}
+
+   memcpy([offset + buffer_offset],
+  tqe->buffer, tqe->buffer_size);
+   offset += vmm_sz;
+   i++;
+   tqe->status = 1;
+   if (tqe->tx_complete_func)
+   tqe->tx_complete_func(tqe->priv, tqe->status);
+   if (tqe->tcp_pending_ack_idx != NOT_TCP_ACK &&
+   tqe->tcp_pending_ack_idx < MAX_PENDING_ACKS)
+   pending_acks_info[tqe->tcp_pending_ack_idx].txqe = NULL;
+   kfree(tqe);
} while (--entries);
 
acquire_bus(wilc, ACQUIRE_AND_WAKEUP);
-- 
2.7.4

[PATCH 1/8] staging: wilc1000: remove unnecessary while(0) in wilc_wlan_handle_txq()

[Ajay Singh]

Refactor wilc_wlan_handle_txq() by removing unnecessary while(0)
loop. "Line over 80 char" issues in wilc_wlan_handle_txq() are fix by
reducing extra leading tab.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_wlan.c | 295 +--
 1 file changed, 141 insertions(+), 154 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 1a9ef1a..37d6d87 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -583,200 +583,187 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 
*txq_count)
 
txb = wilc->tx_buffer;
wilc->txq_exit = 0;
+
+   if (wilc->quit)
+   goto out;
+
+   mutex_lock(>txq_add_to_head_cs);
+   wilc_wlan_txq_filter_dup_tcp_ack(dev);
+   tqe = wilc_wlan_txq_get_first(wilc);
+   i = 0;
+   sum = 0;
do {
-   if (wilc->quit)
-   break;
+   if (tqe && (i < (WILC_VMM_TBL_SIZE - 1))) {
+   if (tqe->type == WILC_CFG_PKT)
+   vmm_sz = ETH_CONFIG_PKT_HDR_OFFSET;
 
-   mutex_lock(>txq_add_to_head_cs);
-   wilc_wlan_txq_filter_dup_tcp_ack(dev);
-   tqe = wilc_wlan_txq_get_first(wilc);
-   i = 0;
-   sum = 0;
-   do {
-   if (tqe && (i < (WILC_VMM_TBL_SIZE - 1))) {
-   if (tqe->type == WILC_CFG_PKT)
-   vmm_sz = ETH_CONFIG_PKT_HDR_OFFSET;
+   else if (tqe->type == WILC_NET_PKT)
+   vmm_sz = ETH_ETHERNET_HDR_OFFSET;
 
-   else if (tqe->type == WILC_NET_PKT)
-   vmm_sz = ETH_ETHERNET_HDR_OFFSET;
+   else
+   vmm_sz = HOST_HDR_OFFSET;
 
-   else
-   vmm_sz = HOST_HDR_OFFSET;
+   vmm_sz += tqe->buffer_size;
 
-   vmm_sz += tqe->buffer_size;
+   if (vmm_sz & 0x3)
+   vmm_sz = (vmm_sz + 4) & ~0x3;
 
-   if (vmm_sz & 0x3)
-   vmm_sz = (vmm_sz + 4) & ~0x3;
+   if ((sum + vmm_sz) > LINUX_TX_SIZE)
+   break;
 
-   if ((sum + vmm_sz) > LINUX_TX_SIZE)
-   break;
+   vmm_table[i] = vmm_sz / 4;
+   if (tqe->type == WILC_CFG_PKT)
+   vmm_table[i] |= BIT(10);
+   vmm_table[i] = cpu_to_le32(vmm_table[i]);
 
-   vmm_table[i] = vmm_sz / 4;
-   if (tqe->type == WILC_CFG_PKT)
-   vmm_table[i] |= BIT(10);
-   vmm_table[i] = cpu_to_le32(vmm_table[i]);
+   i++;
+   sum += vmm_sz;
+   tqe = wilc_wlan_txq_get_next(wilc, tqe);
+   } else {
+   break;
+   }
+   } while (1);
 
-   i++;
-   sum += vmm_sz;
-   tqe = wilc_wlan_txq_get_next(wilc, tqe);
-   } else {
-   break;
-   }
-   } while (1);
+   if (i == 0)
+   goto out;
+   vmm_table[i] = 0x0;
 
-   if (i == 0)
+   acquire_bus(wilc, ACQUIRE_AND_WAKEUP);
+   counter = 0;
+   func = wilc->hif_func;
+   do {
+   ret = func->hif_read_reg(wilc, WILC_HOST_TX_CTRL, );
+   if (!ret)
break;
-   vmm_table[i] = 0x0;
 
-   acquire_bus(wilc, ACQUIRE_AND_WAKEUP);
-   counter = 0;
-   func = wilc->hif_func;
-   do {
-   ret = func->hif_read_reg(wilc, WILC_HOST_TX_CTRL, );
-   if (!ret)
-   break;
+   if ((reg & 0x1) == 0)
+   break;
 
-   if ((reg & 0x1) == 0)
-   break;
+   counter++;
+   if (counter > 200) {
+   counter = 0;
+   ret = func->hif_write_reg(wilc, WILC_HOST_TX_CTRL, 0);
+   break;
+   }
+   } while (!wilc->quit);
 
-   counter++;
-   if (counter > 200) {
-   counter = 0;
-   ret = func->hif_write_reg(wilc,
- 

[PATCH 0/8] staging: wilc1000: fix coding style & checkpatch reported issues

[Ajay Singh]

Cleanup patch series to fix checkpatch.pl reported issue & code
modification to follow linux coding style.

Ajay Singh (8):
  staging: wilc1000: remove unnecessary while(0) in
wilc_wlan_handle_txq()
  staging: wilc1000: rename label _end_ in wilc_wlan_handle_txq()
  staging: wilc1000: fix line over 80 char in wilc_wlan_handle_txq()
  staging: wilc1000: move multiple definition of same macro to common
header
  staging: wilc1000: rename WILC_WFI_mgmt_rx() to avoid camelCase
  staging: wilc1000: fix line over 80 char in wilc_wlan_handle_rxq()
  staging: wilc1000: fix line over 80 char in wilc_wlan_cfg_set()
  staging: wilc1000: fix open parenthesis mismatch issue in
wilc_wlan_cfg_set()

 drivers/staging/wilc1000/linux_mon.c  |   3 -
 drivers/staging/wilc1000/linux_wlan.c |   2 +-
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c |   3 -
 drivers/staging/wilc1000/wilc_wfi_netdevice.h |   2 +-
 drivers/staging/wilc1000/wilc_wlan.c  | 361 +++---
 drivers/staging/wilc1000/wilc_wlan.h  |   5 +
 6 files changed, 183 insertions(+), 193 deletions(-)

-- 
2.7.4

Re: [PATCH] ath9k: introduce endian_check module parameter

[Larry Finger]

On 02/26/2018 04:07 AM, Bas Vermeulen wrote:

On 26-02-18 10:54, Kalle Valo wrote:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c

index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
+static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness compatibility");
  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
  int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
  ether_addr_copy(common->macaddr, mac);
  ah->ah_flags &= ~AH_USE_EEPROM;
-    ah->ah_flags |= AH_NO_EEP_SWAP;
+    if (!ath9k_endian_check)
+    ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?
There is an automatic way to detect this, but that is disabled by the 
AH_NO_EEP_SWAP flag.
The platform initialisation does not set this flag if the endian_check member of 
pdata is set
to true, but there is no way to not set this when using a device tree. I used a 
module
parameter instead of a device tree variable because I don't know of a way to 
modify the

device tree my PowerMac boots with.


Shouldn't you be able to set ath9k_endian_check inside #ifdef __BIG_ENDIAN ... 
#endif in the initialization? I think that would achieve the same functionality 
without requiring the user to set a module parameter.


I agree that you want to stay away from the device tree in a PPC computer.

Larry

Re: [1/8] wil6210: add wil6210_vif structure for per-VIF data

[Kalle Valo]

Maya Erez  wrote:

> From: Lior David 
> 
> For supporting multiple virtual interfaces in the future,
> introduce a wil6210_vif structure which will hold per-VIF
> data. Change the module initialization so wil6210_vif will
> be part of net_device structure, and wireless_dev will be
> embedded inside the wil6210_vif structure. This will allow
> us to find the appropriate wil6210_vif structure when we
> only have access to wireless_dev or net_device.
> 
> Signed-off-by: Lior David 
> Signed-off-by: Maya Erez 

Failed to apply:

error: patch failed: drivers/net/wireless/ath/wil6210/cfg80211.c:1606
error: drivers/net/wireless/ath/wil6210/cfg80211.c: patch does not apply
stg import: Diff does not apply cleanly

8 patches set to Changes Requested.

10224163 [1/8] wil6210: add wil6210_vif structure for per-VIF data
10224157 [2/8] wil6210: support concurrency record in FW file
10224159 [3/8] wil6210: infrastructure for multiple virtual interfaces
10224161 [4/8] wil6210: add support for adding and removing virtual interfaces
10224155 [5/8] wil6210: multiple VIFs support for start/stop AP
10224151 [6/8] wil6210: rename p2p_wdev_mutex to vif_mutex
10224153 [7/8] wil6210: multiple VIFs support for connections and data path
10224149 [8/8] wil6210: add debugfs 'mids' file

-- 
https://patchwork.kernel.org/patch/10224163/

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

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

[Ben Greear]

On 02/25/2018 10:16 PM, Karthikeyan Periyasamy wrote:

This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159.

When Ath10k is in AP mode and an unassociated STA sends a VHT action frame
(Operating Mode Notification for the NSS change) periodically to AP this causes
ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID during
NSS update. Over the time (with a certain client it can happen within 15 mins
when there are over 500 of these VHT action frames) continuous calls of
WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust.


Can you share exactly which resource the firmware ran out of?  It would seem to
be a FW bug if it is leaking, so maybe it can be fixed as well...

Thanks,
Ben

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

Re: [PULL] ath10k firmware 20180219

[Kalle Valo]

Sebastian Gottschall  writes:

> on 9984 i see these messages with this firmware from time to time
>
> [272972.950788] ath10k_pci :01:00.0: Unknown eventid: 36925
> [272982.868922] ath10k_pci :01:00.0: Unknown eventid: 36925
> [335550.123780] ath10k_pci :01:00.0: Unknown eventid: 36925
> [335550.156332] ath10k_pci :01:00.0: Unknown eventid: 36925
> [335550.158813] ath10k_pci :01:00.0: Unknown eventid: 36925
> [335550.193144] ath10k_pci :01:00.0: Unknown eventid: 36925
> [365157.869540] ath10k_pci :01:00.0: Unknown eventid: 36925
> [365157.902452] ath10k_pci :01:00.0: Unknown eventid: 36925
>
>
> according to the WMI header this maybe a critical internal error

Thanks for the report. We are working on a fix but just ignore the
warning for now.

-- 
Kalle Valo

Re: [next] wil6210: fix spelling mistake: "preperation"-> "preparation"

[Kalle Valo]

Colin Ian King  wrote:

> Trivial fix to spelling mistake in debug error message text.
> 
> Signed-off-by: Colin Ian King 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

77b83829ebf6 wil6210: fix spelling mistake: "preperation"-> "preparation"

-- 
https://patchwork.kernel.org/patch/10192357/

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

Re: [PATCH] ath9k: introduce endian_check module parameter

[Kalle Valo]

Bas Vermeulen  writes:

> On 26-02-18 10:54, Kalle Valo wrote:
>> Bas Vermeulen  writes:
>>
>>> A random (little endian eeprom'd) ar9278 card didn't work on my
>>> PowerMac G5 without allowing the driver to byte-swap the eeprom.
>>>
>>> Introduce a module parameter endian_check to allow this to happen,
>>> and the PCIe card to function correctly on BE powerpc.
>>>
>>> Signed-off-by: Bas Vermeulen 
>>> ---
>>>   drivers/net/wireless/ath/ath9k/init.c | 6 +-
>>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath9k/init.c 
>>> b/drivers/net/wireless/ath/ath9k/init.c
>>> index fa58a32227f5..421039dc060a 100644
>>> --- a/drivers/net/wireless/ath/ath9k/init.c
>>> +++ b/drivers/net/wireless/ath/ath9k/init.c
>>> @@ -67,6 +67,9 @@ static int ath9k_ps_enable;
>>>   module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
>>>   MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
>>>   +static int ath9k_endian_check;
>>> +module_param_named(endian_check, ath9k_endian_check, int, 0444);
>>> +MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness 
>>> compatibility");
>>>   #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
>>> int ath9k_use_chanctx;
>>> @@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
>>> ether_addr_copy(common->macaddr, mac);
>>> ah->ah_flags &= ~AH_USE_EEPROM;
>>> -   ah->ah_flags |= AH_NO_EEP_SWAP;
>>> +   if (!ath9k_endian_check)
>>> +   ah->ah_flags |= AH_NO_EEP_SWAP;
>> A bit annoying to have a module parameter, isn't there any automatic way
>> to detect/try this? But on the other hand I guess this isn't a common
>> problem as nobody has reported this before?
>
> There is an automatic way to detect this, but that is disabled by the
> AH_NO_EEP_SWAP flag.

Ah, I didn't check the code at all.

> The platform initialisation does not set this flag if the endian_check
> member of pdata is set to true, but there is no way to not set this
> when using a device tree. I used a module parameter instead of a
> device tree variable because I don't know of a way to modify the
> device tree my PowerMac boots with.

Ok, makes sense. A module parameter is not an ideal solution I guess
it's ok in this case.

-- 
Kalle Valo

Re: ath10k: Make ath10k report discarded packets to mac80211

[Kalle Valo]

Ignacio Núñez Hernanz wrote:

> Whenever ath10k firmware discards a packet (HTT_TX_COMPL_STATE_DISCARD
> flag), the skb is freed and mac80211 does not get feedback through
> ieee80211_tx_status().
> 
> Instead, make sure that the IEEE80211_TX_STAT_ACK flag is disabled and
> let the packet go through, like ath9k does.
> 
> Signed-off-by: Ignacio Nunez Hernanz 
> [kv...@codeaurora.org: rebase patch manually]
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

abb374fe8460 ath10k: make ath10k report discarded packets to mac80211

-- 
https://patchwork.kernel.org/patch/9859221/

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

Re: [PATCH] ath9k: introduce endian_check module parameter

[Bas Vermeulen]

On 26-02-18 12:30, Sebastian Gottschall wrote:

Am 26.02.2018 um 11:07 schrieb Bas Vermeulen:

On 26-02-18 10:54, Kalle Valo wrote:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c

index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
  +static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness 
compatibility");

  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
    int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
  ether_addr_copy(common->macaddr, mac);
    ah->ah_flags &= ~AH_USE_EEPROM;
-    ah->ah_flags |= AH_NO_EEP_SWAP;
+    if (!ath9k_endian_check)
+    ah->ah_flags |= AH_NO_EEP_SWAP;
A bit annoying to have a module parameter, isn't there any automatic 
way

to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?
There is an automatic way to detect this, but that is disabled by the 
AH_NO_EEP_SWAP flag.
The platform initialisation does not set this flag if the 
endian_check member of pdata is set
to true, but there is no way to not set this when using a device 
tree. I used a module
parameter instead of a device tree variable because I don't know of a 
way to modify the

device tree my PowerMac boots with.
have you tried to compile it without device tree support? since its 
just a pcie card, i dont think that devicetree is required here

it should run fine without it.


The driver will still set AH_NO_EEP_SWAP regardless, and will still not 
swap the eeprom from
little endian to big endian on big endian machines. See 
drivers/net/wireless/ath/ath9k/eeprom.c:188

and drivers/net/wireless/ath/ath9k/init.c (lines 593 and 645).

The reason I'm talking about device trees here is because I could have 
used a device tree parameter

instead of a module parameter.

Bas Vermeulen

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [PATCH] ath9k: introduce endian_check module parameter

[Bas Vermeulen]

On 26-02-18 12:28, Sebastian Gottschall wrote:

Am 26.02.2018 um 10:54 schrieb Kalle Valo:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c

index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
  +static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness 
compatibility");

  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
    int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
  ether_addr_copy(common->macaddr, mac);
    ah->ah_flags &= ~AH_USE_EEPROM;
-    ah->ah_flags |= AH_NO_EEP_SWAP;
+    if (!ath9k_endian_check)
+    ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?

There is a way by simply checking the eeprom magic on this chipset


I am well aware.

The AH_NO_EEP_SWAP flag disables fixing the eeprom by swapping the data 
read from eeprom.

AH_NO_EEP_SWAP is enabled by default in ath9k_of_init() without this patch.
I am happy if the AH_NO_EEP_SWAP flag is not set, that would fix my 
problem, but changes the
current behaviour. I wanted to keep the current behaviour by default, 
and give me and others a
way to make it work on big endian machines with cards with little endian 
eeproms.


Bas Vermeulen

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

[Arend van Spriel]

On 2/26/2018 12:22 PM, Hans de Goede wrote:

Hi,

On 26-02-18 12:01, Arend van Spriel wrote:

On 2/26/2018 11:29 AM, Hans de Goede wrote:

Hi,

On 26-02-18 11:22, Arend van Spriel wrote:

On 2/25/2018 3:52 PM, Hans de Goede wrote:

Hi,

On 26-05-17 12:57, Hans de Goede wrote:

The firmware responding with -EBUSY when trying to add an extra
virtual-if
is a normal thing, do not print an error for this.

Signed-off-by: Hans de Goede 


I'm now seeing this on another device too, but this time the error
thrown is -EBADE, this seems to be new with recent kernels:


Yup. Before we were passing firmware errors up to user-space, which
was confusing and potentially be misinterpreted. However, looking at
the output below it would have been good to log the firmware error as
well. And staring at it some more I suddenly realize I broke the
feature detection module with this change. Actually only the GSCAN
feature detection.


[root@localhost ~]# dmesg | grep brcmfmac
[   34.265950] usbcore: registered new interface driver brcmfmac
[   34.266059] brcmfmac :01:00.0: enabling device ( -> 0002)
[   34.376468] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x02
[   34.855143] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac4356-pcie.clm_blob failed with error -2
[   34.855147] brcmfmac: brcmf_c_process_clm_blob: no clm_blob
available(err=-2), device may have limited channels available
[   34.857029] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
wl0:
Jun  4 2017 16:50:07 version 7.35.101.6 (r702795) FWID 01-5e8eb735
[   34.938854] brcmfmac :01:00.0 wlp1s0: renamed from wlan0
[   37.086420] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[   37.086431] brcmfmac: brcmf_cfg80211_add_iface: add iface
p2p-dev-wlp1s0 type 10 failed: err=-52

[root@localhost ~]# strings /lib/firmware/brcm/brcmfmac4356-pcie.bin |
tail -n 1
4356a2-roml/pcie-ag-msgbuf-splitrx-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wl11u-mfp-tdls-amsdutx-sarctrl-proxd-hs20sta-rcc-wepso-ndoe-linkstat-gscan-hchk-logtrace-roamexp-rmon


Version: 7.35.101.6 (r702795) CRC: 4f3f65c5 Date: Sun 2017-06-04
16:51:38 PDT Ucode Ver: 963.316 FWID: 01-5e8eb735

It would be good if we can silence these errors, or maybe at a
minimum lower their log-level from error to warning?


I had a look at it and it seems to be a difference in firmware api
that we need to support in the driver. Need to do a bit more digging,
but it seems an actual issue. You could silence it for now, but I
prefer to wait for the fix.


Ok, what is the ETA of a fix for this?


Actually went back to an old log you sent and noticed:

[   15.714569] brcmfmac: brcmf_attach Enter
[   15.714756] brcmfmac: brcmf_fweh_register event handler registered
for PSM_WATCHDOG
[   15.714757] brcmfmac: brcmf_proto_attach Enter
[   15.716598] brcmfmac: brcmf_bus_started
[   15.716603] brcmfmac: brcmf_add_if Enter, bsscfgidx=0, ifidx=0
[   15.716604] brcmfmac: brcmf_add_if allocate netdev interface
[   15.716622] brcmfmac: brcmf_add_if   pid:2a, if:wlan%d
(00:00:00:00:00:00) created ===
[   15.716624] brcmfmac: brcmf_bus_change_state 0 -> 1
[   15.717841] brcmfmac: brcmf_fil_iovar_data_get ifidx=0,
name=cur_etheraddr, len=6
[   15.717843] brcmutil: data
[   15.717847] : 44 2c 05 9e c9 02   D,

So mac address of the device is 44:2c:05:9e:c9. However, further down
I see:

[   17.819113] brcmfmac: brcmf_netdev_set_mac_address Enter, bsscfgidx=0
[   17.819122] brcmfmac: brcmf_fil_iovar_data_set ifidx=0,
name=cur_etheraddr, len=6
[   17.819127] brcmutil: data
[   17.819135] : aa 3e 81 77 bc 40   .>.w.@
[   17.819864] brcmfmac: brcmf_netdev_set_mac_address updated to
aa:3e:81:77:bc:40

So the mac address in a local admin variant.


Right, this is likely NetworkManager randomizing the mac for privacy
reasons.


Now our firmware has a requirement for the p2p-dev interface that it
should be different from the mac address of the primary interface, ie.
wlp1s0 in this log. In brcmfmac we try to do that by setting the local
admin bit, but... as it is already set we end up using the same mac
address hence the -EBUSY.


Ah, that is good to know, so how can we fix this? Can userspace specify a
different mac-address when it asks for the p2p-dev intf to be created? Or
should we do something about this in the kernel?


The nl80211 api allows user-space to provide a mac address for the newly 
created interface since kernel 3.something. So for legacy user-space we 
use the behavior above as fallback. I am testing a patch right now.


Regards,
Arend


Regards,

Hans



[   17.947704] brcmfmac: brcmf_cfg80211_add_iface enter:
p2p-dev-wlp1s0 type 10
[   17.947714] brcmfmac: brcmf_p2p_add_vif adding vif "p2p-dev-wlp1s0"
(type=10, addr=00:00:00:00:00:00)
[   17.947716] brcmfmac: brcmf_alloc_vif allocating virtual interface
(size=3920)
[   17.947720] brcmfmac: 

Re: [PATCH] ath9k: introduce endian_check module parameter

[Sebastian Gottschall]

Am 26.02.2018 um 11:07 schrieb Bas Vermeulen:

On 26-02-18 10:54, Kalle Valo wrote:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c

index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
  +static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness 
compatibility");

  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
    int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
  ether_addr_copy(common->macaddr, mac);
    ah->ah_flags &= ~AH_USE_EEPROM;
-    ah->ah_flags |= AH_NO_EEP_SWAP;
+    if (!ath9k_endian_check)
+    ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?
There is an automatic way to detect this, but that is disabled by the 
AH_NO_EEP_SWAP flag.
The platform initialisation does not set this flag if the endian_check 
member of pdata is set
to true, but there is no way to not set this when using a device tree. 
I used a module
parameter instead of a device tree variable because I don't know of a 
way to modify the

device tree my PowerMac boots with.
have you tried to compile it without device tree support? since its just 
a pcie card, i dont think that devicetree is required here

it should run fine without it.


Bas Vermeulen



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH] ath9k: introduce endian_check module parameter

[Sebastian Gottschall]

Am 26.02.2018 um 10:54 schrieb Kalle Valo:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
  
+static int ath9k_endian_check;

+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness compatibility");
  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
  
  int ath9k_use_chanctx;

@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
ether_addr_copy(common->macaddr, mac);
  
  	ah->ah_flags &= ~AH_USE_EEPROM;

-   ah->ah_flags |= AH_NO_EEP_SWAP;
+   if (!ath9k_endian_check)
+   ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?

There is a way by simply checking the eeprom magic on this chipset




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

[Hans de Goede]

Hi,

On 26-02-18 12:01, Arend van Spriel wrote:

On 2/26/2018 11:29 AM, Hans de Goede wrote:

Hi,

On 26-02-18 11:22, Arend van Spriel wrote:

On 2/25/2018 3:52 PM, Hans de Goede wrote:

Hi,

On 26-05-17 12:57, Hans de Goede wrote:

The firmware responding with -EBUSY when trying to add an extra
virtual-if
is a normal thing, do not print an error for this.

Signed-off-by: Hans de Goede 


I'm now seeing this on another device too, but this time the error
thrown is -EBADE, this seems to be new with recent kernels:


Yup. Before we were passing firmware errors up to user-space, which
was confusing and potentially be misinterpreted. However, looking at
the output below it would have been good to log the firmware error as
well. And staring at it some more I suddenly realize I broke the
feature detection module with this change. Actually only the GSCAN
feature detection.


[root@localhost ~]# dmesg | grep brcmfmac
[   34.265950] usbcore: registered new interface driver brcmfmac
[   34.266059] brcmfmac :01:00.0: enabling device ( -> 0002)
[   34.376468] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x02
[   34.855143] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac4356-pcie.clm_blob failed with error -2
[   34.855147] brcmfmac: brcmf_c_process_clm_blob: no clm_blob
available(err=-2), device may have limited channels available
[   34.857029] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Jun  4 2017 16:50:07 version 7.35.101.6 (r702795) FWID 01-5e8eb735
[   34.938854] brcmfmac :01:00.0 wlp1s0: renamed from wlan0
[   37.086420] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[   37.086431] brcmfmac: brcmf_cfg80211_add_iface: add iface
p2p-dev-wlp1s0 type 10 failed: err=-52

[root@localhost ~]# strings /lib/firmware/brcm/brcmfmac4356-pcie.bin |
tail -n 1
4356a2-roml/pcie-ag-msgbuf-splitrx-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wl11u-mfp-tdls-amsdutx-sarctrl-proxd-hs20sta-rcc-wepso-ndoe-linkstat-gscan-hchk-logtrace-roamexp-rmon

Version: 7.35.101.6 (r702795) CRC: 4f3f65c5 Date: Sun 2017-06-04
16:51:38 PDT Ucode Ver: 963.316 FWID: 01-5e8eb735

It would be good if we can silence these errors, or maybe at a
minimum lower their log-level from error to warning?


I had a look at it and it seems to be a difference in firmware api
that we need to support in the driver. Need to do a bit more digging,
but it seems an actual issue. You could silence it for now, but I
prefer to wait for the fix.


Ok, what is the ETA of a fix for this?


Actually went back to an old log you sent and noticed:

[   15.714569] brcmfmac: brcmf_attach Enter
[   15.714756] brcmfmac: brcmf_fweh_register event handler registered for 
PSM_WATCHDOG
[   15.714757] brcmfmac: brcmf_proto_attach Enter
[   15.716598] brcmfmac: brcmf_bus_started
[   15.716603] brcmfmac: brcmf_add_if Enter, bsscfgidx=0, ifidx=0
[   15.716604] brcmfmac: brcmf_add_if allocate netdev interface
[   15.716622] brcmfmac: brcmf_add_if   pid:2a, if:wlan%d 
(00:00:00:00:00:00) created ===
[   15.716624] brcmfmac: brcmf_bus_change_state 0 -> 1
[   15.717841] brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=cur_etheraddr, 
len=6
[   15.717843] brcmutil: data
[   15.717847] : 44 2c 05 9e c9 02   D,

So mac address of the device is 44:2c:05:9e:c9. However, further down I see:

[   17.819113] brcmfmac: brcmf_netdev_set_mac_address Enter, bsscfgidx=0
[   17.819122] brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=cur_etheraddr, 
len=6
[   17.819127] brcmutil: data
[   17.819135] : aa 3e 81 77 bc 40   .>.w.@
[   17.819864] brcmfmac: brcmf_netdev_set_mac_address updated to 
aa:3e:81:77:bc:40

So the mac address in a local admin variant.


Right, this is likely NetworkManager randomizing the mac for privacy reasons.


Now our firmware has a requirement for the p2p-dev interface that it should be 
different from the mac address of the primary interface, ie. wlp1s0 in this 
log. In brcmfmac we try to do that by setting the local admin bit, but... as it 
is already set we end up using the same mac address hence the -EBUSY.


Ah, that is good to know, so how can we fix this? Can userspace specify a
different mac-address when it asks for the p2p-dev intf to be created? Or
should we do something about this in the kernel?

Regards,

Hans



[   17.947704] brcmfmac: brcmf_cfg80211_add_iface enter: p2p-dev-wlp1s0 type 10
[   17.947714] brcmfmac: brcmf_p2p_add_vif adding vif "p2p-dev-wlp1s0" 
(type=10, addr=00:00:00:00:00:00)
[   17.947716] brcmfmac: brcmf_alloc_vif allocating virtual interface 
(size=3920)
[   17.947720] brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=3, value=1
[   17.948749] brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=apsta, len=4
[   17.948752] brcmutil: data
[   17.948756] : 01 00 00 00   
[   17.949620] brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=2, value=1
[   

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

[Arend van Spriel]

On 2/26/2018 11:29 AM, Hans de Goede wrote:

Hi,

On 26-02-18 11:22, Arend van Spriel wrote:

On 2/25/2018 3:52 PM, Hans de Goede wrote:

Hi,

On 26-05-17 12:57, Hans de Goede wrote:

The firmware responding with -EBUSY when trying to add an extra
virtual-if
is a normal thing, do not print an error for this.

Signed-off-by: Hans de Goede 


I'm now seeing this on another device too, but this time the error
thrown is -EBADE, this seems to be new with recent kernels:


Yup. Before we were passing firmware errors up to user-space, which
was confusing and potentially be misinterpreted. However, looking at
the output below it would have been good to log the firmware error as
well. And staring at it some more I suddenly realize I broke the
feature detection module with this change. Actually only the GSCAN
feature detection.


[root@localhost ~]# dmesg | grep brcmfmac
[   34.265950] usbcore: registered new interface driver brcmfmac
[   34.266059] brcmfmac :01:00.0: enabling device ( -> 0002)
[   34.376468] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x02
[   34.855143] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac4356-pcie.clm_blob failed with error -2
[   34.855147] brcmfmac: brcmf_c_process_clm_blob: no clm_blob
available(err=-2), device may have limited channels available
[   34.857029] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Jun  4 2017 16:50:07 version 7.35.101.6 (r702795) FWID 01-5e8eb735
[   34.938854] brcmfmac :01:00.0 wlp1s0: renamed from wlan0
[   37.086420] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[   37.086431] brcmfmac: brcmf_cfg80211_add_iface: add iface
p2p-dev-wlp1s0 type 10 failed: err=-52

[root@localhost ~]# strings /lib/firmware/brcm/brcmfmac4356-pcie.bin |
tail -n 1
4356a2-roml/pcie-ag-msgbuf-splitrx-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wl11u-mfp-tdls-amsdutx-sarctrl-proxd-hs20sta-rcc-wepso-ndoe-linkstat-gscan-hchk-logtrace-roamexp-rmon

Version: 7.35.101.6 (r702795) CRC: 4f3f65c5 Date: Sun 2017-06-04
16:51:38 PDT Ucode Ver: 963.316 FWID: 01-5e8eb735

It would be good if we can silence these errors, or maybe at a
minimum lower their log-level from error to warning?


I had a look at it and it seems to be a difference in firmware api
that we need to support in the driver. Need to do a bit more digging,
but it seems an actual issue. You could silence it for now, but I
prefer to wait for the fix.


Ok, what is the ETA of a fix for this?


Actually went back to an old log you sent and noticed:

[   15.714569] brcmfmac: brcmf_attach Enter
[   15.714756] brcmfmac: brcmf_fweh_register event handler registered 
for PSM_WATCHDOG

[   15.714757] brcmfmac: brcmf_proto_attach Enter
[   15.716598] brcmfmac: brcmf_bus_started
[   15.716603] brcmfmac: brcmf_add_if Enter, bsscfgidx=0, ifidx=0
[   15.716604] brcmfmac: brcmf_add_if allocate netdev interface
[   15.716622] brcmfmac: brcmf_add_if   pid:2a, if:wlan%d 
(00:00:00:00:00:00) created ===

[   15.716624] brcmfmac: brcmf_bus_change_state 0 -> 1
[   15.717841] brcmfmac: brcmf_fil_iovar_data_get ifidx=0, 
name=cur_etheraddr, len=6

[   15.717843] brcmutil: data
[   15.717847] : 44 2c 05 9e c9 02 
  D,


So mac address of the device is 44:2c:05:9e:c9. However, further down I see:

[   17.819113] brcmfmac: brcmf_netdev_set_mac_address Enter, bsscfgidx=0
[   17.819122] brcmfmac: brcmf_fil_iovar_data_set ifidx=0, 
name=cur_etheraddr, len=6

[   17.819127] brcmutil: data
[   17.819135] : aa 3e 81 77 bc 40 
  .>.w.@
[   17.819864] brcmfmac: brcmf_netdev_set_mac_address updated to 
aa:3e:81:77:bc:40


So the mac address in a local admin variant. Now our firmware has a 
requirement for the p2p-dev interface that it should be different from 
the mac address of the primary interface, ie. wlp1s0 in this log. In 
brcmfmac we try to do that by setting the local admin bit, but... as it 
is already set we end up using the same mac address hence the -EBUSY.


[   17.947704] brcmfmac: brcmf_cfg80211_add_iface enter: p2p-dev-wlp1s0 
type 10
[   17.947714] brcmfmac: brcmf_p2p_add_vif adding vif "p2p-dev-wlp1s0" 
(type=10, addr=00:00:00:00:00:00)
[   17.947716] brcmfmac: brcmf_alloc_vif allocating virtual interface 
(size=3920)

[   17.947720] brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=3, value=1
[   17.948749] brcmfmac: brcmf_fil_iovar_data_set ifidx=0, name=apsta, len=4
[   17.948752] brcmutil: data
[   17.948756] : 01 00 00 00 
  

[   17.949620] brcmfmac: brcmf_fil_cmd_int_set ifidx=0, cmd=2, value=1
[   17.984420] brcmfmac: brcmf_fweh_event_worker event IF (54) ifidx 0 
bsscfg 0 addr aa:3e:81:77:bc:40
[   17.984424] brcmfmac: brcmf_fweh_event_worker   version 2 flags 0 
status 0 reason 0

[   17.984427] brcmutil: event payload, len=5
[   17.984430] : 00 01 00 00 00 
  .
[   17.984433] brcmfmac: brcmf_fweh_handle_if_event 

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

[periyasa]

On 2018-02-26 14:15, Adrian Chadd wrote:

hi!

On 25 February 2018 at 22:16, Karthikeyan Periyasamy
 wrote:

This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159.

When Ath10k is in AP mode and an unassociated STA sends a VHT action 
frame
(Operating Mode Notification for the NSS change) periodically to AP 
this causes
ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID 
during
NSS update. Over the time (with a certain client it can happen within 
15 mins
when there are over 500 of these VHT action frames) continuous calls 
of

WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust.

To my knowledge setting WMI_PEER_NSS peer param itself enough to 
handle NSS
updates and no need to call ath10k_station_assoc(). So revert the 
original

commit from 2014 as it's unclear why the change was really needed.
Now the firmware assert doesn't happen anymore.

Issue observed in QCA9984 platform with firmware 
version:10.4-3.5.3-00053.
This Change tested in QCA9984 with firmware version: 10.4-3.5.3-00053 
and

QCA988x platform with firmware version: 10.2.4-1.0-00036.


Did you test this on any of the other major firmware variants? I
wonder if it snuck in because of some firmware quirk in something way
before dakota/cascade and 10.4 were a thing.

Eg, Peregrine? Rome? Maybe even earlier Beeliner, just to double check?

Yes. I tested this on peregrine, Beeliner, Dakota and Cascade. This code 
was introduced before Rome.


Thanks,
Karthikeyan.

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

[Hans de Goede]

Hi,

On 26-02-18 11:22, Arend van Spriel wrote:

On 2/25/2018 3:52 PM, Hans de Goede wrote:

Hi,

On 26-05-17 12:57, Hans de Goede wrote:

The firmware responding with -EBUSY when trying to add an extra
virtual-if
is a normal thing, do not print an error for this.

Signed-off-by: Hans de Goede 


I'm now seeing this on another device too, but this time the error
thrown is -EBADE, this seems to be new with recent kernels:


Yup. Before we were passing firmware errors up to user-space, which was 
confusing and potentially be misinterpreted. However, looking at the output 
below it would have been good to log the firmware error as well. And staring at 
it some more I suddenly realize I broke the feature detection module with this 
change. Actually only the GSCAN feature detection.


[root@localhost ~]# dmesg | grep brcmfmac
[   34.265950] usbcore: registered new interface driver brcmfmac
[   34.266059] brcmfmac :01:00.0: enabling device ( -> 0002)
[   34.376468] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x02
[   34.855143] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac4356-pcie.clm_blob failed with error -2
[   34.855147] brcmfmac: brcmf_c_process_clm_blob: no clm_blob
available(err=-2), device may have limited channels available
[   34.857029] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Jun  4 2017 16:50:07 version 7.35.101.6 (r702795) FWID 01-5e8eb735
[   34.938854] brcmfmac :01:00.0 wlp1s0: renamed from wlan0
[   37.086420] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[   37.086431] brcmfmac: brcmf_cfg80211_add_iface: add iface
p2p-dev-wlp1s0 type 10 failed: err=-52

[root@localhost ~]# strings /lib/firmware/brcm/brcmfmac4356-pcie.bin |
tail -n 1
4356a2-roml/pcie-ag-msgbuf-splitrx-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wl11u-mfp-tdls-amsdutx-sarctrl-proxd-hs20sta-rcc-wepso-ndoe-linkstat-gscan-hchk-logtrace-roamexp-rmon
Version: 7.35.101.6 (r702795) CRC: 4f3f65c5 Date: Sun 2017-06-04
16:51:38 PDT Ucode Ver: 963.316 FWID: 01-5e8eb735

It would be good if we can silence these errors, or maybe at a
minimum lower their log-level from error to warning?


I had a look at it and it seems to be a difference in firmware api that we need 
to support in the driver. Need to do a bit more digging, but it seems an actual 
issue. You could silence it for now, but I prefer to wait for the fix.


Ok, what is the ETA of a fix for this?

Regards,

Hans





---
  .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c    | 14
++
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c |  5 -
  2 files changed, 14 insertions(+), 5 deletions(-)

diff --git
a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index cd1d6730eab7..dae88f3d041d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -684,11 +684,17 @@ static struct wireless_dev
*brcmf_cfg80211_add_iface(struct wiphy *wiphy,
  return ERR_PTR(-EINVAL);
  }
-    if (IS_ERR(wdev))
-    brcmf_err("add iface %s type %d failed: err=%d\n",
-  name, type, (int)PTR_ERR(wdev));
-    else
+    if (IS_ERR(wdev)) {
+    err = PTR_ERR(wdev);
+    if (err != -EBUSY)
+    brcmf_err("add iface %s type %d failed: err=%d\n",
+  name, type, err);
+    else
+    brcmf_dbg(INFO, "add iface %s type %d failed: err=%d\n",
+  name, type, err);
+    } else {
  brcmf_cfg80211_update_proto_addr_mode(wdev);
+    }
  return wdev;
  }
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index aa299c47bfa2..1bb296ffb46f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2090,7 +2090,10 @@ static struct wireless_dev
*brcmf_p2p_create_p2pdev(struct brcmf_p2p_info *p2p,
  /* Initialize P2P Discovery in the firmware */
  err = brcmf_fil_iovar_int_set(pri_ifp, "p2p_disc", 1);
  if (err < 0) {
-    brcmf_err("set p2p_disc error\n");
+    if (err != -EBUSY)
+    brcmf_err("set p2p_disc error\n");
+    else
+    brcmf_dbg(INFO, "set p2p_disc error\n");
  brcmf_fweh_p2pdev_setup(pri_ifp, false);
  brcmf_cfg80211_arm_vif_event(p2p->cfg, NULL);
  goto fail;

RE: [PATCH] mac80211: inform wireless layer when frame RSSI is invalid

[Jean Pierre TOSONI]

> -Message d'origine-
> De : Johannes Berg [mailto:johan...@sipsolutions.net]
> Envoyé : lundi 19 février 2018 13:35
> À : Jean Pierre TOSONI; linux-wireless@vger.kernel.org
> Objet : Re: [PATCH] mac80211: inform wireless layer when frame RSSI
> is invalid
> 
(...)
> 
> > /* Track average RSSI from the Beacon frames of the current AP
> */
> > +   if (rx_status->flag & RX_FLAG_NO_SIGNAL_VAL)
> > +   goto skip_signal_processing;
> > if (ifmgd->flags & IEEE80211_STA_RESET_SIGNAL_AVE) {
> > ifmgd->flags &= ~IEEE80211_STA_RESET_SIGNAL_AVE;
> > ewma_beacon_signal_init(>ave_beacon_signal);
> > @@ -3454,6 +3456,7 @@ static void ieee80211_rx_mgmt_beacon(struct
> ieee80211_sub_if_data *sdata,
> > sig, GFP_KERNEL);
> > }
> > }
> > +skip_signal_processing:
> 
> Can't say I like this - how about we pull out the actual processing
> into a helper function, and then abort that function early if the
> NO_SIGNAL_VAL flag is set.
> 

Since I am working on an older version of mac80211, I was aiming to
keep changes minimal to avoid breaking something I could not test...
I'll have a look to your suggestion.

> johannes

Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time

[Arend van Spriel]

On 2/25/2018 3:52 PM, Hans de Goede wrote:

Hi,

On 26-05-17 12:57, Hans de Goede wrote:

The firmware responding with -EBUSY when trying to add an extra
virtual-if
is a normal thing, do not print an error for this.

Signed-off-by: Hans de Goede 


I'm now seeing this on another device too, but this time the error
thrown is -EBADE, this seems to be new with recent kernels:


Yup. Before we were passing firmware errors up to user-space, which was 
confusing and potentially be misinterpreted. However, looking at the 
output below it would have been good to log the firmware error as well. 
And staring at it some more I suddenly realize I broke the feature 
detection module with this change. Actually only the GSCAN feature 
detection.



[root@localhost ~]# dmesg | grep brcmfmac
[   34.265950] usbcore: registered new interface driver brcmfmac
[   34.266059] brcmfmac :01:00.0: enabling device ( -> 0002)
[   34.376468] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm/brcmfmac4356-pcie.bin for chip 0x004356(17238) rev 0x02
[   34.855143] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac4356-pcie.clm_blob failed with error -2
[   34.855147] brcmfmac: brcmf_c_process_clm_blob: no clm_blob
available(err=-2), device may have limited channels available
[   34.857029] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Jun  4 2017 16:50:07 version 7.35.101.6 (r702795) FWID 01-5e8eb735
[   34.938854] brcmfmac :01:00.0 wlp1s0: renamed from wlan0
[   37.086420] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[   37.086431] brcmfmac: brcmf_cfg80211_add_iface: add iface
p2p-dev-wlp1s0 type 10 failed: err=-52

[root@localhost ~]# strings /lib/firmware/brcm/brcmfmac4356-pcie.bin |
tail -n 1
4356a2-roml/pcie-ag-msgbuf-splitrx-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wl11u-mfp-tdls-amsdutx-sarctrl-proxd-hs20sta-rcc-wepso-ndoe-linkstat-gscan-hchk-logtrace-roamexp-rmon
Version: 7.35.101.6 (r702795) CRC: 4f3f65c5 Date: Sun 2017-06-04
16:51:38 PDT Ucode Ver: 963.316 FWID: 01-5e8eb735

It would be good if we can silence these errors, or maybe at a
minimum lower their log-level from error to warning?


I had a look at it and it seems to be a difference in firmware api that 
we need to support in the driver. Need to do a bit more digging, but it 
seems an actual issue. You could silence it for now, but I prefer to 
wait for the fix.


Regards,
Arend


Regards,

Hans



---
  .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 14
++
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c |  5 -
  2 files changed, 14 insertions(+), 5 deletions(-)

diff --git
a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index cd1d6730eab7..dae88f3d041d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -684,11 +684,17 @@ static struct wireless_dev
*brcmf_cfg80211_add_iface(struct wiphy *wiphy,
  return ERR_PTR(-EINVAL);
  }
-if (IS_ERR(wdev))
-brcmf_err("add iface %s type %d failed: err=%d\n",
-  name, type, (int)PTR_ERR(wdev));
-else
+if (IS_ERR(wdev)) {
+err = PTR_ERR(wdev);
+if (err != -EBUSY)
+brcmf_err("add iface %s type %d failed: err=%d\n",
+  name, type, err);
+else
+brcmf_dbg(INFO, "add iface %s type %d failed: err=%d\n",
+  name, type, err);
+} else {
  brcmf_cfg80211_update_proto_addr_mode(wdev);
+}
  return wdev;
  }
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index aa299c47bfa2..1bb296ffb46f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2090,7 +2090,10 @@ static struct wireless_dev
*brcmf_p2p_create_p2pdev(struct brcmf_p2p_info *p2p,
  /* Initialize P2P Discovery in the firmware */
  err = brcmf_fil_iovar_int_set(pri_ifp, "p2p_disc", 1);
  if (err < 0) {
-brcmf_err("set p2p_disc error\n");
+if (err != -EBUSY)
+brcmf_err("set p2p_disc error\n");
+else
+brcmf_dbg(INFO, "set p2p_disc error\n");
  brcmf_fweh_p2pdev_setup(pri_ifp, false);
  brcmf_cfg80211_arm_vif_event(p2p->cfg, NULL);
  goto fail;

Re: [PATCH] ath9k: introduce endian_check module parameter

[Bas Vermeulen]

On 26-02-18 10:54, Kalle Valo wrote:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
  
+static int ath9k_endian_check;

+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness compatibility");
  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
  
  int ath9k_use_chanctx;

@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
ether_addr_copy(common->macaddr, mac);
  
  	ah->ah_flags &= ~AH_USE_EEPROM;

-   ah->ah_flags |= AH_NO_EEP_SWAP;
+   if (!ath9k_endian_check)
+   ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?
There is an automatic way to detect this, but that is disabled by the 
AH_NO_EEP_SWAP flag.
The platform initialisation does not set this flag if the endian_check 
member of pdata is set
to true, but there is no way to not set this when using a device tree. I 
used a module
parameter instead of a device tree variable because I don't know of a 
way to modify the

device tree my PowerMac boots with.

Bas Vermeulen

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [PATCH] ath9k: introduce endian_check module parameter

[Kalle Valo]

Bas Vermeulen  writes:

> A random (little endian eeprom'd) ar9278 card didn't work on my
> PowerMac G5 without allowing the driver to byte-swap the eeprom.
>
> Introduce a module parameter endian_check to allow this to happen,
> and the PCIe card to function correctly on BE powerpc.
>
> Signed-off-by: Bas Vermeulen 
> ---
>  drivers/net/wireless/ath/ath9k/init.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/init.c 
> b/drivers/net/wireless/ath/ath9k/init.c
> index fa58a32227f5..421039dc060a 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -67,6 +67,9 @@ static int ath9k_ps_enable;
>  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
>  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
>  
> +static int ath9k_endian_check;
> +module_param_named(endian_check, ath9k_endian_check, int, 0444);
> +MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness compatibility");
>  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
>  
>  int ath9k_use_chanctx;
> @@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
>   ether_addr_copy(common->macaddr, mac);
>  
>   ah->ah_flags &= ~AH_USE_EEPROM;
> - ah->ah_flags |= AH_NO_EEP_SWAP;
> + if (!ath9k_endian_check)
> + ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?

-- 
Kalle Valo

[PATCH] ath9k: introduce endian_check module parameter

[Bas Vermeulen]

A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
 drivers/net/wireless/ath/ath9k/init.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
 module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
 MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
 
+static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness compatibility");
 #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
 
 int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
ether_addr_copy(common->macaddr, mac);
 
ah->ah_flags &= ~AH_USE_EEPROM;
-   ah->ah_flags |= AH_NO_EEP_SWAP;
+   if (!ath9k_endian_check)
+   ah->ah_flags |= AH_NO_EEP_SWAP;
 
return 0;
 }
-- 
2.16.2


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

[Adrian Chadd]

hi!

On 25 February 2018 at 22:16, Karthikeyan Periyasamy
 wrote:
> This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159.
>
> When Ath10k is in AP mode and an unassociated STA sends a VHT action frame
> (Operating Mode Notification for the NSS change) periodically to AP this 
> causes
> ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID during
> NSS update. Over the time (with a certain client it can happen within 15 mins
> when there are over 500 of these VHT action frames) continuous calls of
> WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust.
>
> To my knowledge setting WMI_PEER_NSS peer param itself enough to handle NSS
> updates and no need to call ath10k_station_assoc(). So revert the original
> commit from 2014 as it's unclear why the change was really needed.
> Now the firmware assert doesn't happen anymore.
>
> Issue observed in QCA9984 platform with firmware version:10.4-3.5.3-00053.
> This Change tested in QCA9984 with firmware version: 10.4-3.5.3-00053 and
> QCA988x platform with firmware version: 10.2.4-1.0-00036.

Did you test this on any of the other major firmware variants? I
wonder if it snuck in because of some firmware quirk in something way
before dakota/cascade and 10.4 were a thing.

Eg, Peregrine? Rome? Maybe even earlier Beeliner, just to double check?

Thanks,



-adrian

[PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

[s . gottschall]

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall 

v2  add correct gpio count per chipset and remove IPQ4019 support since this 
chipset does not make use of specific gpios)
v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
kbuild test robot which does not occur in standard builds. curious
v6  correct return values and fix comment style
v7  fix ath10k_unregister_led for compiling without LED_CLASS
v8  fix various code design issues reported by reviewers
v9  move led and led code to separate sourcefile (gpio.c)
v10 compile fix if gpiolib isnt included
v11 make register_gpio_chip static. advise by krobot
v12 fix warning
---
 drivers/net/wireless/ath/ath10k/Kconfig   |  10 ++
 drivers/net/wireless/ath/ath10k/Makefile  |   1 +
 drivers/net/wireless/ath/ath10k/core.c|  28 -
 drivers/net/wireless/ath/ath10k/core.h|  62 +-
 drivers/net/wireless/ath/ath10k/debug.c   | 146 ++
 drivers/net/wireless/ath/ath10k/gpio.c| 196 ++
 drivers/net/wireless/ath/ath10k/hw.h  |   2 +
 drivers/net/wireless/ath/ath10k/mac.c |   5 +
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
 drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
 drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
 12 files changed, 630 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index deb5ae21a559..5d61d499dca4 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -10,6 +10,16 @@ config ATH10K
 
   If you choose to build a module, it'll be called ath10k.
 
+config ATH10K_LEDS
+   bool "SoftLED Support"
+   depends on ATH10K
+   select MAC80211_LEDS
+   select LEDS_CLASS
+   select NEW_LEDS
+   default y
+   help
+ This option is necessary, if you want LED support for chipset 
connected led pins
+
 config ATH10K_PCI
tristate "Atheros ath10k PCI support"
depends on ATH10K && PCI
diff --git a/drivers/net/wireless/ath/ath10k/Makefile 
b/drivers/net/wireless/ath/ath10k/Makefile
index 6739ac26fd29..eccc9806fa43 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -20,6 +20,7 @@ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
 ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
 ath10k_core-$(CONFIG_THERMAL) += thermal.o
 ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
+ath10k_core-$(CONFIG_ATH10K_LEDS) += gpio.o
 ath10k_core-$(CONFIG_PM) += wow.o
 ath10k_core-$(CONFIG_DEV_COREDUMP) += coredump.o
 
diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f3ec13b80b20..d7f89ca98c2d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -21,6 +21,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+
 
 #include "core.h"
 #include "mac.h"
@@ -65,6 +69,8 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID,
.name = "qca988x hw2.0",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -94,6 +100,8 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
.name = "qca988x hw2.0 ubiquiti",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -123,6 +131,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA9887_HW_1_0_VERSION,
.dev_id = QCA9887_1_0_DEVICE_ID,
.name = "qca9887 hw1.0",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -267,6 +277,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA99X0_HW_2_0_DEV_VERSION,

[PATCH v2] ath10k: debugfs support to get final TPC stats for 10.4 variants

[mkenna]

From: Maharaja Kennadyrajan 

Export the final Transmit Power Control (TPC) value, which is the
minimum of control power and existing TPC value to user space via
a new debugfs file "tpc_stats_final" to help with debugging.
It works with the new wmi cmd and event introduced in 10.4 firmware
branch.

WMI command ID: WMI_PDEV_GET_TPC_TABLE_CMDID
WMI event ID: WMI_PDEV_TPC_TABLE_EVENTID

cat /sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats_final

$ cat /sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats_final

TPC config for channel 5180 mode 10

CTL =  0x 0 Reg. Domain = 58
Antenna Gain=  0 Reg. Max Antenna Gain  =   0
Power Limit = 60 Reg. Max Power = 60
Num tx chains   =  2 Num supported rates= 109

*** CDD POWER TABLE 

No.  Preamble Rate_code tpc_value1 tpc_value2 tpc_value3
0CCK  0x400  0
1CCK  0x410  0
[...]
107  HTCUP0x 0   46  46
108  HTCUP0x 0   46  46

*** STBC POWER TABLE 

No.  Preamble Rate_code tpc_value1 tpc_value2 tpc_value3
0CCK  0x400  0
1CCK  0x410  0
[...]
107  HTCUP0x 046 46
108  HTCUP0x 046 46

***
TXBF not supported
**

The existing tpc_stats debugfs file provides the dump
which is minimum of target power and regulatory domain.

cat /sys/kernel/debug/ieee80211/phyX/ath10k/tpc_stats

Hardware_used: QCA4019
Firmware version: firmware-5.bin_10.4-3.0-00209

Signed-off-by: Maharaja Kennadyrajan 
---
v2: Addressed sparse warnings: (new ones prefixed by >>)

 drivers/net/wireless/ath/ath10k/core.h|  23 +++
 drivers/net/wireless/ath/ath10k/debug.c   | 107 +++
 drivers/net/wireless/ath/ath10k/debug.h   |  11 ++
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  21 ++
 drivers/net/wireless/ath/ath10k/wmi.c | 308 --
 drivers/net/wireless/ath/ath10k/wmi.h |  66 +++
 6 files changed, 521 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index fe6b303..a7cbd79 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2005-2011 Atheros Communications Inc.
  * Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -324,6 +325,27 @@ struct ath10k_tpc_stats {
struct ath10k_tpc_table tpc_table[WMI_TPC_FLAG];
 };
 
+struct ath10k_tpc_table_final {
+   u32 pream_idx[WMI_TPC_FINAL_RATE_MAX];
+   u8 rate_code[WMI_TPC_FINAL_RATE_MAX];
+   char tpc_value[WMI_TPC_FINAL_RATE_MAX][WMI_TPC_TX_N_CHAIN * 
WMI_TPC_BUF_SIZE];
+};
+
+struct ath10k_tpc_stats_final {
+   u32 reg_domain;
+   u32 chan_freq;
+   u32 phy_mode;
+   u32 twice_antenna_reduction;
+   u32 twice_max_rd_power;
+   s32 twice_antenna_gain;
+   u32 power_limit;
+   u32 num_tx_chain;
+   u32 ctl;
+   u32 rate_max;
+   u8 flag[WMI_TPC_FLAG];
+   struct ath10k_tpc_table_final tpc_table_final[WMI_TPC_FLAG];
+};
+
 struct ath10k_dfs_stats {
u32 phy_errors;
u32 pulses_total;
@@ -487,6 +509,7 @@ struct ath10k_debug {
 
/* used for tpc-dump storage, protected by data-lock */
struct ath10k_tpc_stats *tpc_stats;
+   struct ath10k_tpc_stats_final *tpc_stats_final;
 
struct completion tpc_complete;
 
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 554cd78..a726f7c 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1480,6 +1480,19 @@ void ath10k_debug_tpc_stats_process(struct ath10k *ar,
spin_unlock_bh(>data_lock);
 }
 
+void
+ath10k_debug_tpc_stats_final_process(struct ath10k *ar,
+struct ath10k_tpc_stats_final *tpc_stats)
+{
+   spin_lock_bh(>data_lock);
+
+   kfree(ar->debug.tpc_stats_final);
+   ar->debug.tpc_stats_final = tpc_stats;
+   complete(>debug.tpc_complete);
+
+   spin_unlock_bh(>data_lock);
+}
+
 static void ath10k_tpc_stats_print(struct ath10k_tpc_stats *tpc_stats,
   unsigned int j, char *buf, size_t *len)
 {
@@ -2143,6 +2156,95 @@ static ssize_t ath10k_debug_fw_checksums_read(struct 
file *file,
.llseek = default_llseek,
 };
 
+static int ath10k_debug_tpc_stats_final_request(struct ath10k *ar)
+{
+   int ret;
+   unsigned long time_left;
+
+   lockdep_assert_held(>conf_mutex);
+
+