Re: [PATCH] ath10k: fix out of bounds access to local buffer

2017-05-15 Thread Kalle Valo 
Michael Mera  writes:

> Marcin Rokicki  writes:
>> Please send again to ath...@lists.infradead.org with cc
>> linux-wireless@vger.kernel.org
>>
>
> Sorry for the mistake. Resent as requested.
>
> Just for the record, I followed instructions at:
>   
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches?s[]=submit#who_to_address
>
> So, maybe this needs to be updated to reflect the ath10k case.

I added a link to the corresponding ath10k page. BTW, it's a wiki so
everyone are free to improve the instructions on their own.

-- 
Kalle Valo

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

2017-05-15 Thread Luis R. Rodriguez 
On Fri, May 12, 2017 at 11:02:26PM +0200, Arend Van Spriel wrote:
> try again.. replacing email address from Michał
> On 12-5-2017 22:55, Arend Van Spriel wrote:
> > Let me explain the idea to refresh your memory (and mine). It started
> > when we were working on adding driver support for OpenWrt in brcmfmac.
> > The driver requests for firmware calibration data, but on routers it is
> > stored in flash. So after failing on the firmware request we now call a
> > platform specific API. That was my itch, but it was not bad enough to go
> > and scratch. Now for N900 case there is a similar scenario alhtough it
> > has additional requirement to go to user-space due to need to use a
> > proprietary library to obtain the NVS calibration data. My thought: Why
> > should firmware_class care?

Agreed.

> > So the idea is that firmware_class provides
> > a registry for modules that can produce a certain firmware "file". Those
> > modules can do whatever is needed. If they need to use umh so be it.
> > They would only register themselves with firmware_class on platforms
> > that need them. It would basically be replacing the fallback mechanism
> > and only be effective on certain platforms.

Sure, so it sounds like the work that Daniel Wagner and Tom Gundersen worked
[0] on which provides a firmwared with two modes: best-effort, and final-mode,
would address what you are looking for but without requiring any upstream
changes, *and* it also helps solve the rootfs race remote-proc folks had
concerns over.

The other added gain over this solution is if folks need their own proprietary
concoction they can just fork firmwared and have that do whatever it needs
for the specific device on the specific rootfs. That is, firmwared can be the
upstream solution if folks need it, but if folks need something custom they can
just mimic the implementation: best-effort, and and final-mode.

Yet another added gain over this solution we can do *not* support the
custom fallback mechanism as its not needed, the udev event should suffice
to let userspace do what it needs.

Lastly, if we did not want to deal with timeouts for the way the driver data
API implements it I think we might be able to do away with them for for async
requests if we assume there will be a daemon that spawns in final-mode 
eventually,
and since it *knows* when the rootfs is ready it should be able to do a final
lookup, if it returns -ENOENT; then indeed we know we can give up. Now, perhaps
how and if we want to deal with timeouts when using the driver data API for
the fallback mechanism is worth considering given it does not have a fallback
mechanism support yet. If we *add* them it would seem this would also put an
implicit race against userspace finishing initialization and running firmwared
in final-mode.

Johannes, do you recall the corner cases we spoke about regarding timeouts?
Does this match what we spoke about?

> > Let me know if this idea is still of interest and I will rebase what I
> > have for an RFC round.

Since no upstream delta is needed for firmwared I'd like to first encourage
evaluating the above. While distributions don't carry it yet that may be seen as
an issue but since what we are looking for are corner cases, only folks needing
to deploy a specific solution would need it or a custom proprietary solution.

[0] https://github.com/teg/firmwared.git

PS.

Note that firmware signing will require an additional file, the detached
signature. The driver data API does not currently support the fallback
mechanism so we would not have to worry about that yet but once we add
fallback support we'd need to consider this.

  Luis

Re: [PATCH 1/1] dt-binding: net: wireless: fix node name in the BCM43xx example

2017-05-15 Thread Arend Van Spriel 
On 15-5-2017 22:13, Martin Blumenstingl wrote:
> The example in the BCM43xx documentation uses "brcmf" as node name.
> However, wireless devices should be named "wifi" instead. Fix this to

Hi Martin,

Since when is that a rule. I never got the memo and the DTC did not ever
complain to me about the naming. That being said I do not really care
and I suppose it is for the sake of consistency only.

> make sure that .dts authors can simply use the documentation as
> reference (or simply copy the node from the documentation and then
> adjust only the board specific bits).

Please feel free to add my...

Acked-by: Arend van Spriel 
> Signed-off-by: Martin Blumenstingl 
> ---
>  Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt 
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index 5dbf169cd81c..590f622188de 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -31,7 +31,7 @@ mmc3: mmc@01c12000 {
>   non-removable;
>   status = "okay";
>  
> - brcmf: bcrmf@1 {
> + brcmf: wifi@1 {
>   reg = <1>;
>   compatible = "brcm,bcm4329-fmac";
>   interrupt-parent = <>;
>

[PATCH] libertas: Remove function entry/exit debugging

2017-05-15 Thread Kees Cook 
In at least one place, the enter/exit debugging was not being correctly
matched. Based on mailing list feedback, it was desired to drop all of
these in favor of using ftrace instead.

Suggested-by: Joe Perches 
Suggested-by: Kalle Valo 
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/marvell/libertas/cfg.c | 104 +
 drivers/net/wireless/marvell/libertas/cmd.c | 116 ++--
 drivers/net/wireless/marvell/libertas/cmdresp.c |   9 --
 drivers/net/wireless/marvell/libertas/defs.h|   9 --
 drivers/net/wireless/marvell/libertas/ethtool.c |   3 -
 drivers/net/wireless/marvell/libertas/if_cs.c   |  36 
 drivers/net/wireless/marvell/libertas/if_sdio.c |  66 +-
 drivers/net/wireless/marvell/libertas/if_spi.c  |  38 ++--
 drivers/net/wireless/marvell/libertas/if_usb.c  |  27 +-
 drivers/net/wireless/marvell/libertas/main.c|  81 +
 drivers/net/wireless/marvell/libertas/mesh.c|  28 --
 drivers/net/wireless/marvell/libertas/rx.c  |   6 --
 drivers/net/wireless/marvell/libertas/tx.c  |   3 -
 13 files changed, 24 insertions(+), 502 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas/cfg.c 
b/drivers/net/wireless/marvell/libertas/cfg.c
index a0463fef79b0..71ba2c8d09b5 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -443,17 +443,12 @@ static int lbs_cfg_set_monitor_channel(struct wiphy 
*wiphy,
struct lbs_private *priv = wiphy_priv(wiphy);
int ret = -ENOTSUPP;
 
-   lbs_deb_enter_args(LBS_DEB_CFG80211, "freq %d, type %d",
-  chandef->chan->center_freq,
-  cfg80211_get_chandef_type(chandef));
-
if (cfg80211_get_chandef_type(chandef) != NL80211_CHAN_NO_HT)
goto out;
 
ret = lbs_set_channel(priv, chandef->chan->hw_value);
 
  out:
-   lbs_deb_leave_args(LBS_DEB_CFG80211, "ret %d", ret);
return ret;
 }
 
@@ -464,16 +459,12 @@ static int lbs_cfg_set_mesh_channel(struct wiphy *wiphy,
struct lbs_private *priv = wiphy_priv(wiphy);
int ret = -ENOTSUPP;
 
-   lbs_deb_enter_args(LBS_DEB_CFG80211, "iface %s freq %d",
-  netdev_name(netdev), channel->center_freq);
-
if (netdev != priv->mesh_dev)
goto out;
 
ret = lbs_mesh_set_channel(priv, channel->hw_value);
 
  out:
-   lbs_deb_leave_args(LBS_DEB_CFG80211, "ret %d", ret);
return ret;
 }
 
@@ -512,8 +503,6 @@ static int lbs_ret_scan(struct lbs_private *priv, unsigned 
long dummy,
int i;
int ret = -EILSEQ;
 
-   lbs_deb_enter(LBS_DEB_CFG80211);
-
bsssize = get_unaligned_le16(>bssdescriptsize);
 
lbs_deb_scan("scan response: %d BSSs (%d bytes); resp size %d bytes\n",
@@ -665,7 +654,6 @@ static int lbs_ret_scan(struct lbs_private *priv, unsigned 
long dummy,
ret = 0;
 
  done:
-   lbs_deb_leave_args(LBS_DEB_SCAN, "ret %d", ret);
return ret;
 }
 
@@ -693,11 +681,9 @@ static void lbs_scan_worker(struct work_struct *work)
int last_channel;
int running, carrier;
 
-   lbs_deb_enter(LBS_DEB_SCAN);
-
scan_cmd = kzalloc(LBS_SCAN_MAX_CMD_SIZE, GFP_KERNEL);
if (scan_cmd == NULL)
-   goto out_no_scan_cmd;
+   return;
 
/* prepare fixed part of scan command */
scan_cmd->bsstype = CMD_BSS_TYPE_ANY;
@@ -766,16 +752,11 @@ static void lbs_scan_worker(struct work_struct *work)
lbs_deb_scan("scan: waking up waiters\n");
wake_up_all(>scan_q);
}
-
- out_no_scan_cmd:
-   lbs_deb_leave(LBS_DEB_SCAN);
 }
 
 static void _internal_start_scan(struct lbs_private *priv, bool internal,
struct cfg80211_scan_request *request)
 {
-   lbs_deb_enter(LBS_DEB_CFG80211);
-
lbs_deb_scan("scan: ssids %d, channels %d, ie_len %zd\n",
request->n_ssids, request->n_channels, request->ie_len);
 
@@ -785,8 +766,6 @@ static void _internal_start_scan(struct lbs_private *priv, 
bool internal,
 
queue_delayed_work(priv->work_thread, >scan_work,
msecs_to_jiffies(50));
-
-   lbs_deb_leave(LBS_DEB_CFG80211);
 }
 
 /*
@@ -815,8 +794,6 @@ static int lbs_cfg_scan(struct wiphy *wiphy,
struct lbs_private *priv = wiphy_priv(wiphy);
int ret = 0;
 
-   lbs_deb_enter(LBS_DEB_CFG80211);
-
if (priv->scan_req || delayed_work_pending(>scan_work)) {
/* old scan request not yet processed */
ret = -EAGAIN;
@@ -829,7 +806,6 @@ static int lbs_cfg_scan(struct wiphy *wiphy,
ret = -EIO;
 
  out:
-   lbs_deb_leave_args(LBS_DEB_CFG80211, "ret %d", ret);
return ret;
 }
 
@@ -843,18 +819,12 @@ static int lbs_cfg_scan(struct wiphy *wiphy,
 void lbs_send_disconnect_notification(struct lbs_private

[PATCH v3] libertas: Avoid reading past end of buffer

2017-05-15 Thread Kees Cook 
Using memcpy() from a string that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from the kernel
rodata segment. Instead, redefine the stat strings to be ETH_GSTRING_LEN
sizes, like other drivers. This lets us use a single memcpy that does not
leak rodata contents. Additionally adjust indentation to keep checkpatch.pl
happy.

This was found with the future CONFIG_FORTIFY_SOURCE feature.

Cc: Daniel Micay 
Signed-off-by: Kees Cook 
---
v3:
- drop needless "*"; joe
- fix entry/exit in separate patch
v2:
- use ETH_GSTRING_LEN; joe
---
 drivers/net/wireless/marvell/libertas/mesh.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas/mesh.c 
b/drivers/net/wireless/marvell/libertas/mesh.c
index d0c881dd5846..2229fb448189 100644
--- a/drivers/net/wireless/marvell/libertas/mesh.c
+++ b/drivers/net/wireless/marvell/libertas/mesh.c
@@ -1108,15 +1108,15 @@ void lbs_mesh_set_txpd(struct lbs_private *priv,
  * Ethtool related
  */
 
-static const char * const mesh_stat_strings[] = {
-   "drop_duplicate_bcast",
-   "drop_ttl_zero",
-   "drop_no_fwd_route",
-   "drop_no_buffers",
-   "fwded_unicast_cnt",
-   "fwded_bcast_cnt",
-   "drop_blind_table",
-   "tx_failed_cnt"
+static const char mesh_stat_strings[MESH_STATS_NUM][ETH_GSTRING_LEN] = {
+   "drop_duplicate_bcast",
+   "drop_ttl_zero",
+   "drop_no_fwd_route",
+   "drop_no_buffers",
+   "fwded_unicast_cnt",
+   "fwded_bcast_cnt",
+   "drop_blind_table",
+   "tx_failed_cnt"
 };
 
 void lbs_mesh_ethtool_get_stats(struct net_device *dev,
@@ -1170,17 +1170,11 @@ int lbs_mesh_ethtool_get_sset_count(struct net_device 
*dev, int sset)
 void lbs_mesh_ethtool_get_strings(struct net_device *dev,
uint32_t stringset, uint8_t *s)
 {
-   int i;
-
lbs_deb_enter(LBS_DEB_ETHTOOL);
 
switch (stringset) {
case ETH_SS_STATS:
-   for (i = 0; i < MESH_STATS_NUM; i++) {
-   memcpy(s + i * ETH_GSTRING_LEN,
-   mesh_stat_strings[i],
-   ETH_GSTRING_LEN);
-   }
+   memcpy(s, mesh_stat_strings, sizeof(mesh_stat_strings));
break;
}
lbs_deb_enter(LBS_DEB_ETHTOOL);
-- 
2.7.4


-- 
Kees Cook
Pixel Security

Re: BUG related to NAPI and ath10k in 4.9 + hacks kernel.

2017-05-15 Thread Ben Greear 

On 05/15/2017 11:26 AM, Ben Greear wrote:

This is from a test system running my hacked 4.9 kernel, with 9888 ath10k
NIC which often fails during startup.  The firmware did fail to boot this time,
and maybe it left things in a weird state.  Then, the whole OS crashed with BUG.


I think the bug happens like this:

otp fails (don't know why, possibly BMI timeout is too short)

That makes core_start fail:
ret = ath10k_core_start(ar, ATH10K_FIRMWARE_MODE_NORMAL,
 >normal_mode_fw);
 if (ret) {
  ath10k_err(ar, "could not init core (%d)\n", ret);
  goto err_unlock;
 }

That method returns without disabling NAPI, and because core was never
successfully started, it is not later stopped (which would have disabled
napi).  So, napi is never disabled in this error case.

Thanks,
Ben





[ cut here ]
kernel BUG at /home/greearb/git/linux-4.9.dev.y/include/linux/netdevice.h:515!
invalid opcode:  [#1] PREEMPT SMP
Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 
bridge ath10k_pci ath10k_core 8021q garp mrp stp llc bnep bluetooth fuse macv]
CPU: 1 PID: 3651 Comm: wpa_supplicant Not tainted 4.9.27+ #35
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 
4.6.5 06/07/2013
task: 8802111f task.stack: c90001fb4000
RIP: 0010:[]  [] 
ath10k_pci_hif_power_up+0x173/0x180 [ath10k_pci]
RSP: 0018:c90001fb7c30  EFLAGS: 00010246
RAX: 0008 RBX: 880212bc2bc0 RCX: 00082004
RDX: c9000d282000 RSI: c9000d282000 RDI: 0fd0a000
RBP: c90001fb7c40 R08: 0020 R09: 0101
R10: 0d00 R11: 0003 R12: 00082000
R13: 880212beaef8 R14:  R15: 8802134c1118
FS:  7f476575c800() GS:88021e24() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f3da950b490 CR3: 000212b5a000 CR4: 001406e0
Stack:
 880212bc2bc0 880212bc0700 c90001fb7c68 a1429281
 8802134c 880212bc0700  c90001fb7c90
 a07cb818 8802134c 880212bc0700 
Call Trace:
 [] ath10k_start+0x51/0x5c0 [ath10k_core]
 [] drv_start+0x38/0x140 [mac80211]
 [] ieee80211_do_open+0x2c5/0x990 [mac80211]
 [] ieee80211_open+0x50/0x60 [mac80211]
 [] __dev_open+0xaa/0x120
 [] __dev_change_flags+0x98/0x160
 [] dev_change_flags+0x24/0x60
 [] devinet_ioctl+0x5ee/0x6c0
 [] inet_ioctl+0x4b/0x70
 [] sock_do_ioctl+0x20/0x50
 [] sock_ioctl+0x1d6/0x2a0
 [] do_vfs_ioctl+0x8b/0x5b0
 [] ? __sys_recvmsg+0x3d/0x70
 [] SyS_ioctl+0x74/0x80
 [] entry_SYSCALL_64_fastpath+0x1e/0xad
Code: ff ff ff 89 c2 48 89 df 48 c7 c6 10 d3 49 a1 e8 34 1d f9 ff 48 89 df e8 2c f9 
ff ff 44 89 e0 c6 83 0e 74 02 00 01 5b 41 5c 5d c3 <0f> 0b 66 66 2e 0f
RIP  [] ath10k_pci_hif_power_up+0x173/0x180 [ath10k_pci]
 RSP 
---[ end trace b6dede286ed70e39 ]---


The BUG in question is this:

/**
 *  napi_enable - enable NAPI scheduling
 *  @n: NAPI context
 *
 * Resume NAPI from being scheduled on this context.
 * Must be paired with napi_disable.
 */
static inline void napi_enable(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, >state));
smp_mb__before_atomic();
clear_bit(NAPI_STATE_SCHED, >state);
clear_bit(NAPI_STATE_NPSVC, >state);
}


Any ideas what might be the cause of this?

Thanks,
Ben




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

[PATCH 0/1] fix node name in the brcm,bcm43xx-fmac.txt example

2017-05-15 Thread Martin Blumenstingl 
recently there were some negative comments about the quality of
code-reviews for new .dts additions. one issue that came up was that the
node for the Broadcom FullMAC wireless SDIO devices was named "brcmf"
instead of "wifi".

This patch tries to fix (one of) the root cause(s), which is that .dts
authors copy the example from the documentation.
unfortunately there are still many .dts files out there which use
"brmcf" as node name - so any new addition of a Broadcom FullMAC SDIO
wireless device should be reviewed carefully regarding the node name
(just in case a .dts author copied from another .dts which still uses
the "wrong" node name).

Martin Blumenstingl (1):
  dt-binding: net: wireless: fix node name in the BCM43xx example

 Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.13.0

[PATCH 1/1] dt-binding: net: wireless: fix node name in the BCM43xx example

2017-05-15 Thread Martin Blumenstingl 
The example in the BCM43xx documentation uses "brcmf" as node name.
However, wireless devices should be named "wifi" instead. Fix this to
make sure that .dts authors can simply use the documentation as
reference (or simply copy the node from the documentation and then
adjust only the board specific bits).

Signed-off-by: Martin Blumenstingl 
---
 Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt 
b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
index 5dbf169cd81c..590f622188de 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
@@ -31,7 +31,7 @@ mmc3: mmc@01c12000 {
non-removable;
status = "okay";
 
-   brcmf: bcrmf@1 {
+   brcmf: wifi@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
interrupt-parent = <>;
-- 
2.13.0

Re: [PATCH] rt2x00: improve calling conventions for register accessors

2017-05-15 Thread Daniel Golle 
On Mon, May 15, 2017 at 10:40:52AM -0400, David Miller wrote:
> From: Arnd Bergmann 
> Date: Mon, 15 May 2017 16:36:45 +0200
> 
> > On Mon, May 15, 2017 at 4:28 PM, Stanislaw Gruszka  
> > wrote:
> >> On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote:
> >>> With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
> >>> stack usage (with a private patch set I have to turn on this warning,
> >>> which I intend to get into the next kernel release):
> >>>
> >>> wireless/ralink/rt2x00/rt2800lib.c: In function 
> >>> 'rt2800_bw_filter_calibration':
> >>> wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 
> >>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
> >>>
> >>> The problem is that KASAN inserts a redzone around each local variable 
> >>> that
> >>> gets passed by reference, and the newly added function has a lot of them.
> >>> We can easily avoid that here by changing the calling convention to have
> >>> the output as the return value of the function. This should also results 
> >>> in
> >>> smaller object code, saving around 4KB in .text with KASAN, or 2KB without
> >>> KASAN.
> >>>
> >>> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> >>> Signed-off-by: Arnd Bergmann 
> >>> ---
> >>>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 319 
> >>> +
> >>>  1 file changed, 164 insertions(+), 155 deletions(-)
> >>
> >> We have read(, ) calling convention since forever in rt2x00 and that
> >> was never a problem. I dislike to change that now to make some tools
> >> happy, I think problem should be fixed in the tools instead.
> > 
> > How about adding 'depends on !KASAN' in Kconfig instead?
> 
> Please let's not go down that route and make such facilities less
> useful due to decreased coverage.

Being the one to blame for submitting the patch adding most of the
problem's footprint: Arnd's change looks good to me and I believe it
should be merged.
This is the type of feedback I was hoping for when submitting all the
long-forgotten and rotting patches from OpenWrt's mac80211 driver
patches! Thanks to Arnd for your efforts!

Consider this as
Acked-by: Daniel Golle 
for Arnd's original patch (and for NOT adding 'depends on !KASAN')

Cheers


Daniel

> 
> Thanks.

BUG related to NAPI and ath10k in 4.9 + hacks kernel.

2017-05-15 Thread Ben Greear 

This is from a test system running my hacked 4.9 kernel, with 9888 ath10k
NIC which often fails during startup.  The firmware did fail to boot this time,
and maybe it left things in a weird state.  Then, the whole OS crashed with BUG.


[ cut here ]
kernel BUG at /home/greearb/git/linux-4.9.dev.y/include/linux/netdevice.h:515!
invalid opcode:  [#1] PREEMPT SMP
Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv4 
bridge ath10k_pci ath10k_core 8021q garp mrp stp llc bnep bluetooth fuse macv]
CPU: 1 PID: 3651 Comm: wpa_supplicant Not tainted 4.9.27+ #35
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 
4.6.5 06/07/2013
task: 8802111f task.stack: c90001fb4000
RIP: 0010:[]  [] 
ath10k_pci_hif_power_up+0x173/0x180 [ath10k_pci]
RSP: 0018:c90001fb7c30  EFLAGS: 00010246
RAX: 0008 RBX: 880212bc2bc0 RCX: 00082004
RDX: c9000d282000 RSI: c9000d282000 RDI: 0fd0a000
RBP: c90001fb7c40 R08: 0020 R09: 0101
R10: 0d00 R11: 0003 R12: 00082000
R13: 880212beaef8 R14:  R15: 8802134c1118
FS:  7f476575c800() GS:88021e24() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f3da950b490 CR3: 000212b5a000 CR4: 001406e0
Stack:
 880212bc2bc0 880212bc0700 c90001fb7c68 a1429281
 8802134c 880212bc0700  c90001fb7c90
 a07cb818 8802134c 880212bc0700 
Call Trace:
 [] ath10k_start+0x51/0x5c0 [ath10k_core]
 [] drv_start+0x38/0x140 [mac80211]
 [] ieee80211_do_open+0x2c5/0x990 [mac80211]
 [] ieee80211_open+0x50/0x60 [mac80211]
 [] __dev_open+0xaa/0x120
 [] __dev_change_flags+0x98/0x160
 [] dev_change_flags+0x24/0x60
 [] devinet_ioctl+0x5ee/0x6c0
 [] inet_ioctl+0x4b/0x70
 [] sock_do_ioctl+0x20/0x50
 [] sock_ioctl+0x1d6/0x2a0
 [] do_vfs_ioctl+0x8b/0x5b0
 [] ? __sys_recvmsg+0x3d/0x70
 [] SyS_ioctl+0x74/0x80
 [] entry_SYSCALL_64_fastpath+0x1e/0xad
Code: ff ff ff 89 c2 48 89 df 48 c7 c6 10 d3 49 a1 e8 34 1d f9 ff 48 89 df e8 2c f9 
ff ff 44 89 e0 c6 83 0e 74 02 00 01 5b 41 5c 5d c3 <0f> 0b 66 66 2e 0f
RIP  [] ath10k_pci_hif_power_up+0x173/0x180 [ath10k_pci]
 RSP 
---[ end trace b6dede286ed70e39 ]---


The BUG in question is this:

/**
 *  napi_enable - enable NAPI scheduling
 *  @n: NAPI context
 *
 * Resume NAPI from being scheduled on this context.
 * Must be paired with napi_disable.
 */
static inline void napi_enable(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, >state));
smp_mb__before_atomic();
clear_bit(NAPI_STATE_SCHED, >state);
clear_bit(NAPI_STATE_NPSVC, >state);
}


Any ideas what might be the cause of this?

Thanks,
Ben

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

Re: [PATCH] rt2x00: improve calling conventions for register accessors

2017-05-15 Thread David Miller 
From: Arnd Bergmann 
Date: Mon, 15 May 2017 16:36:45 +0200

> On Mon, May 15, 2017 at 4:28 PM, Stanislaw Gruszka  
> wrote:
>> On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote:
>>> With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
>>> stack usage (with a private patch set I have to turn on this warning,
>>> which I intend to get into the next kernel release):
>>>
>>> wireless/ralink/rt2x00/rt2800lib.c: In function 
>>> 'rt2800_bw_filter_calibration':
>>> wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 
>>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>>>
>>> The problem is that KASAN inserts a redzone around each local variable that
>>> gets passed by reference, and the newly added function has a lot of them.
>>> We can easily avoid that here by changing the calling convention to have
>>> the output as the return value of the function. This should also results in
>>> smaller object code, saving around 4KB in .text with KASAN, or 2KB without
>>> KASAN.
>>>
>>> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
>>> Signed-off-by: Arnd Bergmann 
>>> ---
>>>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 319 
>>> +
>>>  1 file changed, 164 insertions(+), 155 deletions(-)
>>
>> We have read(, ) calling convention since forever in rt2x00 and that
>> was never a problem. I dislike to change that now to make some tools
>> happy, I think problem should be fixed in the tools instead.
> 
> How about adding 'depends on !KASAN' in Kconfig instead?

Please let's not go down that route and make such facilities less
useful due to decreased coverage.

Thanks.

Re: [PATCH] rt2x00: improve calling conventions for register accessors

2017-05-15 Thread David Miller 
From: Stanislaw Gruszka 
Date: Mon, 15 May 2017 16:28:01 +0200

> On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote:
>> With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
>> stack usage (with a private patch set I have to turn on this warning,
>> which I intend to get into the next kernel release):
>> 
>> wireless/ralink/rt2x00/rt2800lib.c: In function 
>> 'rt2800_bw_filter_calibration':
>> wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 
>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>> 
>> The problem is that KASAN inserts a redzone around each local variable that
>> gets passed by reference, and the newly added function has a lot of them.
>> We can easily avoid that here by changing the calling convention to have
>> the output as the return value of the function. This should also results in
>> smaller object code, saving around 4KB in .text with KASAN, or 2KB without
>> KASAN.
>> 
>> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 319 
>> +
>>  1 file changed, 164 insertions(+), 155 deletions(-)
> 
> We have read(, ) calling convention since forever in rt2x00 and that
> was never a problem. I dislike to change that now to make some tools
> happy, I think problem should be fixed in the tools instead.

Passing return values by reference is and always has been a really
poor way to achieve what these functions are doing.

And frankly, whilst the tool could see what's going on here better, we
should be making code easier rather than more difficult to audit.

I am therefore very much in favor of Arnd's change.

This isn't even a situation where there are multiple return values,
such as needing to signal an error and return an unsigned value at the
same time.

These functions return _one_ value, and therefore they should be
returned as a true return value.

Thanks.

Re: [PATCH] rt2x00: improve calling conventions for register accessors

2017-05-15 Thread Arnd Bergmann 
On Mon, May 15, 2017 at 4:28 PM, Stanislaw Gruszka  wrote:
> On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote:
>> With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
>> stack usage (with a private patch set I have to turn on this warning,
>> which I intend to get into the next kernel release):
>>
>> wireless/ralink/rt2x00/rt2800lib.c: In function 
>> 'rt2800_bw_filter_calibration':
>> wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 
>> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>>
>> The problem is that KASAN inserts a redzone around each local variable that
>> gets passed by reference, and the newly added function has a lot of them.
>> We can easily avoid that here by changing the calling convention to have
>> the output as the return value of the function. This should also results in
>> smaller object code, saving around 4KB in .text with KASAN, or 2KB without
>> KASAN.
>>
>> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 319 
>> +
>>  1 file changed, 164 insertions(+), 155 deletions(-)
>
> We have read(, ) calling convention since forever in rt2x00 and that
> was never a problem. I dislike to change that now to make some tools
> happy, I think problem should be fixed in the tools instead.

How about adding 'depends on !KASAN' in Kconfig instead?

   Arnd

Re: [PATCH] rt2x00: improve calling conventions for register accessors

2017-05-15 Thread Stanislaw Gruszka 
On Mon, May 15, 2017 at 03:46:55PM +0200, Arnd Bergmann wrote:
> With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
> stack usage (with a private patch set I have to turn on this warning,
> which I intend to get into the next kernel release):
> 
> wireless/ralink/rt2x00/rt2800lib.c: In function 
> 'rt2800_bw_filter_calibration':
> wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 
> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
> 
> The problem is that KASAN inserts a redzone around each local variable that
> gets passed by reference, and the newly added function has a lot of them.
> We can easily avoid that here by changing the calling convention to have
> the output as the return value of the function. This should also results in
> smaller object code, saving around 4KB in .text with KASAN, or 2KB without
> KASAN.
> 
> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 319 
> +
>  1 file changed, 164 insertions(+), 155 deletions(-)

We have read(, ) calling convention since forever in rt2x00 and that
was never a problem. I dislike to change that now to make some tools
happy, I think problem should be fixed in the tools instead.

Stanislaw

[PATCH] rt2x00: improve calling conventions for register accessors

2017-05-15 Thread Arnd Bergmann 
With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
stack usage (with a private patch set I have to turn on this warning,
which I intend to get into the next kernel release):

wireless/ralink/rt2x00/rt2800lib.c: In function 'rt2800_bw_filter_calibration':
wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 bytes 
is larger than 1536 bytes [-Werror=frame-larger-than=]

The problem is that KASAN inserts a redzone around each local variable that
gets passed by reference, and the newly added function has a lot of them.
We can easily avoid that here by changing the calling convention to have
the output as the return value of the function. This should also results in
smaller object code, saving around 4KB in .text with KASAN, or 2KB without
KASAN.

Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 319 +
 1 file changed, 164 insertions(+), 155 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index d11c7b210e81..cafcf43436b9 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -203,10 +203,11 @@ static void rt2800_rfcsr_write_dccal(struct rt2x00_dev 
*rt2x00dev,
rt2800_rfcsr_write_bank(rt2x00dev, 7, reg, value);
 }
 
-static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int word, u8 *value)
+static u8 rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
+ const unsigned int word)
 {
u32 reg;
+   u8 value;
 
mutex_lock(>csr_mutex);
 
@@ -232,7 +233,7 @@ static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
WAIT_FOR_RFCSR_MT7620(rt2x00dev, );
}
 
-   *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
+   value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
break;
 
default:
@@ -247,17 +248,19 @@ static void rt2800_rfcsr_read(struct rt2x00_dev 
*rt2x00dev,
WAIT_FOR_RFCSR(rt2x00dev, );
}
 
-   *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
+   value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
break;
}
 
mutex_unlock(>csr_mutex);
+
+   return value;
 }
 
-static void rt2800_rfcsr_read_bank(struct rt2x00_dev *rt2x00dev, const u8 bank,
-  const unsigned int reg, u8 *value)
+static u8 rt2800_rfcsr_read_bank(struct rt2x00_dev *rt2x00dev, const u8 bank,
+  const unsigned int reg)
 {
-   rt2800_rfcsr_read(rt2x00dev, (reg | (bank << 6)), value);
+   return rt2800_rfcsr_read(rt2x00dev, (reg | (bank << 6)));
 }
 
 static void rt2800_rf_write(struct rt2x00_dev *rt2x00dev,
@@ -1225,6 +1228,12 @@ void rt2800_clear_beacon(struct queue_entry *entry)
 EXPORT_SYMBOL_GPL(rt2800_clear_beacon);
 
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
+static void rt2800_rfcsr_readreg(struct rt2x00_dev *rt2x00dev,
+const unsigned int word, u8 *value)
+{
+   *value = rt2800_rfcsr_read(rt2x00dev, word);
+}
+
 const struct rt2x00debug rt2800_rt2x00debug = {
.owner  = THIS_MODULE,
.csr= {
@@ -1260,7 +1269,7 @@ const struct rt2x00debug rt2800_rt2x00debug = {
.word_count = RF_SIZE / sizeof(u32),
},
.rfcsr  = {
-   .read   = rt2800_rfcsr_read,
+   .read   = rt2800_rfcsr_readreg,
.write  = rt2800_rfcsr_write,
.word_base  = RFCSR_BASE,
.word_size  = sizeof(u8),
@@ -2072,7 +2081,7 @@ static void rt2800_freq_cal_mode1(struct rt2x00_dev 
*rt2x00dev)
freq_offset = rt2x00_get_field8(rt2x00dev->freq_offset, RFCSR17_CODE);
freq_offset = min_t(u8, freq_offset, FREQ_OFFSET_BOUND);
 
-   rt2800_rfcsr_read(rt2x00dev, 17, );
+   rfcsr = rt2800_rfcsr_read(rt2x00dev, 17);
prev_rfcsr = rfcsr;
 
rt2x00_set_field8(, RFCSR17_CODE, freq_offset);
@@ -2174,23 +2183,23 @@ static void rt2800_config_channel_rf3xxx(struct 
rt2x00_dev *rt2x00dev,
 
rt2800_rfcsr_write(rt2x00dev, 2, rf->rf1);
 
-   rt2800_rfcsr_read(rt2x00dev, 3, );
+   rfcsr = rt2800_rfcsr_read(rt2x00dev, 3);
rt2x00_set_field8(, RFCSR3_K, rf->rf3);
rt2800_rfcsr_write(rt2x00dev, 3, rfcsr);
 
-   rt2800_rfcsr_read(rt2x00dev, 6, );
+   rfcsr = rt2800_rfcsr_read(rt2x00dev, 6);
rt2x00_set_field8(, RFCSR6_R1, rf->rf2);
rt2800_rfcsr_write(rt2x00dev, 6, rfcsr);
 
-   rt2800_rfcsr_read(rt2x00dev, 12, );
+   rfcsr = rt2800_rfcsr_read(rt2x00dev, 12);
rt2x00_set_field8(, RFCSR12_TX_POWER, info->default_power1);
rt2800_rfcsr_write(rt2x00dev, 12,

[PATCH v2 4/5] wil6210: add option to ignore OTA regulatory hints

2017-05-15 Thread Maya Erez 
On some platforms, the regulatory domain (country) is set
using mechanisms external to WIFI, such as cellular modem
and GPS. In these scenarios the regulatory hints that
are received over the air (in beacons and similar) can
conflict and even cause an incorrect country to be set.
Add an option to ignore the OTA regulatory hints to better
support such scenarios.

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

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 567fe43..0f297c0 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -26,6 +26,11 @@
 module_param(disable_ap_sme, bool, 0444);
 MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
 
+static bool ignore_reg_hints;
+module_param(ignore_reg_hints, bool, 0444);
+MODULE_PARM_DESC(ignore_reg_hints,
+" Ignore OTA regulatory hints (Default: false)");
+
 #define CHAN60G(_channel, _flags) {\
.band   = NL80211_BAND_60GHZ,   \
.center_freq= 56160 + (2160 * (_channel)),  \
@@ -1763,6 +1768,11 @@ static void wil_wiphy_init(struct wiphy *wiphy)
 
wiphy->n_vendor_commands = ARRAY_SIZE(wil_nl80211_vendor_commands);
wiphy->vendor_commands = wil_nl80211_vendor_commands;
+
+   if (ignore_reg_hints) {
+   wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS;
+   wiphy->regulatory_flags |= REGULATORY_COUNTRY_IE_IGNORE;
+   }
 }
 
 struct wireless_dev *wil_cfg80211_init(struct device *dev)
-- 
1.9.1

[PATCH v2 3/5] wil6210: Improve AP stop handling

2017-05-15 Thread Maya Erez 
From: Hamad Kadmany 

Set resetting flag early when stopping AP to avoid
disconnect events as a result of disconnect command
sent during AP stop procedure.

Signed-off-by: Hamad Kadmany 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index aa9ce30..567fe43 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -1446,6 +1446,8 @@ static int wil_cfg80211_stop_ap(struct wiphy *wiphy,
wil6210_bus_request(wil, WIL_DEFAULT_BUS_REQUEST_KBPS);
wil_set_recovery_state(wil, fw_recovery_idle);
 
+   set_bit(wil_status_resetting, wil->status);
+
mutex_lock(>mutex);
 
wmi_pcp_stop(wil);
-- 
1.9.1

[PATCH v2 2/5] wil6210: add option to load FTM FW

2017-05-15 Thread Maya Erez 
From: Hamad Kadmany 

Module parameter allows to load specific FW used
for FTM testing.

Signed-off-by: Hamad Kadmany 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/pcie_bus.c | 18 +-
 drivers/net/wireless/ath/wil6210/wil6210.h  |  9 +++--
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c 
b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index b38515f..33bd85c 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012-2016 Qualcomm Atheros, Inc.
+ * Copyright (c) 2012-2017 Qualcomm Atheros, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -26,6 +26,10 @@
 module_param(use_msi, bool, 0444);
 MODULE_PARM_DESC(use_msi, " Use MSI interrupt, default - true");
 
+static bool ftm_mode;
+module_param(ftm_mode, bool, 0444);
+MODULE_PARM_DESC(ftm_mode, " Set factory test mode, default - false");
+
 #ifdef CONFIG_PM
 #ifdef CONFIG_PM_SLEEP
 static int wil6210_pm_notify(struct notifier_block *notify_block,
@@ -36,13 +40,15 @@ static int wil6210_pm_notify(struct notifier_block 
*notify_block,
 static
 void wil_set_capabilities(struct wil6210_priv *wil)
 {
+   const char *wil_fw_name;
u32 jtag_id = wil_r(wil, RGF_USER_JTAG_DEV_ID);
u8 chip_revision = (wil_r(wil, RGF_USER_REVISION_ID) &
RGF_USER_REVISION_ID_MASK);
 
bitmap_zero(wil->hw_capabilities, hw_capability_last);
bitmap_zero(wil->fw_capabilities, WMI_FW_CAPABILITY_MAX);
-   wil->wil_fw_name = WIL_FW_NAME_DEFAULT;
+   wil->wil_fw_name = ftm_mode ? WIL_FW_NAME_FTM_DEFAULT :
+  WIL_FW_NAME_DEFAULT;
wil->chip_revision = chip_revision;
 
switch (jtag_id) {
@@ -51,9 +57,11 @@ void wil_set_capabilities(struct wil6210_priv *wil)
case REVISION_ID_SPARROW_D0:
wil->hw_name = "Sparrow D0";
wil->hw_version = HW_VER_SPARROW_D0;
-   if (wil_fw_verify_file_exists(wil,
- WIL_FW_NAME_SPARROW_PLUS))
-   wil->wil_fw_name = WIL_FW_NAME_SPARROW_PLUS;
+   wil_fw_name = ftm_mode ? WIL_FW_NAME_FTM_SPARROW_PLUS :
+ WIL_FW_NAME_SPARROW_PLUS;
+
+   if (wil_fw_verify_file_exists(wil, wil_fw_name))
+   wil->wil_fw_name = wil_fw_name;
break;
case REVISION_ID_SPARROW_B0:
wil->hw_name = "Sparrow B0";
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index b00c803..fe942ba 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -37,8 +37,13 @@
 extern bool disable_ap_sme;
 
 #define WIL_NAME "wil6210"
-#define WIL_FW_NAME_DEFAULT "wil6210.fw" /* code Sparrow B0 */
-#define WIL_FW_NAME_SPARROW_PLUS "wil6210_sparrow_plus.fw" /* code Sparrow D0 
*/
+
+#define WIL_FW_NAME_DEFAULT "wil6210.fw"
+#define WIL_FW_NAME_FTM_DEFAULT "wil6210_ftm.fw"
+
+#define WIL_FW_NAME_SPARROW_PLUS "wil6210_sparrow_plus.fw"
+#define WIL_FW_NAME_FTM_SPARROW_PLUS "wil6210_sparrow_plus_ftm.fw"
+
 #define WIL_BOARD_FILE_NAME "wil6210.brd" /* board & radio parameters */
 
 #define WIL_DEFAULT_BUS_REQUEST_KBPS 128000 /* ~1Gbps */
-- 
1.9.1

[PATCH v2 5/5] wil6210: support devices with different PCIe bar size

2017-05-15 Thread Maya Erez 
wil6210 devices can have different PCIe bar size, hence get the
bar size from PCIe device instead of using a constant bar size.

Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/ioctl.c|  4 ++--
 drivers/net/wireless/ath/wil6210/pcie_bus.c | 17 ++---
 drivers/net/wireless/ath/wil6210/wil6210.h  |  4 +++-
 drivers/net/wireless/ath/wil6210/wmi.c  |  4 ++--
 4 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/ioctl.c 
b/drivers/net/wireless/ath/wil6210/ioctl.c
index 6303800..1c49ad8 100644
--- a/drivers/net/wireless/ath/wil6210/ioctl.c
+++ b/drivers/net/wireless/ath/wil6210/ioctl.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 Qualcomm Atheros, Inc.
+ * Copyright (c) 2014,2017 Qualcomm Atheros, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -46,7 +46,7 @@ static void __iomem *wil_ioc_addr(struct wil6210_priv *wil, 
uint32_t addr,
}
 
off = a - wil->csr;
-   if (size >= WIL6210_MEM_SIZE - off) {
+   if (size >= wil->bar_size - off) {
wil_err(wil, "Requested block does not fit into memory: "
"off = 0x%08x size = 0x%08x\n", off, size);
return NULL;
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c 
b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 33bd85c..bf9f265 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -200,16 +200,18 @@ static int wil_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
.ramdump = wil_platform_rop_ramdump,
.fw_recovery = wil_platform_rop_fw_recovery,
};
+   u32 bar_size = pci_resource_len(pdev, 0);
 
/* check HW */
dev_info(>dev, WIL_NAME
-" device found [%04x:%04x] (rev %x)\n",
-(int)pdev->vendor, (int)pdev->device, (int)pdev->revision);
-
-   if (pci_resource_len(pdev, 0) != WIL6210_MEM_SIZE) {
-   dev_err(>dev, "Not " WIL_NAME "? "
-   "BAR0 size is %lu while expecting %lu\n",
-   (ulong)pci_resource_len(pdev, 0), WIL6210_MEM_SIZE);
+" device found [%04x:%04x] (rev %x) bar size 0x%x\n",
+(int)pdev->vendor, (int)pdev->device, (int)pdev->revision,
+bar_size);
+
+   if ((bar_size < WIL6210_MIN_MEM_SIZE) ||
+   (bar_size > WIL6210_MAX_MEM_SIZE)) {
+   dev_err(>dev, "Unexpected BAR0 size 0x%x\n",
+   bar_size);
return -ENODEV;
}
 
@@ -222,6 +224,7 @@ static int wil_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
 
wil->pdev = pdev;
pci_set_drvdata(pdev, wil);
+   wil->bar_size = bar_size;
/* rollback to if_free */
 
wil->platform_handle =
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index fe942ba..ca532c7 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -58,7 +58,8 @@ static inline u32 WIL_GET_BITS(u32 x, int b0, int b1)
return (x >> b0) & ((1 << (b1 - b0 + 1)) - 1);
 }
 
-#define WIL6210_MEM_SIZE (2*1024*1024UL)
+#define WIL6210_MIN_MEM_SIZE (2 * 1024 * 1024UL)
+#define WIL6210_MAX_MEM_SIZE (4 * 1024 * 1024UL)
 
 #define WIL_TX_Q_LEN_DEFAULT   (4000)
 #define WIL_RX_RING_SIZE_ORDER_DEFAULT (10)
@@ -599,6 +600,7 @@ struct blink_on_off_time {
 
 struct wil6210_priv {
struct pci_dev *pdev;
+   u32 bar_size;
struct wireless_dev *wdev;
void __iomem *csr;
DECLARE_BITMAP(status, wil_status_last);
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c 
b/drivers/net/wireless/ath/wil6210/wmi.c
index 814c356..93902cb 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -157,7 +157,7 @@ void __iomem *wmi_buffer(struct wil6210_priv *wil, __le32 
ptr_)
return NULL;
 
off = HOSTADDR(ptr);
-   if (off > WIL6210_MEM_SIZE - 4)
+   if (off > wil->bar_size - 4)
return NULL;
 
return wil->csr + off;
@@ -177,7 +177,7 @@ void __iomem *wmi_addr(struct wil6210_priv *wil, u32 ptr)
return NULL;
 
off = HOSTADDR(ptr);
-   if (off > WIL6210_MEM_SIZE - 4)
+   if (off > wil->bar_size - 4)
return NULL;
 
return wil->csr + off;
-- 
1.9.1

[PATCH v2 0/5] wil6210 patches

2017-05-15 Thread Maya Erez 
This set of patches include the following:
- Fix for "low level RF sector API" patch
- Addtotional wil6210 fixes

Hamad Kadmany (2):
  wil6210: add option to load FTM FW
  wil6210: Improve AP stop handling

Lior David (1):
  wil6210: low level RF sector API

Maya Erez (2):
  wil6210: add option to ignore OTA regulatory hints
  wil6210: support devices with different PCIe bar size

 drivers/net/wireless/ath/wil6210/cfg80211.c | 585 
 drivers/net/wireless/ath/wil6210/ioctl.c|   4 +-
 drivers/net/wireless/ath/wil6210/pcie_bus.c |  35 +-
 drivers/net/wireless/ath/wil6210/wil6210.h  |  13 +-
 drivers/net/wireless/ath/wil6210/wmi.c  |   4 +-
 5 files changed, 622 insertions(+), 19 deletions(-)

-- 
1.9.1

[PATCH v2 1/5] wil6210: low level RF sector API

2017-05-15 Thread Maya Erez 
From: Lior David 

Added vendor commands for low level control over
RF sectors. It allows user space a fine-grained control
over RF characteristics for TX and RX, such as direction
and gain of TX/RX. Main usages are debugging and diagnostics,
but also operational use cases.
API includes getting/setting a specific RF sector
configuration, as well as getting/setting the selected
sector which is used to communicate with a station.

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

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index fdaa99c..aa9ce30 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 #include "wil6210.h"
 #include "wmi.h"
 
@@ -41,6 +42,126 @@
 /* channel 4 not supported yet */
 };
 
+/* Vendor id to be used in vendor specific command and events
+ * to user space.
+ * NOTE: The authoritative place for definition of QCA_NL80211_VENDOR_ID,
+ * vendor subcmd definitions prefixed with QCA_NL80211_VENDOR_SUBCMD, and
+ * qca_wlan_vendor_attr is open source file src/common/qca-vendor.h in
+ * git://w1.fi/srv/git/hostap.git; the values here are just a copy of that
+ */
+
+#define QCA_NL80211_VENDOR_ID  0x001374
+
+#define WIL_MAX_RF_SECTORS (128)
+#define WIL_CID_ALL (0xff)
+
+enum qca_wlan_vendor_attr_rf_sector {
+   QCA_ATTR_MAC_ADDR = 6,
+   QCA_ATTR_PAD = 13,
+   QCA_ATTR_TSF = 29,
+   QCA_ATTR_DMG_RF_SECTOR_INDEX = 30,
+   QCA_ATTR_DMG_RF_SECTOR_TYPE = 31,
+   QCA_ATTR_DMG_RF_MODULE_MASK = 32,
+   QCA_ATTR_DMG_RF_SECTOR_CFG = 33,
+   QCA_ATTR_DMG_RF_SECTOR_MAX,
+};
+
+enum qca_wlan_vendor_attr_dmg_rf_sector_type {
+   QCA_ATTR_DMG_RF_SECTOR_TYPE_RX,
+   QCA_ATTR_DMG_RF_SECTOR_TYPE_TX,
+   QCA_ATTR_DMG_RF_SECTOR_TYPE_MAX
+};
+
+enum qca_wlan_vendor_attr_dmg_rf_sector_cfg {
+   QCA_ATTR_DMG_RF_SECTOR_CFG_INVALID = 0,
+   QCA_ATTR_DMG_RF_SECTOR_CFG_MODULE_INDEX,
+   QCA_ATTR_DMG_RF_SECTOR_CFG_ETYPE0,
+   QCA_ATTR_DMG_RF_SECTOR_CFG_ETYPE1,
+   QCA_ATTR_DMG_RF_SECTOR_CFG_ETYPE2,
+   QCA_ATTR_DMG_RF_SECTOR_CFG_PSH_HI,
+   QCA_ATTR_DMG_RF_SECTOR_CFG_PSH_LO,
+   QCA_ATTR_DMG_RF_SECTOR_CFG_DTYPE_X16,
+
+   /* keep last */
+   QCA_ATTR_DMG_RF_SECTOR_CFG_AFTER_LAST,
+   QCA_ATTR_DMG_RF_SECTOR_CFG_MAX =
+   QCA_ATTR_DMG_RF_SECTOR_CFG_AFTER_LAST - 1
+};
+
+static const struct
+nla_policy wil_rf_sector_policy[QCA_ATTR_DMG_RF_SECTOR_MAX + 1] = {
+   [QCA_ATTR_MAC_ADDR] = { .len = ETH_ALEN },
+   [QCA_ATTR_DMG_RF_SECTOR_INDEX] = { .type = NLA_U16 },
+   [QCA_ATTR_DMG_RF_SECTOR_TYPE] = { .type = NLA_U8 },
+   [QCA_ATTR_DMG_RF_MODULE_MASK] = { .type = NLA_U32 },
+   [QCA_ATTR_DMG_RF_SECTOR_CFG] = { .type = NLA_NESTED },
+};
+
+static const struct
+nla_policy wil_rf_sector_cfg_policy[QCA_ATTR_DMG_RF_SECTOR_CFG_MAX + 1] = {
+   [QCA_ATTR_DMG_RF_SECTOR_CFG_MODULE_INDEX] = { .type = NLA_U8 },
+   [QCA_ATTR_DMG_RF_SECTOR_CFG_ETYPE0] = { .type = NLA_U32 },
+   [QCA_ATTR_DMG_RF_SECTOR_CFG_ETYPE1] = { .type = NLA_U32 },
+   [QCA_ATTR_DMG_RF_SECTOR_CFG_ETYPE2] = { .type = NLA_U32 },
+   [QCA_ATTR_DMG_RF_SECTOR_CFG_PSH_HI] = { .type = NLA_U32 },
+   [QCA_ATTR_DMG_RF_SECTOR_CFG_PSH_LO] = { .type = NLA_U32 },
+   [QCA_ATTR_DMG_RF_SECTOR_CFG_DTYPE_X16] = { .type = NLA_U32 },
+};
+
+enum qca_nl80211_vendor_subcmds {
+   QCA_NL80211_VENDOR_SUBCMD_DMG_RF_GET_SECTOR_CFG = 139,
+   QCA_NL80211_VENDOR_SUBCMD_DMG_RF_SET_SECTOR_CFG = 140,
+   QCA_NL80211_VENDOR_SUBCMD_DMG_RF_GET_SELECTED_SECTOR = 141,
+   QCA_NL80211_VENDOR_SUBCMD_DMG_RF_SET_SELECTED_SECTOR = 142,
+};
+
+static int wil_rf_sector_get_cfg(struct wiphy *wiphy,
+struct wireless_dev *wdev,
+const void *data, int data_len);
+static int wil_rf_sector_set_cfg(struct wiphy *wiphy,
+struct wireless_dev *wdev,
+const void *data, int data_len);
+static int wil_rf_sector_get_selected(struct wiphy *wiphy,
+ struct wireless_dev *wdev,
+ const void *data, int data_len);
+static int wil_rf_sector_set_selected(struct wiphy *wiphy,
+ struct wireless_dev *wdev,
+ const void *data, int data_len);
+
+/* vendor specific commands */
+static const struct wiphy_vendor_command wil_nl80211_vendor_commands[] = {
+   {
+   .info.vendor_id = QCA_NL80211_VENDOR_ID,
+   .info.subcmd = QCA_NL80211_VENDOR_SUBCMD_DMG_RF_GET_SECTOR_CFG,
+   .flags = WIPHY_VENDOR_CMD_NEED_WDEV |

Re: [PATCH] iwlegacy: warn when enabling power save

2017-05-15 Thread Stanislaw Gruszka 
On Mon, May 15, 2017 at 11:25:51AM +0200, Arend van Spriel wrote:
> On 5/15/2017 11:20 AM, Stanislaw Gruszka wrote:
> >On Mon, May 15, 2017 at 11:41:05AM +0300, Kalle Valo wrote:
> >>Stanislaw Gruszka  writes:
> >>
> >>>iwlegacy firmware can crash when power save is configured. PS was
> >>>allowed in "dbdac2b iwlegacy: properly enable power saving" with belive
> >>>that user who enable PS is aware of that and can relate firmware crahes
> >>>with PS. However some distributions seems to enable PS without user
> >>>intervention, so warn about that.
> >>>
> >>>Signed-off-by: Stanislaw Gruszka 
> >>>---
> >>>  drivers/net/wireless/intel/iwlegacy/common.c |2 ++
> >>>  1 files changed, 2 insertions(+), 0 deletions(-)
> >>>
> >>>diff --git a/drivers/net/wireless/intel/iwlegacy/common.c 
> >>>b/drivers/net/wireless/intel/iwlegacy/common.c
> >>>index 140b6ea..6aaa0e7 100644
> >>>--- a/drivers/net/wireless/intel/iwlegacy/common.c
> >>>+++ b/drivers/net/wireless/intel/iwlegacy/common.c
> >>>@@ -5147,6 +5147,8 @@ void il_mac_flush(struct ieee80211_hw *hw, struct 
> >>>ieee80211_vif *vif,
> >>>   if (changed & (IEEE80211_CONF_CHANGE_PS | IEEE80211_CONF_CHANGE_IDLE)) {
> >>>   il->power_data.ps_disabled = !(conf->flags & IEEE80211_CONF_PS);
> >>>+  WARN_ONCE(!il->power_data.ps_disabled,
> >>>+"Enabling power save might cause firmware crashes\n");
> >>
> >>This prints the whole stack trace, right? Isn't that excessive and
> >>fooling the users to think that they found a bug, which would mean more
> >>bug reports sent to us? So maybe a simple printk is better here?
> >
> >I wanted to have back trace to assure problem will not be missed, but
> >I think you have right, I'll post v2.
> 
> I think instead of printk, a wiphy_warn() would be better here using
> hw->wiphy.

I used dev_warn variant, what is consistent with the driver code.

Stanislaw

Re: ath10k: controlling TX aggregation

2017-05-15 Thread Krishna Chaitanya 
On Fri, May 12, 2017 at 8:15 PM, Ben Greear  wrote:
> What chipset, and what firmware version?
>
> Thanks,
> Ben

Hi Ben,

I have missed your response. PFB details.

 chip: QCA986x/988x PCIe
 FW ver: 10.2.4.70.54 api 5
 kernel: 4.11.0-rc+7 (wireless-drivers-next)


> On 05/12/2017 07:43 AM, Krishna Chaitanya wrote:
>>
>> Hi,
>>
>> I am doing some comparative tests, wanted to configure common
>> settings btw all STA's. wanted to limit agg_size to 24 in ath10k with
>> the below command.
>>
>> echo "3 24" > /sys/kernel/debug/ieee80211/phy0/ath10k/htt_max_amsdu_ampdu
>>
>> The ADDBA request still has 64 and when i run iperf it is aggregating 64
>> frames.
>>
>> Except for 1 no number takes effect. If i configure 1 there is no ADDBA
>> exchange
>> initiated by ath10k.
>>
>> Is this expected? Can we control the aggregation size through driver?
>>
>> latest wireless-drivers-next and linux-firmware git is used.
>>
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com



-- 
Thanks,
Regards,
Chaitanya T K.

[PATCH v2] iwlegacy: warn when enabling power save

2017-05-15 Thread Stanislaw Gruszka 
iwlegacy firmware can crash when power save is configured. PS was
allowed in "dbdac2b iwlegacy: properly enable power saving" with belive
that user who enable PS is aware of that and can relate firmware crahes
with PS. However some distributions seems to enable PS without user
intervention, so warn about that.

Signed-off-by: Stanislaw Gruszka 
---
v1 -> v2: do not print call trace

 drivers/net/wireless/intel/iwlegacy/common.c |2 ++
 drivers/net/wireless/intel/iwlegacy/common.h |1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/common.c 
b/drivers/net/wireless/intel/iwlegacy/common.c
index 140b6ea..8d5acda 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -5147,6 +5147,8 @@ void il_mac_flush(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 
if (changed & (IEEE80211_CONF_CHANGE_PS | IEEE80211_CONF_CHANGE_IDLE)) {
il->power_data.ps_disabled = !(conf->flags & IEEE80211_CONF_PS);
+   if (!il->power_data.ps_disabled)
+   IL_WARN_ONCE("Enabling power save might cause firmware 
crashes\n");
ret = il_power_update_mode(il, false);
if (ret)
D_MAC80211("Error setting sleep level\n");
diff --git a/drivers/net/wireless/intel/iwlegacy/common.h 
b/drivers/net/wireless/intel/iwlegacy/common.h
index 3bba521..18c60c9 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.h
+++ b/drivers/net/wireless/intel/iwlegacy/common.h
@@ -45,6 +45,7 @@
 
 #define IL_ERR(f, a...) dev_err(>pci_dev->dev, f, ## a)
 #define IL_WARN(f, a...) dev_warn(>pci_dev->dev, f, ## a)
+#define IL_WARN_ONCE(f, a...) dev_warn_once(>pci_dev->dev, f, ## a)
 #define IL_INFO(f, a...) dev_info(>pci_dev->dev, f, ## a)
 
 #define RX_QUEUE_SIZE 256
-- 
1.7.1

Re: [PATCH] iwlegacy: warn when enabling power save

2017-05-15 Thread Arend van Spriel 

On 5/15/2017 11:20 AM, Stanislaw Gruszka wrote:

On Mon, May 15, 2017 at 11:41:05AM +0300, Kalle Valo wrote:

Stanislaw Gruszka  writes:


iwlegacy firmware can crash when power save is configured. PS was
allowed in "dbdac2b iwlegacy: properly enable power saving" with belive
that user who enable PS is aware of that and can relate firmware crahes
with PS. However some distributions seems to enable PS without user
intervention, so warn about that.

Signed-off-by: Stanislaw Gruszka 
---
  drivers/net/wireless/intel/iwlegacy/common.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/common.c 
b/drivers/net/wireless/intel/iwlegacy/common.c
index 140b6ea..6aaa0e7 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -5147,6 +5147,8 @@ void il_mac_flush(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
  
  	if (changed & (IEEE80211_CONF_CHANGE_PS | IEEE80211_CONF_CHANGE_IDLE)) {

il->power_data.ps_disabled = !(conf->flags & IEEE80211_CONF_PS);
+   WARN_ONCE(!il->power_data.ps_disabled,
+ "Enabling power save might cause firmware crashes\n");


This prints the whole stack trace, right? Isn't that excessive and
fooling the users to think that they found a bug, which would mean more
bug reports sent to us? So maybe a simple printk is better here?


I wanted to have back trace to assure problem will not be missed, but
I think you have right, I'll post v2.


I think instead of printk, a wiphy_warn() would be better here using 
hw->wiphy.


Regards,
Arend

Re: [PATCH] iwlegacy: warn when enabling power save

2017-05-15 Thread Stanislaw Gruszka 
On Mon, May 15, 2017 at 11:41:05AM +0300, Kalle Valo wrote:
> Stanislaw Gruszka  writes:
> 
> > iwlegacy firmware can crash when power save is configured. PS was
> > allowed in "dbdac2b iwlegacy: properly enable power saving" with belive
> > that user who enable PS is aware of that and can relate firmware crahes
> > with PS. However some distributions seems to enable PS without user
> > intervention, so warn about that.
> >
> > Signed-off-by: Stanislaw Gruszka 
> > ---
> >  drivers/net/wireless/intel/iwlegacy/common.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/wireless/intel/iwlegacy/common.c 
> > b/drivers/net/wireless/intel/iwlegacy/common.c
> > index 140b6ea..6aaa0e7 100644
> > --- a/drivers/net/wireless/intel/iwlegacy/common.c
> > +++ b/drivers/net/wireless/intel/iwlegacy/common.c
> > @@ -5147,6 +5147,8 @@ void il_mac_flush(struct ieee80211_hw *hw, struct 
> > ieee80211_vif *vif,
> >  
> > if (changed & (IEEE80211_CONF_CHANGE_PS | IEEE80211_CONF_CHANGE_IDLE)) {
> > il->power_data.ps_disabled = !(conf->flags & IEEE80211_CONF_PS);
> > +   WARN_ONCE(!il->power_data.ps_disabled,
> > + "Enabling power save might cause firmware crashes\n");
> 
> This prints the whole stack trace, right? Isn't that excessive and
> fooling the users to think that they found a bug, which would mean more
> bug reports sent to us? So maybe a simple printk is better here?

I wanted to have back trace to assure problem will not be missed, but
I think you have right, I'll post v2.

Thanks
Stanislaw

Re: [PATCH] iwlegacy: warn when enabling power save

2017-05-15 Thread Kalle Valo 
Stanislaw Gruszka  writes:

> iwlegacy firmware can crash when power save is configured. PS was
> allowed in "dbdac2b iwlegacy: properly enable power saving" with belive
> that user who enable PS is aware of that and can relate firmware crahes
> with PS. However some distributions seems to enable PS without user
> intervention, so warn about that.
>
> Signed-off-by: Stanislaw Gruszka 
> ---
>  drivers/net/wireless/intel/iwlegacy/common.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlegacy/common.c 
> b/drivers/net/wireless/intel/iwlegacy/common.c
> index 140b6ea..6aaa0e7 100644
> --- a/drivers/net/wireless/intel/iwlegacy/common.c
> +++ b/drivers/net/wireless/intel/iwlegacy/common.c
> @@ -5147,6 +5147,8 @@ void il_mac_flush(struct ieee80211_hw *hw, struct 
> ieee80211_vif *vif,
>  
>   if (changed & (IEEE80211_CONF_CHANGE_PS | IEEE80211_CONF_CHANGE_IDLE)) {
>   il->power_data.ps_disabled = !(conf->flags & IEEE80211_CONF_PS);
> + WARN_ONCE(!il->power_data.ps_disabled,
> +   "Enabling power save might cause firmware crashes\n");

This prints the whole stack trace, right? Isn't that excessive and
fooling the users to think that they found a bug, which would mean more
bug reports sent to us? So maybe a simple printk is better here?

-- 
Kalle Valo

Re: Cubieboard2 + hostapd + 100 wireless devices

2017-05-15 Thread Stanislaw Gruszka 
Hi

On Wed, May 10, 2017 at 04:30:35PM +0200, Marek Floriańczyk wrote:
> I'm running hostapd in debug mode now, and I have found station:
> 2c:3a:e8:00:33:e0
> That deauthenticate with AP, but I don't know why, 
> reason_code=3 "station is leaving (or has left) IBSS or ESS"

Not sure about ESP module, but mac80211 sends deauth frame with reason=3
among some other cases when system suspend.

Stanislaw

[PATCH] iwlegacy: warn when enabling power save

2017-05-15 Thread Stanislaw Gruszka 
iwlegacy firmware can crash when power save is configured. PS was
allowed in "dbdac2b iwlegacy: properly enable power saving" with belive
that user who enable PS is aware of that and can relate firmware crahes
with PS. However some distributions seems to enable PS without user
intervention, so warn about that.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/intel/iwlegacy/common.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/common.c 
b/drivers/net/wireless/intel/iwlegacy/common.c
index 140b6ea..6aaa0e7 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -5147,6 +5147,8 @@ void il_mac_flush(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 
if (changed & (IEEE80211_CONF_CHANGE_PS | IEEE80211_CONF_CHANGE_IDLE)) {
il->power_data.ps_disabled = !(conf->flags & IEEE80211_CONF_PS);
+   WARN_ONCE(!il->power_data.ps_disabled,
+ "Enabling power save might cause firmware crashes\n");
ret = il_power_update_mode(il, false);
if (ret)
D_MAC80211("Error setting sleep level\n");
-- 
1.7.1

Re: Participation in common kernel API recommendation?

2017-05-15 Thread Kalle Valo 
Arend Van Spriel  writes:

>> Would any members be interested in spending a one hour meeting with the
>> subcommittee to give some feedback on the recommendation? If so, please
>> let me know.
>
> Just throwing a wild idea at you. In the spirit of how the community
> works why not post it (on refer to some public link) on the mailing list
> for review to get the feedback.

Indeed. Much more time efficient and no need to have a call in some odd
time of the day.

-- 
Kalle Valo