* Re: [PATCH v2 1/5] mwifiex: remove redundant condition in main process
From: Brian Norris @ 2016-10-27 18:35 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov
In-Reply-To: <1477559563-18328-1-git-send-email-akarwar@marvell.com>
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 <akarwar@marvell.com>
> ---
> v2: Same as v1
You've omitted the Reviewed-by tags from v1:
Reviewed-by: Brian Norris <briannorris@chromium.org>
^ permalink raw reply
* Re: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting
From: Denis Kenzior @ 2016-10-27 18:12 UTC (permalink / raw)
To: Johannes Berg, Zaborowski, Andrew, linux-wireless@vger.kernel.org
In-Reply-To: <1477487137.4059.43.camel@sipsolutions.net>
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
^ permalink raw reply
* Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Dmitry Torokhov @ 2016-10-27 17:44 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris
In-Reply-To: <1477559563-18328-2-git-send-email-akarwar@marvell.com>
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 <akarwar@marvell.com>
> ---
> 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(&adapter->main_proc_lock, flags);
> if (adapter->mwifiex_processing) {
> + spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
> mwifiex_dbg(adapter, WARN,
> "main process is still running\n");
> return ret;
> }
> + spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
>
> /* cancel current command */
> if (adapter->curr_cmd) {
> --
> 1.9.1
>
--
Dmitry
^ permalink raw reply
* Re: [RFC] mac80211: set wifi_acked[_valid] bits for transmitted SKBs
From: Dave Taht @ 2016-10-27 16:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20161027142103.19756-1-johannes@sipsolutions.net>
On Thu, Oct 27, 2016 at 7:21 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> 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 <johannes.berg@intel.com>
> ---
> 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 ieee802=
11_local *local,
> } else if (info->ack_frame_id) {
> ieee80211_report_ack_skb(local, info, acked, dropped);
> }
> +
> + if (!dropped && skb->destructor) {
> + skb->wifi_acked_valid =3D 1;
> + skb->wifi_acked =3D 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 10000p 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
>
--=20
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2016-10-25-2
From: Kalle Valo @ 2016-10-27 15:32 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1477469629.27792.8.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> 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
^ permalink raw reply
* wireless-drivers-next open for 4.10
From: Kalle Valo @ 2016-10-27 15:28 UTC (permalink / raw)
To: linux-wireless
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
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Johannes Berg @ 2016-10-27 15:06 UTC (permalink / raw)
To: Sebastian Gottschall, Kalle Valo, Antonio Quartulli
Cc: ath9k-devel, linux-wireless, sw, Antonio Quartulli
In-Reply-To: <62a2dc74-4a7c-d3d4-4170-4d5759b07ab3@dd-wrt.com>
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
^ permalink raw reply
* Re: [19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Kalle Valo @ 2016-10-27 15:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Linus Torvalds, linux-kernel, Arnd Bergmann,
Hante Meuleman, Franky Lin, Pieter-Paul Giesberts,
Franky (Zhenhui) Lin, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, netdev
In-Reply-To: <20161017221355.1861551-7-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> 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 <hante.meuleman@broadcom.com>
> Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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
^ permalink raw reply
* Re: pull-request: iwlwifi 2016-10-25
From: Kalle Valo @ 2016-10-27 15:02 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1477388323.17122.27.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> Here are 7 patches intended for 4.9. =C2=A0They fix some small issues, as
> described in the tag itself. I sent them out for review on 2016-10-19,=20
> 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 1ea2643961b0d1b8d0e4a11af5aa69b0f92d05=
33:
>
> 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.
--=20
Kalle Valo
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Sebastian Gottschall @ 2016-10-27 7:54 UTC (permalink / raw)
To: Kalle Valo, Antonio Quartulli
Cc: ath9k-devel, linux-wireless, sw, Antonio Quartulli
In-Reply-To: <87bmy65nz8.fsf@kamboji.qca.qualcomm.com>
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 <a@unstable.cc> writes:
>
>> On Wed, Oct 26, 2016 at 05:05:14PM +0300, Kalle Valo wrote:
>>> Antonio Quartulli <a@unstable.cc> writes:
>>>
>>>> From: Antonio Quartulli <antonio@open-mesh.com>
>>>>
>>>> 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.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: Outdated wl12xx firmwares
From: Gary Bisson @ 2016-10-27 10:45 UTC (permalink / raw)
To: linux-firmware; +Cc: linux-wireless
In-Reply-To: <CAAMH-ytch0sbtjfp8rjUCNbEkj4euBES7a4n9niS1DtMZk2EKA@mail.gmail.com>
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
<gary.bisson@boundarydevices.com> 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
^ permalink raw reply
* Re: [PATCH v2 0/9] cfg80211/mac80211: Fast Initial Link Setup (IEEE 802.11ai)
From: Johannes Berg @ 2016-10-27 10:42 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <1477518126-823-1-git-send-email-jouni@qca.qualcomm.com>
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
^ permalink raw reply
* [RFC] mac80211: set wifi_acked[_valid] bits for transmitted SKBs
From: Johannes Berg @ 2016-10-27 14:21 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
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 <johannes.berg@intel.com>
---
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
^ permalink raw reply related
* Re: [PATCH v2] cfg80211: Add support to update connection parameters
From: Johannes Berg @ 2016-10-27 14:00 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1477576271-12696-1-git-send-email-jouni@qca.qualcomm.com>
On Thu, 2016-10-27 at 16:51 +0300, Jouni Malinen wrote:
> From: vamsi krishna <vamsin@qti.qualcomm.com>
>
> 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
^ permalink raw reply
* Re: [PATCH 5/5] mwifiex: wait for firmware dump completion in remove_card
From: Kalle Valo @ 2016-10-27 13:20 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Amitkumar Karwar, linux-wireless, Cathy Luo, Nishant Sarmukadam,
briannorris, Xinming Hu
In-Reply-To: <20161025001405.GE15034@dtor-ws>
Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
>> +/* reset_trigger variable is used to identify if mwifiex_sdio_remove()
>> + * is called by sdio_work during reset or the call is from sdio subsystem.
>> + * We will cancel sdio_work only if the call is from sdio subsystem.
>> + */
>> +static u8 reset_triggered;
>
> It would be really great if the driver supported multiple devices. IOW
> please avoid module-globals.
Good catch, it's a hard requirement to support multiple devices at the
same time.
--
Kalle Valo
^ permalink raw reply
* pull-request: mac80211 2016-10-27
From: Johannes Berg @ 2016-10-27 8:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
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(-)
^ permalink raw reply
* Re: [PATCH v6 4/4] mac80211: multicast to unicast conversion
From: Johannes Berg @ 2016-10-27 12:29 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, netdev
In-Reply-To: <1476119543-24509-4-git-send-email-michael-dev@fami-braun.de>
> @@ -2242,6 +2242,20 @@ static int ieee80211_set_wds_peer(struct wiphy
> *wiphy, struct net_device *dev,
> return 0;
> }
>
> +static int ieee80211_set_multicast_to_unicast(struct wiphy *wiphy,
> + struct net_device
> *dev,
> + const bool enabled)
I don't understand why you put this with set_wds_peer, please add it
here also at the end like anywhere else - I've changed that for you in
the cfg80211 patch.
> + struct ieee80211_sub_if_data *sdata =
> IEEE80211_DEV_TO_SUB_IF(dev);
> +
> + if (sdata->vif.type != NL80211_IFTYPE_AP)
> + return -1;
Not needed. Also, don't ever just blindly return -1 in the kernel, that
means -EPERM, i.e. permission denied.
> +/* rewrite destination mac address */
that's a pretty useless comment ...
> +/* Check if multicast to unicast conversion is needed and do it.
> + * Returns 1 if skb was freed and should not be send out.
Follow kernel convention of returning a negative error code, e.g.
-ENOTCONN in this case, and remove this comment.
> + /* clone packets and update destination mac */
> + list_for_each_entry_rcu(sta, &local->sta_list, list) {
> + if (sdata != sta->sdata)
> + continue;
> + if (unlikely(!ether_addr_equal(eth->h_source, sta-
> >sta.addr)))
> + /* do not send back to source */
> + continue;
> + if (!prev) {
> + prev = sta;
> + continue;
> + }
> + cloned_skb = skb_clone(skb, GFP_ATOMIC);
> + if (unlikely(ieee80211_change_da(cloned_skb, prev)))
> {
> + dev_kfree_skb(cloned_skb);
> + continue;
> + }
> + __ieee80211_subif_start_xmit(cloned_skb, cloned_skb-
> >dev, 0);
I don't like the recursion here.
I think we can call this from ieee80211_subif_start_xmit(), and then do
something like
if (unlikely(multicast)) {
struct skb_queue queue;
__skb_queue_head_init(&queue);
convert_frames(
while ((skb = __skb_dequeue(&queue))
__ieee80211_subif_start_xmit(...);
} else {
__ieee80211_subif_start_xmit(...);
}
Yes, that's a little less efficient (RCU stuff, although that could
even move in theory), but it avoids the recursion which imho is better.
johannes
^ permalink raw reply
* Re: [PATCH v6 3/4] cfg80211: configure multicast to unicast for AP interfaces
From: Johannes Berg @ 2016-10-27 12:20 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, netdev
In-Reply-To: <1476119543-24509-3-git-send-email-michael-dev@fami-braun.de>
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
^ permalink raw reply
* [PATCH v2] cfg80211: Add support to update connection parameters
From: Jouni Malinen @ 2016-10-27 13:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, vamsi krishna, Jouni Malinen
From: vamsi krishna <vamsin@qti.qualcomm.com>
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 <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
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 &enum 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 *info)
return err;
}
+static int nl80211_update_connect_params(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ struct cfg80211_connect_params connect = {};
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct net_device *dev = info->user_ptr[1];
+ struct wireless_dev *wdev = dev->ieee80211_ptr;
+ u32 changed = 0;
+ int ret;
+
+ if (!rdev->ops->update_connect_params)
+ return -EOPNOTSUPP;
+
+ if (info->attrs[NL80211_ATTR_IE]) {
+ if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
+ return -EINVAL;
+ connect.ie = nla_data(info->attrs[NL80211_ATTR_IE]);
+ connect.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
+ changed |= UPDATE_ASSOC_IES;
+ }
+
+ wdev_lock(dev->ieee80211_ptr);
+ if (!wdev->current_bss)
+ ret = -ENOLINK;
+ else
+ ret = rdev_update_connect_params(rdev, dev, &connect, changed);
+ wdev_unlock(dev->ieee80211_ptr);
+
+ return ret;
+}
+
static int nl80211_disconnect(struct sk_buff *skb, struct genl_info *info)
{
struct cfg80211_registered_device *rdev = info->user_ptr[0];
@@ -12231,6 +12262,14 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
NL80211_FLAG_NEED_RTNL,
},
{
+ .cmd = NL80211_CMD_UPDATE_CONNECT_PARAMS,
+ .doit = nl80211_update_connect_params,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
.cmd = NL80211_CMD_DISCONNECT,
.doit = nl80211_disconnect,
.policy = nl80211_policy,
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index e9ecf23..2f42507 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -490,6 +490,18 @@ static inline int rdev_connect(struct cfg80211_registered_device *rdev,
return ret;
}
+static inline int
+rdev_update_connect_params(struct cfg80211_registered_device *rdev,
+ struct net_device *dev,
+ struct cfg80211_connect_params *sme, u32 changed)
+{
+ int ret;
+ trace_rdev_update_connect_params(&rdev->wiphy, dev, sme, changed);
+ ret = rdev->ops->update_connect_params(&rdev->wiphy, dev, sme, changed);
+ trace_rdev_return_int(&rdev->wiphy, ret);
+ return ret;
+}
+
static inline int rdev_disconnect(struct cfg80211_registered_device *rdev,
struct net_device *dev, u16 reason_code)
{
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 25f8318..ea1b47e 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -1281,6 +1281,24 @@
__entry->wpa_versions, __entry->flags, MAC_PR_ARG(prev_bssid))
);
+TRACE_EVENT(rdev_update_connect_params,
+ TP_PROTO(struct wiphy *wiphy, struct net_device *netdev,
+ struct cfg80211_connect_params *sme, u32 changed),
+ TP_ARGS(wiphy, netdev, sme, changed),
+ TP_STRUCT__entry(
+ WIPHY_ENTRY
+ NETDEV_ENTRY
+ __field(u32, changed)
+ ),
+ TP_fast_assign(
+ WIPHY_ASSIGN;
+ NETDEV_ASSIGN;
+ __entry->changed = changed;
+ ),
+ TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", parameters changed: %u",
+ WIPHY_PR_ARG, NETDEV_PR_ARG, __entry->changed)
+);
+
TRACE_EVENT(rdev_set_cqm_rssi_config,
TP_PROTO(struct wiphy *wiphy,
struct net_device *netdev, s32 rssi_thold,
--
1.9.1
^ permalink raw reply related
* [PATCH v2 5/5] mwifiex: wait firmware dump complete during card remove process
From: Amitkumar Karwar @ 2016-10-27 9:12 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1477559563-18328-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
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 <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
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);
+
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(&pcie_work);
+
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, &add_remove_card_sem);
}
+static void
+mwifiex_sdio_remove(struct sdio_func *func)
+{
+ cancel_work_sync(&sdio_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
^ permalink raw reply related
* [PATCH v2 4/5] mwifiex: get rid of drv_info* adapter variables
From: Amitkumar Karwar @ 2016-10-27 9:12 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1477559563-18328-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
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 <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
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("\n========End 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, "\n========End dump========\n");
fw_dump_ptr += strlen("\n========End dump========\n");
@@ -1219,18 +1217,12 @@ done:
struct memory_type_mapping *entry =
&adapter->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;
- void *drv_info_dump;
- u32 drv_info_size;
bool scan_chan_gap_enabled;
struct sk_buff_head rx_data_q;
bool mfg_mode;
@@ -1606,8 +1604,9 @@ void mwifiex_hist_data_add(struct mwifiex_private *priv,
u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
u8 rx_rate, u8 ht_info);
-void mwifiex_drv_info_dump(struct mwifiex_adapter *adapter);
-void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter);
+int mwifiex_drv_info_dump(struct mwifiex_adapter *adapter, void **drv_info);
+void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void *drv_info,
+ int drv_info_size);
void *mwifiex_alloc_dma_align_buf(int rx_len, gfp_t flags);
void mwifiex_queue_main_work(struct mwifiex_adapter *adapter);
int mwifiex_get_wakeup_reason(struct mwifiex_private *priv, u16 action,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 9147e6a..9025af7 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2699,9 +2699,12 @@ static void mwifiex_pcie_fw_dump(struct mwifiex_adapter *adapter)
static void mwifiex_pcie_device_dump_work(struct mwifiex_adapter *adapter)
{
- mwifiex_drv_info_dump(adapter);
+ int drv_info_size;
+ void *drv_info;
+
+ drv_info_size = mwifiex_drv_info_dump(adapter, &drv_info);
mwifiex_pcie_fw_dump(adapter);
- mwifiex_upload_device_dump(adapter);
+ mwifiex_upload_device_dump(adapter, drv_info, drv_info_size);
}
static unsigned long iface_work_flags;
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 4cad1c2..241d2b3 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2602,13 +2602,15 @@ done:
static void mwifiex_sdio_device_dump_work(struct mwifiex_adapter *adapter)
{
struct sdio_mmc_card *card = adapter->card;
+ int drv_info_size;
+ void *drv_info;
- mwifiex_drv_info_dump(adapter);
+ drv_info_size = mwifiex_drv_info_dump(adapter, &drv_info);
if (card->fw_dump_enh)
mwifiex_sdio_generic_fw_dump(adapter);
else
mwifiex_sdio_fw_dump(adapter);
- mwifiex_upload_device_dump(adapter);
+ mwifiex_upload_device_dump(adapter, drv_info, drv_info_size);
}
static void mwifiex_sdio_work(struct work_struct *work)
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/5] mwifiex: do not free firmware dump memory in shutdown_drv
From: Amitkumar Karwar @ 2016-10-27 9:12 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1477559563-18328-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
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 <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
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 =
- &adapter->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
^ permalink raw reply related
* [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Amitkumar Karwar @ 2016-10-27 9:12 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
In-Reply-To: <1477559563-18328-1-git-send-email-akarwar@marvell.com>
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 <akarwar@marvell.com>
---
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(&adapter->main_proc_lock, flags);
if (adapter->mwifiex_processing) {
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
mwifiex_dbg(adapter, WARN,
"main process is still running\n");
return ret;
}
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
/* cancel current command */
if (adapter->curr_cmd) {
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/5] mwifiex: remove redundant condition in main process
From: Amitkumar Karwar @ 2016-10-27 9:12 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, 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 <akarwar@marvell.com>
---
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
^ permalink raw reply related
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Kalle Valo @ 2016-10-27 6:02 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: ath9k-devel, linux-wireless, sw, Antonio Quartulli
In-Reply-To: <20161026141016.GB26376@prodigo.lan>
Antonio Quartulli <a@unstable.cc> writes:
> On Wed, Oct 26, 2016 at 05:05:14PM +0300, Kalle Valo wrote:
>> Antonio Quartulli <a@unstable.cc> writes:
>>
>> > From: Antonio Quartulli <antonio@open-mesh.com>
>> >
>> > 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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox