Re: [PATCH v2 5/5] mwifiex: wait firmware dump complete during card remove process

[Brian Norris]

Hi,

On Thu, Oct 27, 2016 at 02:42:43PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu 
> 
> Wait for firmware dump complete in card remove function.
> For sdio interface, there are two diffenrent cases,
> card reset trigger sdio_work and firmware dump trigger sdio_work.
> Do code rearrangement for distinguish between these two cases.
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 
> ---
> v2: 1. Get rid of reset_triggered flag. Instead split the code and use
> __mwifiex_sdio_remove() (Brian Norris/Dmitry Torokhov)
> 2. "v1 4/5 mwifiex: firmware dump code rearrangement.." is dropped. So
> rebased accordingly.
> ---
>  drivers/net/wireless/marvell/mwifiex/pcie.c |  6 +-
>  drivers/net/wireless/marvell/mwifiex/sdio.c | 15 ---
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 9025af7..6c421ad 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -37,6 +37,9 @@ static struct mwifiex_if_ops pcie_ops;
>  
>  static struct semaphore add_remove_card_sem;
>  
> +static void mwifiex_pcie_work(struct work_struct *work);
> +static DECLARE_WORK(pcie_work, mwifiex_pcie_work);

This work_struct didn't need to be static in the first place; it should
be embedded in the 'card' and initialized during device init. Then once
you cancel the work in remove() (like this patch is doing) you can also
kill the cancel_work_sync() from the module_exit() path -- you really
shouldn't be doing work like this in the module_init()/module_exit(). It
all belongs in device init/teardown.

> +
>  static int
>  mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
>  size_t size, int flags)
> @@ -249,6 +252,8 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
>   if (!adapter || !adapter->priv_num)
>   return;
>  
> + cancel_work_sync(_work);

Hmm, actually what happens if we have !adapter? Then that means we've
already torn down the device (e.g., unregister_dev() -- except we
haven't quite fixed that bug, see the other patch series you sent out),
and so we'll never reach this. But that also means we haven't
synchronized any outstanding work.

So this really belongs in one of the earlier mwifiex callbacks
(unregister_dev()?), and not in the device remove() callback.

Same applies to sdio.c I think.

Brian

> +
>   if (user_rmmod && !adapter->mfg_mode) {
>  #ifdef CONFIG_PM_SLEEP
>   if (adapter->is_suspended)
> @@ -2716,7 +2721,6 @@ static void mwifiex_pcie_work(struct work_struct *work)
>   mwifiex_pcie_device_dump_work(save_adapter);
>  }
>  
> -static DECLARE_WORK(pcie_work, mwifiex_pcie_work);
>  /* This function dumps FW information */
>  static void mwifiex_pcie_device_dump(struct mwifiex_adapter *adapter)
>  {
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
> b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index 241d2b3..5d84c563 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -46,6 +46,9 @@
>   */
>  static u8 user_rmmod;
>  
> +static void mwifiex_sdio_work(struct work_struct *work);
> +static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
> +
>  static struct mwifiex_if_ops sdio_ops;
>  static unsigned long iface_work_flags;
>  
> @@ -275,7 +278,7 @@ static int mwifiex_sdio_resume(struct device *dev)
>   * This function removes the interface and frees up the card structure.
>   */
>  static void
> -mwifiex_sdio_remove(struct sdio_func *func)
> +__mwifiex_sdio_remove(struct sdio_func *func)
>  {
>   struct sdio_mmc_card *card;
>   struct mwifiex_adapter *adapter;
> @@ -305,6 +308,13 @@ mwifiex_sdio_remove(struct sdio_func *func)
>   mwifiex_remove_card(card->adapter, _remove_card_sem);
>  }
>  
> +static void
> +mwifiex_sdio_remove(struct sdio_func *func)
> +{
> + cancel_work_sync(_work);
> + __mwifiex_sdio_remove(func);
> +}
> +
>  /*
>   * SDIO suspend.
>   *
> @@ -2290,7 +2300,7 @@ static void mwifiex_recreate_adapter(struct 
> sdio_mmc_card *card)
>* discovered and initializes them from scratch.
>*/
>  
> - mwifiex_sdio_remove(func);
> + __mwifiex_sdio_remove(func);
>  
>   /* power cycle the adapter */
>   sdio_claim_host(func);
> @@ -2623,7 +2633,6 @@ static void mwifiex_sdio_work(struct work_struct *work)
>   mwifiex_sdio_card_reset_work(save_adapter);
>  }
>  
> -static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
>  /* This function resets the card */
>  static void mwifiex_sdio_card_reset(struct mwifiex_adapter *adapter)
>  {
> -- 
> 1.9.1
> 

Re: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting

[Johannes Berg]

> Pardon a dumb question, but can filtering be turned off?  I doubt
> anyone would want to, but just wondering.

Generally I assume that a typical device/firmware will be able to turn
it off (I know ours can), but we don't think we even provide a knob for
it for anyone to request it, so you'd have to modify the driver.

> Is there anything you have in mind?  Our goal is to minimize 
> hardware-kernel-userspace wakeups.  With the nl80211 API as it is
> today, it doesn't seem feasible to do anything besides
> polling.  Whatever we come up with will surely be better than that.

I was thinking of just providing two thresholds, since you should be
able to emulate more of them with that, without much cost.

> So you're thinking of having high and low threshold.  So we'd get an 
> event when we're higher than the high threshold and lower than the
> low threshold, right?  

I'm mostly handwaving, but yes.

> Then we'd need to bootstrap our current rssi somehow, or do we get
> another event?  I'm guessing we're going to have some race condition
> issues?

Generally, with CQM, when you initially program it you get an event
telling you where you're at right now - so hopefully you'd get "middle"
(rather than "low"/"high") with the actual signal falling squarely into
your range, and from there on you're pretty much good to go.

> Would using an n-threshold API be possible?  That way user space can 
> program in whatever threholds once, and then the kernel would figure
> out how to support that given the relevant hardware capabilities.

That seems like a reasonable idea. We'd want to have code in cfg80211
that does the emulation as we discussed above, so that from a userspace
POV an "arbitrary" number of thresholds is supported (if the capability
is supported at all, which would depend on the device doing >=2
thresholds).

johannes

Re: [PATCH v2 1/5] mwifiex: remove redundant condition in main process

[Brian Norris]

On Thu, Oct 27, 2016 at 02:42:39PM +0530, Amitkumar Karwar wrote:
> This condition while calling mwifiex_check_ps_cond() is redundant.
> The function internally already takes care of it.
> 
> Signed-off-by: Amitkumar Karwar 
> ---
> v2: Same as v1

You've omitted the Reviewed-by tags from v1:

Reviewed-by: Brian Norris 

Re: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting

[Denis Kenzior]

Hi Johannes,

> Huh? No, beacon filtering is implemented by a lot of drivers today.

Pardon a dumb question, but can filtering be turned off?  I doubt anyone 
would want to, but just wondering.





The userspace switches count too and are the main motivation for this
patch.  Eventually, as you say, things will depend on specific
drivers and you will want to optimise whatever you can assuming the
hardware you're constrained to.


Yes and no. I think we can probably define a reasonable subset that
you'd expect more devices to implement. I don't really see the
requirement to do the "banding" that you did here offloaded - doing it
in mac80211 won't help much, and won't work in cases where you have
beacon filtering already anyway.


Is there anything you have in mind?  Our goal is to minimize 
hardware-kernel-userspace wakeups.  With the nl80211 API as it is today, 
it doesn't seem feasible to do anything besides polling.  Whatever we 
come up with will surely be better than that.



Well, ok, technically the API can be implemented on top of drivers with
low/high thresholds, by doing the configuration according to the
current range you're in.


So you're thinking of having high and low threshold.  So we'd get an 
event when we're higher than the high threshold and lower than the low 
threshold, right?  Then we'd need to bootstrap our current rssi somehow, 
or do we get another event?  I'm guessing we're going to have some race 
condition issues?




I would argue though that it makes more sense to expose a simpler
capability (e.g. two instead of the current single threshold) and do
the reprogramming from higher layers. That ends up being more flexible,
since you can then, for example, also have ranges that aren't all
identical - which makes some sense because above a certain level you
don't really care at all.


It seems like we'd be limiting ourselves here.  Couple reasons that come 
to mind:
- This would still require user space to keep re-setting the new 
thresholds.  While the wakeups are much less frequent than with polling 
for example, they still add up.  Scheduling userspace, processing 
nl80211 messages, etc is still a cost.
- It feels like we're exposing a lowest-common-denominator API with no 
possibility of offload / optimization in the future.  E.g. even drivers 
that can support arbitrary number of thresholds will be boxed in.


Would using an n-threshold API be possible?  That way user space can 
program in whatever threholds once, and then the kernel would figure out 
how to support that given the relevant hardware capabilities.





In short a nl80211 change would be needed regardless of the mechanism
chosen.


Agree. I'm just not convinced that the banding mechanism you propose is
the most reasonable choice for new API.



Understood, but it was just a stab in the dark to get this discussion 
started.


Regards,
-Denis

Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

[Dmitry Torokhov]

Hi Amit,

On Thu, Oct 27, 2016 at 02:42:40PM +0530, Amitkumar Karwar wrote:
> This variable is guarded by spinlock at all other places. This patch
> takes care of missing spinlock usage in mwifiex_shutdown_drv().

Since in the previous discussion you stated that we inhibit interrupts
and flush the workqueue so that mwifiex_shutdown_drv() can't run
simultaneously with the main processing routine, why do we need this?

Instead please remove call to mwifiex_shutdown_drv() in the main routine
and "if (adapter->mwifiex_processing)" check here.

Thanks.

> 
> Signed-off-by: Amitkumar Karwar 
> ---
> v2: Same as v1
> ---
>  drivers/net/wireless/marvell/mwifiex/init.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
> b/drivers/net/wireless/marvell/mwifiex/init.c
> index 82839d9..8e5e424 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -670,11 +670,14 @@ mwifiex_shutdown_drv(struct mwifiex_adapter *adapter)
>  
>   adapter->hw_status = MWIFIEX_HW_STATUS_CLOSING;
>   /* wait for mwifiex_process to complete */
> + spin_lock_irqsave(>main_proc_lock, flags);
>   if (adapter->mwifiex_processing) {
> + spin_unlock_irqrestore(>main_proc_lock, flags);
>   mwifiex_dbg(adapter, WARN,
>   "main process is still running\n");
>   return ret;
>   }
> + spin_unlock_irqrestore(>main_proc_lock, flags);
>  
>   /* cancel current command */
>   if (adapter->curr_cmd) {
> -- 
> 1.9.1
> 

-- 
Dmitry

Re: [RFC] mac80211: set wifi_acked[_valid] bits for transmitted SKBs

[Dave Taht]

On Thu, Oct 27, 2016 at 7:21 AM, Johannes Berg
 wrote:
> From: Johannes Berg 
>
> There may be situations in which the in-kernel originator of an
> SKB cares about its wifi transmission status. To have that, set
> the wifi_acked[_valid] bits before freeing/orphaning the SKB if
> the destructor is set. The originator can then use it in there.
>
> Signed-off-by: Johannes Berg 
> ---
>  net/mac80211/status.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/net/mac80211/status.c b/net/mac80211/status.c
> index ddf71c648cab..dc3132d0effe 100644
> --- a/net/mac80211/status.c
> +++ b/net/mac80211/status.c
> @@ -541,6 +541,11 @@ static void ieee80211_report_used_skb(struct 
> ieee80211_local *local,
> } else if (info->ack_frame_id) {
> ieee80211_report_ack_skb(local, info, acked, dropped);
> }
> +
> +   if (!dropped && skb->destructor) {
> +   skb->wifi_acked_valid = 1;
> +   skb->wifi_acked = acked;
> +   }
>  }

One of the things I've been curious about one day trying to take advantage of
is the pacing available from sch_fq, in a world where we were trying
to take advantage of the chocolatey goodness of the new TCP BBR
congestion control algorithm. (sch_fq is apparently required for BBR
to work right)

By moving the fq_codel algo into the softmac layer as we are doing, we
currently expose the "noqueue" interface to the qdisc layer, there, which
works great for routers, but for dual use (acting as a NAS host and
routing) seems less than ideal.

Now it turns out that you can indeed slap the fq qdisc on top of the
new wifi intermediate queues code...

dave@nemesis:~/slashdot$ tc -s qdisc show dev wlp3s0
qdisc fq 8001: root refcnt 5 limit 1p flow_limit 100p buckets 1024
orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay
40.0ms
 Sent 30828141202 bytes 20530733 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  1127 flows (1127 inactive, 0 throttled)
  0 gc, 117 highprio, 714646 throttled

but as 1127 inactive flows have been there for a day now, and don't
show up in netstat, I guess that somewhere in here we aren't
"retiring" a skb in a way the tcp stack understands.

root@nemesis:~/slashdot# tc qdisc del dev wlp3s0 root
root@nemesis:~/slashdot# tc -s qdisc show dev wlp3s0
qdisc noqueue 0: root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0





>
>  /*
> --
> 2.9.3
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: pull-request: iwlwifi-next 2016-10-25-2

[Kalle Valo]

Luca Coelho  writes:

> Hi Kalle,
>
> Here's an updated pull-request, replacing 2016-10-25, with one commit
> message reworded, as you requested.
>
> I sent v2 of that patch to the linux-wireless mailing list.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 15b95a15950238eff4d7f24be1716086eea67835:
>
>   Merge ath-next from 
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2016-09-28 
> 16:37:33 +0300)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2016-10-25-2

Pulled, thanks.

-- 
Kalle Valo

wireless-drivers-next open for 4.10

[Kalle Valo]

Delayed due to my trip last week but wireless-drivers-next is now open
for new features going to 4.10.

wireless-drivers remains open for important fixes for 4.9.

-- 
Kalle Valo

Re: [19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap

[Kalle Valo]

Arnd Bergmann  wrote:
> A bugfix added a sanity check around the assignment and use of the
> 'is_11d' variable, which looks correct to me, but as the function is
> rather complex already, this confuses the compiler to the point where
> it can no longer figure out if the variable is always initialized
> correctly:
> 
> brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
> brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This adds an initialization for the newly introduced case in which
> the variable should not really be used, in order to make the warning
> go away.
> 
> Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
> Cc: Hante Meuleman 
> Cc: Arend van Spriel 
> Cc: Kalle Valo 
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers.git, thanks.

d3532ea6ce4e brcmfmac: avoid maybe-uninitialized warning in 
brcmf_cfg80211_start_ap

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [NOT FOR MERGE] ath9k: work around key cache corruption

[Johannes Berg]

On Thu, 2016-10-27 at 09:54 +0200, Sebastian Gottschall wrote:
> all patches have a unclear license since most patches are not comming
> with any licence declaration ;-)

You should read the DCO some time. Maybe you shouldn't be sending
patches if you think so.

johannes

Re: pull-request: iwlwifi 2016-10-25

[Kalle Valo]

Luca Coelho  writes:

> Hi Kalle,
>
> Here are 7 patches intended for 4.9.  They fix some small issues, as
> described in the tag itself.  I sent them out for review on 2016-10-19, 
> and pushed to a pending branch.  Kbuildbot didn't find any issues.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 1ea2643961b0d1b8d0e4a11af5aa69b0f92d0533:
>
>   ath6kl: add Dell OEM SDIO I/O for the Venue 8 Pro (2016-10-13 14:16:33 
> +0300)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
> tags/iwlwifi-for-kalle-2016-10-25

Pulled, thanks.

-- 
Kalle Valo

Re: [NOT FOR MERGE] ath9k: work around key cache corruption

[Sebastian Gottschall]

all patches have a unclear license since most patches are not comming 
with any licence declaration ;-)


Am 27.10.2016 um 08:02 schrieb Kalle Valo:

Antonio Quartulli  writes:


On Wed, Oct 26, 2016 at 05:05:14PM +0300, Kalle Valo wrote:

Antonio Quartulli  writes:


From: Antonio Quartulli 

This patch was crafted long time ago to work around a key cache
corruption problem on ath9k chipsets.

The workaround consists in periodically triggering a worker that
uploads all the keys to the HW cache. The worker is triggered also
when the vif detects 21 undecryptable packets.


This patch is based on top compat-wireless-2015-10-26.


I was asked to release this code to the public and, since it is
GPL, I am now doing it.

GPL? AFAICS ath9k is under ISC. I'm not sure what you mean with the
sentence above, but it's possible to interpret it so that this patch is
not under ISC license, which is problematic.

Honestly, my sentence was just a way to say "it makes sense to release this
patch to the public".

I was suspecting it was like that, I just wasn't sure.


If it needs to be ISC in order to be merged, then it can be released under ISC.

I don't want to enter a legal case :)

Me neither. But I can't apply patches with unclear license.




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 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: Outdated wl12xx firmwares

[Gary Bisson]

Hi,

Adding linux-wireless in CC, hoping to get more traction.

Just checked the MAINTAINERS file of this driver and it is listed as
'Orphan', so is it ok if a non-TI person submits the up-to-date
firmware files?

Regards,
Gary

On Fri, Oct 14, 2016 at 7:32 PM, Gary Bisson
 wrote:
> Hi,
>
> I am wondering why the w127x and wl128x firmware files have not been
> updated to their latest version (since Jan 2014)?
>
> The current version in the linux-firmware repo are:
> - 6.3.10.0.133 for single-role
> - 6.5.7.0.42 for multi-role
>
> Looking at TI's forum[1], they recommend using the latest one to avoid
> issues like firmware reload:
> - 6.3.10.0.139 for single-role
> - 6.5.7.0.47 for multi-role
>
> The up-to-date firmware files can be found in the following repo:
> https://github.com/TI-OpenLink/ti-utils/tree/master/hw/firmware
>
> What is the procedure to update them, does it need to be a TI employee
> that sends the patch? The former wl12xx maintainer (Luciano Coelho)
> seems to work for Intel now.
>
> Regards,
> Gary
>
> [1] 
> https://e2e.ti.com/support/wireless_connectivity/wilink_wifi_bluetooth/f/307/p/350832/1236099#1236099

Re: [PATCH v2 0/9] cfg80211/mac80211: Fast Initial Link Setup (IEEE 802.11ai)

[Johannes Berg]

On Thu, 2016-10-27 at 00:41 +0300, Jouni Malinen wrote:
> [...]

> This series covers only the FILS authentication/association
> functionality from IEEE 802.11ai, i.e., the other changes like
> scanning optimizations are not included.
> 

Applied, thanks.

johannes

[RFC] mac80211: set wifi_acked[_valid] bits for transmitted SKBs

[Johannes Berg]

From: Johannes Berg 

There may be situations in which the in-kernel originator of an
SKB cares about its wifi transmission status. To have that, set
the wifi_acked[_valid] bits before freeing/orphaning the SKB if
the destructor is set. The originator can then use it in there.

Signed-off-by: Johannes Berg 
---
 net/mac80211/status.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index ddf71c648cab..dc3132d0effe 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -541,6 +541,11 @@ static void ieee80211_report_used_skb(struct 
ieee80211_local *local,
} else if (info->ack_frame_id) {
ieee80211_report_ack_skb(local, info, acked, dropped);
}
+
+   if (!dropped && skb->destructor) {
+   skb->wifi_acked_valid = 1;
+   skb->wifi_acked = acked;
+   }
 }
 
 /*
-- 
2.9.3

Re: [PATCH v6 3/4] cfg80211: configure multicast to unicast for AP interfaces

[Johannes Berg]

On Mon, 2016-10-10 at 19:12 +0200, Michael Braun wrote:
> This add a userspace toggle to configure multicast to unicast.
> 

I applied this, with a bunch of fixes and documentation improvements.

johannes

pull-request: mac80211 2016-10-27

[Johannes Berg]

Hi Dave,

Before I go off for LPC and the workshop and everything, I have
two fixes. Neither is very important, but I figured I'd get them
out since I won't have any others soon.

Let me know if there's any problem.

Thanks,
johannes



The following changes since commit b4f0fd4baa90ecce798e0d26d1cce8f4457f2028:

  qed: Use list_move_tail instead of list_del/list_add_tail (2016-10-18 
16:40:41 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2016-10-27

for you to fetch changes up to b4f7f4ad425a84fd5d40da21aff8681997b25ff9:

  mac80211: fix some sphinx warnings (2016-10-26 08:01:07 +0200)


Just two fixes:
 * a fix to process all events while suspending, so any
   potential calls into the driver are done before it is
   suspended
 * small markup fixes for the sphinx documentation conversion
   that's coming into the tree via the doc tree


Jani Nikula (1):
  mac80211: fix some sphinx warnings

Johannes Berg (1):
  cfg80211: process events caused by suspend before suspending

 include/net/mac80211.h | 21 +
 net/wireless/sysfs.c   |  5 -
 2 files changed, 17 insertions(+), 9 deletions(-)

Re: [PATCH v2] cfg80211: Add support to update connection parameters

[Johannes Berg]

On Thu, 2016-10-27 at 16:51 +0300, Jouni Malinen wrote:
> From: vamsi krishna 
> 
> Add functionality to update the connection parameters when in
> connected
> state, so that driver/firmware uses the updated parameters for
> subsequent roaming. This is for drivers that support internal BSS
> selection and roaming. The new command does not change the current
> association state, i.e., it can be used to update IE contents for
> future
> (re)associations without causing an immediate disassociation or
> reassociation with the current BSS.
> 
> [...]

applied.

johannes

[PATCH v2] cfg80211: Add support to update connection parameters

[Jouni Malinen]

From: vamsi krishna 

Add functionality to update the connection parameters when in connected
state, so that driver/firmware uses the updated parameters for
subsequent roaming. This is for drivers that support internal BSS
selection and roaming. The new command does not change the current
association state, i.e., it can be used to update IE contents for future
(re)associations without causing an immediate disassociation or
reassociation with the current BSS.

This commit implements the required functionality for updating IEs for
(Re)Association Request frame only. Other parameters can be added in
future when required.

Signed-off-by: vamsi krishna 
Signed-off-by: Jouni Malinen 
---
 include/net/cfg80211.h   | 24 
 include/uapi/linux/nl80211.h |  7 +++
 net/wireless/nl80211.c   | 39 +++
 net/wireless/rdev-ops.h  | 12 
 net/wireless/trace.h | 18 ++
 5 files changed, 100 insertions(+)

v2:
- Address the comments from Arend and Johannes:
  * replace _valid struct with u32 changed
  * fix couple of typos in the comments
  * remove unnecessary wrapper function from sme.c
  * use C99 initializer to clear struct data
  * use wdev_lock/unlock() around the current_bss check and driver call
- fix EOPNOTSUPP logic in nl80211_update_connect_params()

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 41ae3f5..c575583 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2051,6 +2051,18 @@ struct cfg80211_connect_params {
 };
 
 /**
+ * enum cfg80211_connect_params_changed - Connection parameters being updated
+ *
+ * This enum provides information of all connect parameters that
+ * have to be updated as part of update_connect_params() call.
+ *
+ * @UPDATE_ASSOC_IES: Indicates whether association request IEs are updated
+ */
+enum cfg80211_connect_params_changed {
+   UPDATE_ASSOC_IES= BIT(0),
+};
+
+/**
  * enum wiphy_params_flags - set_wiphy_params bitfield values
  * @WIPHY_PARAM_RETRY_SHORT: wiphy->retry_short has changed
  * @WIPHY_PARAM_RETRY_LONG: wiphy->retry_long has changed
@@ -2571,6 +2583,14 @@ struct cfg80211_nan_func {
  * cases, the result of roaming is indicated with a call to
  * cfg80211_roamed() or cfg80211_roamed_bss().
  * (invoked with the wireless_dev mutex held)
+ * @update_connect_params: Update the connect parameters while connected to a
+ * BSS. The updated parameters can be used by driver/firmware for
+ * subsequent BSS selection (roaming) decisions and to form the
+ * Authentication/(Re)Association Request frames. This call does not
+ * request an immediate disassociation or reassociation with the current
+ * BSS, i.e., this impacts only subsequent (re)associations. The bits in
+ * changed are defined in  cfg80211_connect_params_changed.
+ * (invoked with the wireless_dev mutex held)
  * @disconnect: Disconnect from the BSS/ESS or stop connection attempts if
  *  connection is in progress. Once done, call cfg80211_disconnected() in
  *  case connection was already established (invoked with the
@@ -2858,6 +2878,10 @@ struct cfg80211_ops {
 
int (*connect)(struct wiphy *wiphy, struct net_device *dev,
   struct cfg80211_connect_params *sme);
+   int (*update_connect_params)(struct wiphy *wiphy,
+struct net_device *dev,
+struct cfg80211_connect_params *sme,
+u32 changed);
int (*disconnect)(struct wiphy *wiphy, struct net_device *dev,
  u16 reason_code);
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index e21d23d..67b464f 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -888,6 +888,11 @@
  * This will contain a %NL80211_ATTR_NAN_MATCH nested attribute and
  * %NL80211_ATTR_COOKIE.
  *
+ * @NL80211_CMD_UPDATE_CONNECT_PARAMS: Update one or more connect parameters
+ * for subsequent roaming cases if the driver or firmware uses internal
+ * BSS selection. This command can be issued only while connected and it
+ * does not result in a change for the current association.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -1085,6 +1090,8 @@ enum nl80211_commands {
 
NL80211_CMD_SET_MULTICAST_TO_UNICAST,
 
+   NL80211_CMD_UPDATE_CONNECT_PARAMS,
+
/* add new commands above here */
 
/* used to define NL80211_CMD_MAX below */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 46b2e8c..26821d4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8778,6 +8778,37 @@ static int nl80211_connect(struct sk_buff *skb, struct 
genl_info 

[PATCH v2 1/5] mwifiex: remove redundant condition in main process

[Amitkumar Karwar]

This condition while calling mwifiex_check_ps_cond() is redundant.
The function internally already takes care of it.

Signed-off-by: Amitkumar Karwar 
---
v2: Same as v1
---
 drivers/net/wireless/marvell/mwifiex/main.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 2478ccd..3b31ea2 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -355,10 +355,8 @@ process_start:
 
/* Check if we need to confirm Sleep Request
   received previously */
-   if (adapter->ps_state == PS_STATE_PRE_SLEEP) {
-   if (!adapter->cmd_sent && !adapter->curr_cmd)
-   mwifiex_check_ps_cond(adapter);
-   }
+   if (adapter->ps_state == PS_STATE_PRE_SLEEP)
+   mwifiex_check_ps_cond(adapter);
 
/* * The ps_state may have been changed during processing of
 * Sleep Request event.
-- 
1.9.1

[PATCH v2 4/5] mwifiex: get rid of drv_info* adapter variables

[Amitkumar Karwar]

From: Xinming Hu 

We can avoid drv_info_dump and drv_info_size adapter variables.
This info can be passed to mwifiex_upload_device_dump() as parameters

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
v2: This patch is introduced in v2. 
Also, I have dropped "v1 4/5 mwifiex: firmware dump code rearrangement
in pcie.c" patch in this series to avoid rebase efforts for other patches
from Rajat/Brian in queue. I will submit this later.
---
 drivers/net/wireless/marvell/mwifiex/main.c | 42 -
 drivers/net/wireless/marvell/mwifiex/main.h |  7 +++--
 drivers/net/wireless/marvell/mwifiex/pcie.c |  7 +++--
 drivers/net/wireless/marvell/mwifiex/sdio.c |  6 +++--
 4 files changed, 29 insertions(+), 33 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 3b31ea2..158305f 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1031,7 +1031,7 @@ void mwifiex_multi_chan_resync(struct mwifiex_adapter 
*adapter)
 }
 EXPORT_SYMBOL_GPL(mwifiex_multi_chan_resync);
 
-void mwifiex_drv_info_dump(struct mwifiex_adapter *adapter)
+int mwifiex_drv_info_dump(struct mwifiex_adapter *adapter, void **drv_info)
 {
void *p;
char drv_version[64];
@@ -1041,21 +1041,17 @@ void mwifiex_drv_info_dump(struct mwifiex_adapter 
*adapter)
int i, idx;
struct netdev_queue *txq;
struct mwifiex_debug_info *debug_info;
-
-   if (adapter->drv_info_dump) {
-   vfree(adapter->drv_info_dump);
-   adapter->drv_info_dump = NULL;
-   adapter->drv_info_size = 0;
-   }
+   void *drv_info_dump;
 
mwifiex_dbg(adapter, MSG, "===mwifiex driverinfo dump start===\n");
 
-   adapter->drv_info_dump = vzalloc(MWIFIEX_DRV_INFO_SIZE_MAX);
+   /* memory allocate here should be free in mwifiex_upload_device_dump*/
+   drv_info_dump = vzalloc(MWIFIEX_DRV_INFO_SIZE_MAX);
 
-   if (!adapter->drv_info_dump)
-   return;
+   if (!drv_info_dump)
+   return 0;
 
-   p = (char *)(adapter->drv_info_dump);
+   p = (char *)(drv_info_dump);
p += sprintf(p, "driver_name = " "\"mwifiex\"\n");
 
mwifiex_drv_get_driver_version(adapter, drv_version,
@@ -1139,18 +1135,20 @@ void mwifiex_drv_info_dump(struct mwifiex_adapter 
*adapter)
kfree(debug_info);
}
 
-   adapter->drv_info_size = p - adapter->drv_info_dump;
mwifiex_dbg(adapter, MSG, "===mwifiex driverinfo dump end===\n");
+   *drv_info = drv_info_dump;
+   return p - drv_info_dump;
 }
 EXPORT_SYMBOL_GPL(mwifiex_drv_info_dump);
 
-void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter)
+void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void 
*drv_info,
+   int drv_info_size)
 {
u8 idx, *dump_data, *fw_dump_ptr;
u32 dump_len;
 
dump_len = (strlen("Start dump driverinfo\n") +
-  adapter->drv_info_size +
+  drv_info_size +
   strlen("\nEnd dump\n"));
 
for (idx = 0; idx < adapter->num_mem_types; idx++) {
@@ -1180,8 +1178,8 @@ void mwifiex_upload_device_dump(struct mwifiex_adapter 
*adapter)
 
strcpy(fw_dump_ptr, "Start dump driverinfo\n");
fw_dump_ptr += strlen("Start dump driverinfo\n");
-   memcpy(fw_dump_ptr, adapter->drv_info_dump, adapter->drv_info_size);
-   fw_dump_ptr += adapter->drv_info_size;
+   memcpy(fw_dump_ptr, drv_info, drv_info_size);
+   fw_dump_ptr += drv_info_size;
strcpy(fw_dump_ptr, "\nEnd dump\n");
fw_dump_ptr += strlen("\nEnd dump\n");
 
@@ -1219,18 +1217,12 @@ done:
struct memory_type_mapping *entry =
>mem_type_mapping_tbl[idx];
 
-   if (entry->mem_ptr) {
-   vfree(entry->mem_ptr);
-   entry->mem_ptr = NULL;
-   }
+   vfree(entry->mem_ptr);
+   entry->mem_ptr = NULL;
entry->mem_size = 0;
}
 
-   if (adapter->drv_info_dump) {
-   vfree(adapter->drv_info_dump);
-   adapter->drv_info_dump = NULL;
-   adapter->drv_info_size = 0;
-   }
+   vfree(drv_info);
 }
 EXPORT_SYMBOL_GPL(mwifiex_upload_device_dump);
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index d61fe3a..a4aca45 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -990,8 +990,6 @@ struct mwifiex_adapter {
u8 key_api_major_ver, key_api_minor_ver;
struct memory_type_mapping *mem_type_mapping_tbl;
u8 num_mem_types;
- 

[PATCH v2 3/5] mwifiex: do not free firmware dump memory in shutdown_drv

[Amitkumar Karwar]

From: Xinming Hu 

mwifiex_upload_device_dump() already takes care of freeing firmware dump
memory. Doing the same thing in mwifiex_shutdown_drv() is redundant.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
v2: Same as v1. 
drv_info_dump and drv_info_size need not be in adapter structure. Saparate
patch is created for this (Dmitry Torokhov)
---
 drivers/net/wireless/marvell/mwifiex/init.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index 8e5e424..365efb8 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -407,8 +407,6 @@ static void mwifiex_free_lock_list(struct mwifiex_adapter 
*adapter)
 static void
 mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
 {
-   int idx;
-
if (!adapter) {
pr_err("%s: adapter is NULL\n", __func__);
return;
@@ -426,23 +424,6 @@ mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
mwifiex_dbg(adapter, INFO, "info: free cmd buffer\n");
mwifiex_free_cmd_buffer(adapter);
 
-   for (idx = 0; idx < adapter->num_mem_types; idx++) {
-   struct memory_type_mapping *entry =
-   >mem_type_mapping_tbl[idx];
-
-   if (entry->mem_ptr) {
-   vfree(entry->mem_ptr);
-   entry->mem_ptr = NULL;
-   }
-   entry->mem_size = 0;
-   }
-
-   if (adapter->drv_info_dump) {
-   vfree(adapter->drv_info_dump);
-   adapter->drv_info_dump = NULL;
-   adapter->drv_info_size = 0;
-   }
-
if (adapter->sleep_cfm)
dev_kfree_skb_any(adapter->sleep_cfm);
 }
-- 
1.9.1

[PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

[Amitkumar Karwar]

This variable is guarded by spinlock at all other places. This patch
takes care of missing spinlock usage in mwifiex_shutdown_drv().

Signed-off-by: Amitkumar Karwar 
---
v2: Same as v1
---
 drivers/net/wireless/marvell/mwifiex/init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index 82839d9..8e5e424 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -670,11 +670,14 @@ mwifiex_shutdown_drv(struct mwifiex_adapter *adapter)
 
adapter->hw_status = MWIFIEX_HW_STATUS_CLOSING;
/* wait for mwifiex_process to complete */
+   spin_lock_irqsave(>main_proc_lock, flags);
if (adapter->mwifiex_processing) {
+   spin_unlock_irqrestore(>main_proc_lock, flags);
mwifiex_dbg(adapter, WARN,
"main process is still running\n");
return ret;
}
+   spin_unlock_irqrestore(>main_proc_lock, flags);
 
/* cancel current command */
if (adapter->curr_cmd) {
-- 
1.9.1

Re: [NOT FOR MERGE] ath9k: work around key cache corruption

[Kalle Valo]

Antonio Quartulli  writes:

> On Wed, Oct 26, 2016 at 05:05:14PM +0300, Kalle Valo wrote:
>> Antonio Quartulli  writes:
>> 
>> > From: Antonio Quartulli 
>> >
>> > This patch was crafted long time ago to work around a key cache
>> > corruption problem on ath9k chipsets.
>> >
>> > The workaround consists in periodically triggering a worker that
>> > uploads all the keys to the HW cache. The worker is triggered also
>> > when the vif detects 21 undecryptable packets.
>> >
>> >
>> > This patch is based on top compat-wireless-2015-10-26.
>> >
>> >
>> > I was asked to release this code to the public and, since it is
>> > GPL, I am now doing it.
>> 
>> GPL? AFAICS ath9k is under ISC. I'm not sure what you mean with the
>> sentence above, but it's possible to interpret it so that this patch is
>> not under ISC license, which is problematic.
>
> Honestly, my sentence was just a way to say "it makes sense to release this
> patch to the public".

I was suspecting it was like that, I just wasn't sure.

> If it needs to be ISC in order to be merged, then it can be released under 
> ISC.
>
> I don't want to enter a legal case :)

Me neither. But I can't apply patches with unclear license.

-- 
Kalle Valo