* Re: [PATCH] wireless: fix bogus maybe-uninitialized warning
From: Kalle Valo @ 2016-11-09 1:21 UTC (permalink / raw)
To: Arnd Bergmann, Johannes Berg
Cc: Stanislav Yakovlev, Jouni Malinen, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20161024153918.2810634-2-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> The hostap_80211_rx() function is supposed to set up the mac addresses
> for four possible cases, based on two bits of input data. For
> some reason, gcc decides that it's possible that none of the these
> four cases apply and the addresses remain uninitialized:
>
> drivers/net/wireless/intersil/hostap/hostap_80211_rx.c: In function =E2=
=80=98hostap_80211_rx=E2=80=99:
> arch/x86/include/asm/string_32.h:77:14: warning: =E2=80=98src=E2=80=99 ma=
y be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/net/wireless/intel/ipw2x00/libipw_rx.c: In function =E2=80=98libi=
pw_rx=E2=80=99:
> arch/x86/include/asm/string_32.h:77:14: error: =E2=80=98dst=E2=80=99 may =
be used uninitialized in this function [-Werror=3Dmaybe-uninitialized]
> arch/x86/include/asm/string_32.h:78:22: error: =E2=80=98*((void *)&dst+4)=
=E2=80=99 may be used uninitialized in this function [-Werror=3Dmaybe-unini=
tialized]
>
> This warning is clearly nonsense, but changing the last case into
> 'default' makes it obvious to the compiler too, which avoids the
> warning and probably leads to better object code too.
>
> The same code is duplicated several times in the kernel, so this
> patch uses the same workaround for all copies. The exact configuration
> was hit only very rarely in randconfig builds and I only saw it
> in three drivers, but I assume that all of them are potentially
> affected, and it's better to keep the code consistent.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/wireless/ath/ath6kl/wmi.c | 8 ++++----
> drivers/net/wireless/intel/ipw2x00/libipw_rx.c | 2 +-
> drivers/net/wireless/intersil/hostap/hostap_80211_rx.c | 2 +-
> net/wireless/lib80211_crypt_tkip.c | 2 +-
> 4 files changed, 7 insertions(+), 7 deletions(-)
[...]
> --- a/net/wireless/lib80211_crypt_tkip.c
> +++ b/net/wireless/lib80211_crypt_tkip.c
> @@ -556,7 +556,7 @@ static void michael_mic_hdr(struct sk_buff *skb, u8 *=
hdr)
> memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */
> memcpy(hdr + ETH_ALEN, hdr11->addr4, ETH_ALEN); /* SA */
> break;
> - case 0:
> + default:
> memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */
> memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */
> break;
Ideally we prefer that drivers/net/wireless and net/wireless changes are
split into different patches as they get applied to different trees.
Johannes, is it ok if I take this change through my tree this time?
--=20
Kalle Valo
^ permalink raw reply
* Re: [v2] rt2x00: add support for mac addr from device tree
From: Kalle Valo @ 2016-11-09 1:29 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless
In-Reply-To: <1472195813-30471-1-git-send-email-dev@kresin.me>
Mathias Kresin <dev@kresin.me> wrote:
> On some devices the EEPROMs of Ralink Wi-Fi chips have a default Ralink
> MAC address set (RT3062F: 00:0C:43:30:62:00, RT3060F:
> 00:0C:43:30:60:00). Using multiple of these devices in the same network
> can cause nasty issues.
>
> Allow to override the MAC in the EEPROM with (a known good) one set in
> the device tree to bypass the issue.
>
> Signed-off-by: Mathias Kresin <dev@kresin.me>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
9766cb709089 rt2x00: add support for mac addr from device tree
--
https://patchwork.kernel.org/patch/9300893/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: proto: add callback for queuing TX data
From: Kalle Valo @ 2016-11-09 1:30 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
In-Reply-To: <20160926215144.9923-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> So far our core code was calling brcmf_fws_process_skb which wasn't
> a proper thing to do. If case of devices using msgbuf protocol fwsignal
> shouldn't be used. It was an unnecessary extra layer simply calling
> a protocol specifix txdata function.
>
> Please note we already have txdata callback, but it's used for calls
> between bcdc and fwsignal so it couldn't be simply used there.
>
> This makes core code more generic (instead of bcdc/fwsignal specific).
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Patch applied to wireless-drivers-next.git, thanks.
b073ac1fcf42 brcmfmac: proto: add callback for queuing TX data
--
https://patchwork.kernel.org/patch/9351305/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/8] mwifiex: prevent register accesses after host is sleeping
From: Kalle Valo @ 2016-11-09 1:34 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> Following is mwifiex driver-firmware host sleep handshake.
> It involves three threads. suspend handler, interrupt handler, interrupt
> processing in main work queue.
>
> 1) Enter suspend handler
> 2) Download HS_CFG command
> 3) Response from firmware for HS_CFG
> 4) Suspend thread waits until handshake completes(i.e hs_activate becomes
> true)
> 5) SLEEP from firmware
> 6) SLEEP confirm downloaded to firmware.
> 7) SLEEP confirm response from firmware
> 8) Driver processes SLEEP confirm response and set hs_activate to wake up
> suspend thread
> 9) Exit suspend handler
> 10) Read sleep cookie in loop and wait until it indicates firmware is
> sleep.
> 11) After processing SLEEP confirm response, we are at the end of interrupt
> processing routine. Recheck if there are interrupts received while we were
> processing them.
>
> During suspend-resume stress test, it's been observed that we may end up
> acessing PCIe hardware(in 10 and 11) when PCIe bus is closed which leads
> to a kernel crash.
>
> This patch solves the problem with below changes.
> a) action 10 above can be done before 8
> b) Skip 11 if hs_activated is true. SLEEP confirm response
> is the last interrupt from firmware. No need to recheck for
> pending interrupts.
> c) Add flush_workqueue() in suspend handler.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Tested-by: Brian Norris <briannorris@chromium.org>
8 patches applied to wireless-drivers-next.git, thanks.
ec815dd2a5f1 mwifiex: prevent register accesses after host is sleeping
5190f2e40591 mwifiex: report error to PCIe for suspend failure
c44c040300d7 mwifiex: Fix NULL pointer dereference in skb_dequeue()
113630b581d6 mwifiex: vendor_ie length check for parse WMM IEs
a936ea543657 mwifiex: add memrw command information in README
77f486c8bb39 mwifiex: update tx_pkts_queued for requeued packets
49abe5c83cd0 mwifiex: fix command timeout problem seen in stress tests
3d8bd85c2c9e mwifiex: fix p2p device doesn't find in scan problem
--
https://patchwork.kernel.org/patch/9353809/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [-next] mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virtual_intf()
From: Kalle Valo @ 2016-11-09 1:34 UTC (permalink / raw)
To: Wei Yongjun
Cc: Amitkumar Karwar, Nishant Sarmukadam, Wei Yongjun, linux-wireless
In-Reply-To: <1475161076-1409-1-git-send-email-weiyj.lk@gmail.com>
Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Add the missing destroy_workqueue() before return from
> mwifiex_add_virtual_intf() in the error handling case.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
424342ff0e03 mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virtual_intf()
--
https://patchwork.kernel.org/patch/9356567/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] cw1200: Don't leak memory if krealloc failes
From: Kalle Valo @ 2016-11-09 1:37 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: Solomon Peachy, linux-wireless, netdev, linux-kernel,
Johannes Thumshirn, Johannes Berg
In-Reply-To: <1475239157-16448-1-git-send-email-jthumshirn@suse.de>
Johannes Thumshirn <jthumshirn@suse.de> wrote:
> The call to krealloc() in wsm_buf_reserve() directly assigns the newly
> returned memory to buf->begin. This is all fine except when krealloc()
> failes we loose the ability to free the old memory pointed to by
> buf->begin. If we just create a temporary variable to assign memory to
> and assign the memory to it we can mitigate the memory leak.
>
> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
> Cc: Johannes Berg <johannes@sipsolutions.net>
Patch applied to wireless-drivers-next.git, thanks.
9afdd6128c39 cw1200: Don't leak memory if krealloc failes
--
https://patchwork.kernel.org/patch/9358185/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* make-wifi-fast linuxplumbers talk summarized on lwn.net
From: Dave Taht @ 2016-11-09 1:59 UTC (permalink / raw)
To: linux-wireless, make-wifi-fast, bloat
and available here:
https://lwn.net/SubscriberLink/705884/1bdb9c4aa048b0d5/
After the talk I discussed with several folk about applying the same
debloating techniques to other chipsets.
I don't remember, unfortunately, who all those folk were, nor the
candidate chipsets!
--=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: [v5] ath9k: Switch to using mac80211 intermediate software queues.
From: Kalle Valo @ 2016-11-09 2:22 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: make-wifi-fast, linux-wireless, Toke Høiland-Jørgensen,
Tim Shepard, Felix Fietkau
In-Reply-To: <20160902140030.11798-1-toke@toke.dk>
Toke Høiland-Jørgensen wrote:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
>
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
>
> Based on Tim's original patch set, but reworked quite thoroughly.
>
> Cc: Tim Shepard <shep@alum.mit.edu>
> Cc: Felix Fietkau <nbd@nbd.name>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
All dependencies have trickled down to ath.git but unfortunately doesn't apply
anymore, so please rebase. Hopefully the last time :)
While at it, could you also add to the commit log some info how awesome this
patch is from user's point of view and how it helps. For example, before and
and after numbers and other results.
error: patch failed: drivers/net/wireless/ath/ath9k/xmit.c:921
error: drivers/net/wireless/ath/ath9k/xmit.c: patch does not apply
stg import: Diff does not apply cleanly
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9311037/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] mwifiex: printk() overflow with 32-byte SSIDs
From: Brian Norris @ 2016-11-09 2:28 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo
Cc: linux-kernel, linux-wireless, Cathy Luo, security, stable,
Brian Norris
SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
when we print them out.
This can be easily noticed by connecting to a network with a 32-octet
SSID:
[ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to
'0123456789abcdef0123456789abcdef <uninitialized mem>' bssid
xx:xx:xx:xx:xx:xx
Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Cc: <stable@vger.kernel.org>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 39ce76ad00bc..16241d21727b 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2222,8 +2222,9 @@ mwifiex_cfg80211_assoc(struct mwifiex_private *priv, size_t ssid_len,
is_scanning_required = 1;
} else {
mwifiex_dbg(priv->adapter, MSG,
- "info: trying to associate to '%s' bssid %pM\n",
- (char *)req_ssid.ssid, bss->bssid);
+ "info: trying to associate to '%.*s' bssid %pM\n",
+ req_ssid.ssid_len, (char *)req_ssid.ssid,
+ bss->bssid);
memcpy(&priv->cfg_bssid, bss->bssid, ETH_ALEN);
break;
}
@@ -2283,8 +2284,8 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy, struct net_device *dev,
}
mwifiex_dbg(adapter, INFO,
- "info: Trying to associate to %s and bssid %pM\n",
- (char *)sme->ssid, sme->bssid);
+ "info: Trying to associate to %.*s and bssid %pM\n",
+ (int)sme->ssid_len, (char *)sme->ssid, sme->bssid);
if (!mwifiex_stop_bg_scan(priv))
cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
@@ -2417,8 +2418,8 @@ mwifiex_cfg80211_join_ibss(struct wiphy *wiphy, struct net_device *dev,
}
mwifiex_dbg(priv->adapter, MSG,
- "info: trying to join to %s and bssid %pM\n",
- (char *)params->ssid, params->bssid);
+ "info: trying to join to %.*s and bssid %pM\n",
+ params->ssid_len, (char *)params->ssid, params->bssid);
mwifiex_set_ibss_params(priv, params);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [v5] ath9k: Switch to using mac80211 intermediate software queues.
From: Tim Shepard @ 2016-11-09 2:44 UTC (permalink / raw)
To: Kalle Valo
Cc: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless,
Felix Fietkau
In-Reply-To: <1cd07522568b40a6a3e2db6170153c74@euamsexm01a.eu.qualcomm.com>
> While at it, could you also add to the commit log some info how awesome this
> patch is from user's point of view and how it helps. For example, before and
> and after numbers and other results.
That varies wildly, depending on many details of the scenario
(including the wireless capabilities of the clients connected to the
AP using this patch, and how far away those clients are). There's
really not enough room in a commit message to explain enough to make
any such claimed numbers reproducible.
And, BTW, this patch alone is not really where the big improvement
comes from. This just cuts ath9k over to use the new
transmit-a-packet interface between the mac80211 layer and the
wireless device driver. All the good work to improve latency is being
done on the new mac80211 interface to the driver to transmit a packet.
If you want numbers in a commit message, those numbers belong over on
those commits, not on this ath9k commit, IMHO.
And there's different patches that taken together achieve the best
improvement, and in various subsets differing amounts of improvement,
which again all depends on the scenarios.
And all this is complicated by how often real users are involved in
scenarios where this matters (hard to say).
This mainly improves things when you have an ath9k interface with
packets queued simultaneously to different wireless destinations,
which is typically when the ath9k interface is serving as an AP.
And I would expect similar improvements for any wireless driver cut
over to use the new mac80211 interface. (This patch might be a
helpful guide to other wireless driver maintainers wishing to see the
same improvements other wireless drivers.)
I hope that the above paragraphs were helpful.
-Tim Shepard
shep@alum.mit.edu
^ permalink raw reply
* [PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()
From: Ricky Liang @ 2016-11-09 3:37 UTC (permalink / raw)
Cc: Ricky Liang, Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo,
open list:MARVELL MWIFIEX WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels():
unreferenced object 0xffffffc0a2914780 (size 192):
comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s)
hex dump (first 32 bytes):
00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@
07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04 ..TW 4..d.$..$..
backtrace:
[<ffffffc0003375f4>] create_object+0x164/0x2b4
[<ffffffc0008e3530>] kmemleak_alloc+0x50/0x88
[<ffffffc000335120>] __kmalloc_track_caller+0x1bc/0x264
[<ffffffc00030899c>] kmemdup+0x38/0x64
[<ffffffbffc2311cc>] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex]
[<ffffffbffc22ee9c>] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex]
[<ffffffbffc22f45c>] mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex]
[<ffffffbffc2375d0>] mwifiex_process_sta_event+0x378/0x898 [mwifiex]
[<ffffffbffc224dc8>] mwifiex_process_event+0x1a8/0x1e8 [mwifiex]
[<ffffffbffc2228f0>] mwifiex_main_process+0x258/0x534 [mwifiex]
[<ffffffbffc258858>] 0xffffffbffc258858
[<ffffffc00071ee90>] process_sdio_pending_irqs+0xf8/0x160
[<ffffffc00071efdc>] sdio_irq_thread+0x9c/0x1a4
[<ffffffc000240d08>] kthread+0xf4/0x100
[<ffffffc0002043fc>] ret_from_fork+0xc/0x50
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Ricky Liang <jcliang@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index 97c9765..98ce072 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1671,6 +1671,10 @@ static int mwifiex_save_hidden_ssid_channels(struct mwifiex_private *priv,
}
done:
+ /* beacon_ie buffer was allocated in function
+ * mwifiex_fill_new_bss_desc(). Free it now.
+ */
+ kfree(bss_desc->beacon_buf);
kfree(bss_desc);
return 0;
}
--
2.6.6
^ permalink raw reply related
* [PATCH v2 0/3] Fix -Wunused-but-set-variable in iwlwifi/pcie/trans and iwlwifi/mvm/rs
From: Kirtika Ruchandani @ 2016-11-09 5:49 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless, Arnd Bergmann, Kalle Valo, Emmanuel Grumbach,
Johannes Berg, Sara Sharon, Eran Harary, Liad Kaufman,
Eyal Shapira, Alexander Bondar
This patchset is part of the effort led by Arnd Bergmann to clean up
warnings in the kernel. This and following patchsets will focus on
"-Wunused-but-set-variable" as it among the noisier ones. These were
found compiling with W=1.
--
Changes in v2:
- Made the following changes suggested by Arnd in all 3 patches
1. Each patch has a unique subject line.
2. Add the commit that introduced/led to the warning with the "Fixes:" line.
3. cc linux-wireles, cc commit authors.
Kirtika Ruchandani (3):
iwlwifi: mvm: rs: Remove unused 'mvmvif'/'mvmsta' variables
iwlwifi: mvm: rs: Remove unused 'mcs' variable
iwlwifi: pcie: trans: Remove unused 'shift_param'
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 10 +---------
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 3 ---
2 files changed, 1 insertion(+), 12 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* [PATCH v2 1/3] iwlwifi: mvm: rs: Remove unused 'mvmvif'/'mvmsta' variables
From: Kirtika Ruchandani @ 2016-11-09 5:50 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless, Arnd Bergmann, Kalle Valo, Emmanuel Grumbach,
Johannes Berg, Sara Sharon, Eran Harary, Liad Kaufman,
Eyal Shapira, Alexander Bondar
mvmvif is defined and set in rs_mimo_allow but not used. Compiling
iwlwifi with W=1 gives the following warning, remove it. mvmsta is used only to
obtain mvmvif so remove it as well.
iwlwifi/mvm/rs.c: In function 'rs_mimo_allow':
iwlwifi/mvm/rs.c:165:22: warning: variable 'mvmvif' set but not used.[-Wunused-but-set-variable]
This fix removes calls to iwl_mvm_sta_from_mac & iwl_mvm_vif_from_mac. They are
both accessors, and do not have any side-effects.
Commit e621c2282 removed a workaround that disabled MIMO on P2P, 'mvmvif' was
used for that workaround, but not removed with it.
Fixes: e621c2282e31 ("iwlwifi: rs: Remove workaround that disables MIMO on P2P")
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
Cc: Alexander Bondar <alexander.bondar@intel.com>
Cc: Emmanuel Grumbach <emmmanuel.grumbach@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 227c5ed..0b79f4a 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -161,9 +161,6 @@ static bool rs_mimo_allow(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
struct rs_rate *rate,
const struct rs_tx_column *next_col)
{
- struct iwl_mvm_sta *mvmsta;
- struct iwl_mvm_vif *mvmvif;
-
if (!sta->ht_cap.ht_supported)
return false;
@@ -176,9 +173,6 @@ static bool rs_mimo_allow(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
if (!iwl_mvm_bt_coex_is_mimo_allowed(mvm, sta))
return false;
- mvmsta = iwl_mvm_sta_from_mac80211(sta);
- mvmvif = iwl_mvm_vif_from_mac80211(mvmsta->vif);
-
if (mvm->nvm_data->sku_cap_mimo_disabled)
return false;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 2/3] iwlwifi: mvm: rs: Remove unused 'mcs' variable
From: Kirtika Ruchandani @ 2016-11-09 5:50 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless, Arnd Bergmann, Kalle Valo, Emmanuel Grumbach,
Johannes Berg, Sara Sharon, Eran Harary, Liad Kaufman,
Eyal Shapira, Alexander Bondar
Commit 5fc0f76c4 introduced Rx stats from debugfs, the function
iwl_mvm_reset_frame_stats from that commit defines and sets mcs but does not use
it. Compiling iwlwifi with W=1 gives this warning -
iwlwifi/mvm/rs.c: In function ‘iwl_mvm_update_frame_stats’:
iwlwifi/mvm/rs.c:3074:14: warning: variable ‘mcs’ set but not used [-Wunused-but-set-variable]
Fixes: 5fc0f76c43bd (iwlwifi: mvm: add Rx frames statistics via debugfs)
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
Cc: Eyal Shapira <eyal@wizery.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 0b79f4a..80f99c3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -3065,7 +3065,7 @@ static void iwl_mvm_reset_frame_stats(struct iwl_mvm *mvm)
void iwl_mvm_update_frame_stats(struct iwl_mvm *mvm, u32 rate, bool agg)
{
- u8 nss = 0, mcs = 0;
+ u8 nss = 0;
spin_lock(&mvm->drv_stats_lock);
@@ -3093,11 +3093,9 @@ void iwl_mvm_update_frame_stats(struct iwl_mvm *mvm, u32 rate, bool agg)
if (rate & RATE_MCS_HT_MSK) {
mvm->drv_rx_stats.ht_frames++;
- mcs = rate & RATE_HT_MCS_RATE_CODE_MSK;
nss = ((rate & RATE_HT_MCS_NSS_MSK) >> RATE_HT_MCS_NSS_POS) + 1;
} else if (rate & RATE_MCS_VHT_MSK) {
mvm->drv_rx_stats.vht_frames++;
- mcs = rate & RATE_VHT_MCS_RATE_CODE_MSK;
nss = ((rate & RATE_VHT_MCS_NSS_MSK) >>
RATE_VHT_MCS_NSS_POS) + 1;
} else {
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 3/3] iwlwifi: pcie: trans: Remove unused 'shift_param'
From: Kirtika Ruchandani @ 2016-11-09 5:50 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless, Arnd Bergmann, Kalle Valo, Emmanuel Grumbach,
Johannes Berg, Sara Sharon, Eran Harary, Liad Kaufman,
Eyal Shapira, Alexander Bondar
shift_param is defined and set in iwl_pcie_load_cpu_sections
but not used. Fix this to avoid -Wunused-but-set-variable
warning.
The code using it turned into dead code with commit dcab8ecd5617
which added a separate function iwl_pcie_load_given_ucode_8000
(then 8000b) for IWL_DEVICE_FAMILY_8000. Commit 76f8c0e17edc
removed the dead code but left shift_param as is.
iwlwifi/pcie/trans.c: In function ‘iwl_pcie_load_cpu_sections’:
iwlwifi/pcie/trans.c:871:6: warning: variable ‘shift_param’ set but not used [-Wunused-but-set-variable]
Fixes: dcab8ecd5617 (iwlwifi: mvm: support ucode load for family_8000 B0 only)
Fixes: 76f8c0e17edc (iwlwifi: pcie: remove dead code)
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
Cc: Sara Sharon <sara.sharon@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Eran Harary <eran.harary@intel.com>
Cc: Liad Kaufman <liad.kaufman@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index ae95533..1b27a39 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -868,15 +868,12 @@ static int iwl_pcie_load_cpu_sections(struct iwl_trans *trans,
int cpu,
int *first_ucode_section)
{
- int shift_param;
int i, ret = 0;
u32 last_read_idx = 0;
if (cpu == 1) {
- shift_param = 0;
*first_ucode_section = 0;
} else {
- shift_param = 16;
(*first_ucode_section)++;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [PATCH v2 0/3] Fix -Wunused-but-set-variable in iwlwifi/pcie/trans and iwlwifi/mvm/rs
From: Coelho, Luciano @ 2016-11-09 6:30 UTC (permalink / raw)
To: kirtika.ruchandani@gmail.com
Cc: Kaufman, Liad, Bondar, Alexander, Berg, Johannes,
kvalo@codeaurora.org, eran.harary@intel.com, eyal@wizery.com,
arnd@arndb.de, Sharon, Sara, linux-wireless@vger.kernel.org,
Grumbach, Emmanuel
In-Reply-To: <20161109054930.GA26716@google.com>
T24gVHVlLCAyMDE2LTExLTA4IGF0IDIxOjQ5IC0wODAwLCBLaXJ0aWthIFJ1Y2hhbmRhbmkgd3Jv
dGU6DQo+IFRoaXMgcGF0Y2hzZXQgaXMgcGFydCBvZiB0aGUgZWZmb3J0IGxlZCBieSBBcm5kIEJl
cmdtYW5uIHRvIGNsZWFuIHVwDQo+IHdhcm5pbmdzIGluIHRoZSBrZXJuZWwuIFRoaXMgYW5kIGZv
bGxvd2luZyBwYXRjaHNldHMgd2lsbCBmb2N1cyBvbiANCj4gIi1XdW51c2VkLWJ1dC1zZXQtdmFy
aWFibGUiIGFzIGl0IGFtb25nIHRoZSBub2lzaWVyIG9uZXMuIFRoZXNlIHdlcmUNCj4gZm91bmQg
Y29tcGlsaW5nIHdpdGggVz0xLg0KPiANCj4gLS0gDQo+IENoYW5nZXMgaW4gdjI6DQo+IC0gTWFk
ZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMgc3VnZ2VzdGVkIGJ5IEFybmQgaW4gYWxsIDMgcGF0Y2hl
cw0KPiAgIDEuIEVhY2ggcGF0Y2ggaGFzIGEgdW5pcXVlIHN1YmplY3QgbGluZS4NCj4gICAyLiBB
ZGQgdGhlIGNvbW1pdCB0aGF0IGludHJvZHVjZWQvbGVkIHRvIHRoZSB3YXJuaW5nIHdpdGggdGhl
ICJGaXhlczoiIGxpbmUuDQo+ICAgMy4gY2MgbGludXgtd2lyZWxlcywgY2MgY29tbWl0IGF1dGhv
cnMuDQo+IA0KPiBLaXJ0aWthIFJ1Y2hhbmRhbmkgKDMpOg0KPiAgIGl3bHdpZmk6IG12bTogcnM6
IFJlbW92ZSB1bnVzZWQgJ212bXZpZicvJ212bXN0YScgdmFyaWFibGVzDQo+ICAgaXdsd2lmaTog
bXZtOiByczogUmVtb3ZlIHVudXNlZCAnbWNzJyB2YXJpYWJsZQ0KPiAgIGl3bHdpZmk6IHBjaWU6
IHRyYW5zOiBSZW1vdmUgdW51c2VkICdzaGlmdF9wYXJhbScNCj4gDQo+ICBkcml2ZXJzL25ldC93
aXJlbGVzcy9pbnRlbC9pd2x3aWZpL212bS9ycy5jICAgICB8IDEwICstLS0tLS0tLS0NCj4gIGRy
aXZlcnMvbmV0L3dpcmVsZXNzL2ludGVsL2l3bHdpZmkvcGNpZS90cmFucy5jIHwgIDMgLS0tDQo+
ICAyIGZpbGVzIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxMiBkZWxldGlvbnMoLSkNCg0KVGhh
bmtzLCBLaXJ0aWthISBJJ2xsIHB1c2ggdGhlc2UgcGF0Y2hlcyB2aWEgb3VyIGludGVybmFsIHRy
ZWUgYW5kDQppbmNsdWRlIHRoZW0gaW4gbXkgbmV4dCBwdWxsIHJlcXVlc3QgdG8gS2FsbGUuDQoN
Ci0tIA0KQ2hlZXJzLA0KTHVjYS4=
^ permalink raw reply
* Re: [PATCH v2 1/3] iwlwifi: mvm: rs: Remove unused 'mvmvif'/'mvmsta' variables
From: Luca Coelho @ 2016-11-09 7:25 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: linux-wireless, Arnd Bergmann, Kalle Valo, Emmanuel Grumbach,
Johannes Berg, Sara Sharon, Liad Kaufman, Eyal Shapira,
Alexander Bondar
In-Reply-To: <20161109055015.GA27416@google.com>
(removed Erarn Harary from the Cc list, since this email is not valid
anymore)
Hi Kirtika,
Just a couple of nitpicks, nothing important, so no need to resend.
On Tue, 2016-11-08 at 21:50 -0800, Kirtika Ruchandani wrote:
> mvmvif is defined and set in rs_mimo_allow but not used. Compiling
> iwlwifi with W=1 gives the following warning, remove it. mvmsta is used only to
> obtain mvmvif so remove it as well.
>
> iwlwifi/mvm/rs.c: In function 'rs_mimo_allow':
> iwlwifi/mvm/rs.c:165:22: warning: variable 'mvmvif' set but not used.[-Wunused-but-set-variable]
>
> This fix removes calls to iwl_mvm_sta_from_mac & iwl_mvm_vif_from_mac. They are
> both accessors, and do not have any side-effects.
> Commit e621c2282 removed a workaround that disabled MIMO on P2P, 'mvmvif' was
> used for that workaround, but not removed with it.
>
> Fixes: e621c2282e31 ("iwlwifi: rs: Remove workaround that disables MIMO on P2P")
>
Usually the Fixes: tag is together with the other tags (such as Cc,
Signed-off-by), i.e. no empty line here.
> Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
> Cc: Alexander Bondar <alexander.bondar@intel.com>
> Cc: Emmanuel Grumbach <emmmanuel.grumbach@intel.com>
And the Signed-off-by tag is usually the last one here, after all Cc's
and stuff. But it doesn't matter much.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2 2/3] iwlwifi: mvm: rs: Remove unused 'mcs' variable
From: Luca Coelho @ 2016-11-09 7:28 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: linux-wireless, Arnd Bergmann, Kalle Valo, Emmanuel Grumbach,
Johannes Berg, Sara Sharon, Liad Kaufman, Eyal Shapira,
Alexander Bondar
In-Reply-To: <20161109055033.GA27470@google.com>
Another nitpick....
On Tue, 2016-11-08 at 21:50 -0800, Kirtika Ruchandani wrote:
> Commit 5fc0f76c4 introduced Rx stats from debugfs, the function
> iwl_mvm_reset_frame_stats from that commit defines and sets mcs but does not use
> it. Compiling iwlwifi with W=1 gives this warning -
>
> iwlwifi/mvm/rs.c: In function ‘iwl_mvm_update_frame_stats’:
> iwlwifi/mvm/rs.c:3074:14: warning: variable ‘mcs’ set but not used [-Wunused-but-set-variable]
>
> Fixes: 5fc0f76c43bd (iwlwifi: mvm: add Rx frames statistics via debugfs)
You forgot the quotes here, but no worries, I'll add them.
--
Luca.
^ permalink raw reply
* Re: [PATCH v2 3/3] iwlwifi: pcie: trans: Remove unused 'shift_param'
From: Luca Coelho @ 2016-11-09 7:31 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: linux-wireless, Arnd Bergmann, Kalle Valo, Emmanuel Grumbach,
Johannes Berg, Sara Sharon, Eran Harary, Liad Kaufman,
Eyal Shapira, Alexander Bondar
In-Reply-To: <20161109055048.GA27520@google.com>
On Tue, 2016-11-08 at 21:50 -0800, Kirtika Ruchandani wrote:
> shift_param is defined and set in iwl_pcie_load_cpu_sections
> but not used. Fix this to avoid -Wunused-but-set-variable
> warning.
> The code using it turned into dead code with commit dcab8ecd5617
> which added a separate function iwl_pcie_load_given_ucode_8000
> (then 8000b) for IWL_DEVICE_FAMILY_8000. Commit 76f8c0e17edc
> removed the dead code but left shift_param as is.
>
> iwlwifi/pcie/trans.c: In function ‘iwl_pcie_load_cpu_sections’:
> iwlwifi/pcie/trans.c:871:6: warning: variable ‘shift_param’ set but not used [-Wunused-but-set-variable]
>
> Fixes: dcab8ecd5617 (iwlwifi: mvm: support ucode load for family_8000 B0 only)
> Fixes: 76f8c0e17edc (iwlwifi: pcie: remove dead code)
>
> Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
> Cc: Sara Sharon <sara.sharon@intel.com>
> Cc: Luca Coelho <luciano.coelho@intel.com>
> Cc: Eran Harary <eran.harary@intel.com>
I'll remove Harary's Cc here too, since this email is not valid anymore
and I don't know his new one (and he probably doesn't care anymore
anyway).
--
Luca.
^ permalink raw reply
* RE: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs
From: Amitkumar Karwar @ 2016-11-09 7:51 UTC (permalink / raw)
To: Brian Norris, Nishant Sarmukadam, Kalle Valo
Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
Cathy Luo, security@kernel.org, stable@vger.kernel.org
In-Reply-To: <1478658504-31045-1-git-send-email-briannorris@chromium.org>
> From: Brian Norris [mailto:briannorris@chromium.org]
> Sent: Wednesday, November 09, 2016 7:58 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; Cathy
> Luo; security@kernel.org; stable@vger.kernel.org; Brian Norris
> Subject: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs
>
> SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
> when we print them out.
>
> This can be easily noticed by connecting to a network with a 32-octet
> SSID:
>
> [ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to
> '0123456789abcdef0123456789abcdef <uninitialized mem>' bssid
> xx:xx:xx:xx:xx:xx
>
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell
> mwifiex driver")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Cc: <stable@vger.kernel.org>
> ---
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index 39ce76ad00bc..16241d21727b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -2222,8 +2222,9 @@ mwifiex_cfg80211_assoc(struct mwifiex_private
> *priv, size_t ssid_len,
> is_scanning_required = 1;
> } else {
> mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to associate to '%s' bssid
> %pM\n",
> - (char *)req_ssid.ssid, bss->bssid);
> + "info: trying to associate to '%.*s' bssid
> %pM\n",
> + req_ssid.ssid_len, (char *)req_ssid.ssid,
> + bss->bssid);
> memcpy(&priv->cfg_bssid, bss->bssid, ETH_ALEN);
> break;
> }
> @@ -2283,8 +2284,8 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy,
> struct net_device *dev,
> }
>
> mwifiex_dbg(adapter, INFO,
> - "info: Trying to associate to %s and bssid %pM\n",
> - (char *)sme->ssid, sme->bssid);
> + "info: Trying to associate to %.*s and bssid %pM\n",
> + (int)sme->ssid_len, (char *)sme->ssid, sme->bssid);
>
> if (!mwifiex_stop_bg_scan(priv))
> cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
> @@ -2417,8 +2418,8 @@ mwifiex_cfg80211_join_ibss(struct wiphy *wiphy,
> struct net_device *dev,
> }
>
> mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to join to %s and bssid %pM\n",
> - (char *)params->ssid, params->bssid);
> + "info: trying to join to %.*s and bssid %pM\n",
> + params->ssid_len, (char *)params->ssid, params->bssid);
>
> mwifiex_set_ibss_params(priv, params);
>
> --
> 2.8.0.rc3.226.g39d4020
Thanks for fixing this.
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH] wireless: fix bogus maybe-uninitialized warning
From: Johannes Berg @ 2016-11-09 8:10 UTC (permalink / raw)
To: Kalle Valo, Arnd Bergmann
Cc: Stanislav Yakovlev, Jouni Malinen, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <87mvh9qwhi.fsf@purkki.adurom.net>
> Ideally we prefer that drivers/net/wireless and net/wireless changes
> are
> split into different patches as they get applied to different trees.
> Johannes, is it ok if I take this change through my tree this time?
Sure, please do, thanks.
(I don't particularly care about the lib80211 stuff anyway)
johannes
^ permalink raw reply
* RE: [PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()
From: Amitkumar Karwar @ 2016-11-09 8:53 UTC (permalink / raw)
To: Ricky Liang
Cc: Nishant Sarmukadam, Kalle Valo,
open list:MARVELL MWIFIEX WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <1478662648-70698-1-git-send-email-jcliang@chromium.org>
> From: Ricky Liang [mailto:jcliang@chromium.org]
> Sent: Wednesday, November 09, 2016 9:07 AM
> Cc: Ricky Liang; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; open
> list:MARVELL MWIFIEX WIRELESS DRIVER; open list:NETWORKING DRIVERS; open
> list
> Subject: [PATCH] mwifiex: fix memory leak in
> mwifiex_save_hidden_ssid_channels()
>
> kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels():
>
> unreferenced object 0xffffffc0a2914780 (size 192):
> comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s)
> hex dump (first 32 bytes):
> 00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@
> 07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04 ..TW 4..d.$..$..
> backtrace:
> [<ffffffc0003375f4>] create_object+0x164/0x2b4
> [<ffffffc0008e3530>] kmemleak_alloc+0x50/0x88
> [<ffffffc000335120>] __kmalloc_track_caller+0x1bc/0x264
> [<ffffffc00030899c>] kmemdup+0x38/0x64
> [<ffffffbffc2311cc>] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex]
> [<ffffffbffc22ee9c>] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex]
> [<ffffffbffc22f45c>]
> mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex]
> [<ffffffbffc2375d0>] mwifiex_process_sta_event+0x378/0x898 [mwifiex]
> [<ffffffbffc224dc8>] mwifiex_process_event+0x1a8/0x1e8 [mwifiex]
> [<ffffffbffc2228f0>] mwifiex_main_process+0x258/0x534 [mwifiex]
> [<ffffffbffc258858>] 0xffffffbffc258858
> [<ffffffc00071ee90>] process_sdio_pending_irqs+0xf8/0x160
> [<ffffffc00071efdc>] sdio_irq_thread+0x9c/0x1a4
> [<ffffffc000240d08>] kthread+0xf4/0x100
> [<ffffffc0002043fc>] ret_from_fork+0xc/0x50
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> Signed-off-by: Ricky Liang <jcliang@chromium.org>
> ---
> drivers/net/wireless/marvell/mwifiex/scan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
> b/drivers/net/wireless/marvell/mwifiex/scan.c
> index 97c9765..98ce072 100644
> --- a/drivers/net/wireless/marvell/mwifiex/scan.c
> +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
> @@ -1671,6 +1671,10 @@ static int
> mwifiex_save_hidden_ssid_channels(struct mwifiex_private *priv,
> }
>
> done:
> + /* beacon_ie buffer was allocated in function
> + * mwifiex_fill_new_bss_desc(). Free it now.
> + */
> + kfree(bss_desc->beacon_buf);
> kfree(bss_desc);
> return 0;
> }
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Regards,
Amitkumar
^ permalink raw reply
* Re: [v5] ath9k: Switch to using mac80211 intermediate software queues.
From: Toke Høiland-Jørgensen @ 2016-11-09 10:42 UTC (permalink / raw)
To: Tim Shepard; +Cc: Kalle Valo, make-wifi-fast, linux-wireless, Felix Fietkau
In-Reply-To: <E1c4IsV-0003Rk-00@www.xplot.org>
Tim Shepard <shep@alum.mit.edu> writes:
>> While at it, could you also add to the commit log some info how awesome this
>> patch is from user's point of view and how it helps. For example, before and
>> and after numbers and other results.
>
> That varies wildly, depending on many details of the scenario
> (including the wireless capabilities of the clients connected to the
> AP using this patch, and how far away those clients are). There's
> really not enough room in a commit message to explain enough to make
> any such claimed numbers reproducible.
I disagree; it's quite straightforward to demonstrate a gain from this
on an ath9k access point. And while of course the mac80211 queues is the
reason for this, the commit that uses it (i.e. this one) can explain
that and include some numbers. I'll add that and resend :)
-Toke
^ permalink raw reply
* Re: [PATCH 1/4] ath10k: Add support to enable or disable btcoex via nl80211
From: Tamizh chelvam @ 2016-11-09 10:45 UTC (permalink / raw)
To: kbuild test robot; +Cc: c_traja, kbuild-all, ath10k, linux-wireless
In-Reply-To: <201611090758.VuakpqyK%fengguang.wu@intel.com>
On 2016-11-09 04:50, kbuild test robot wrote:
> Hi Tamizh,
>
> [auto build test WARNING on ath6kl/ath-next]
> [also build test WARNING on v4.9-rc4 next-20161108]
> [if your patch is applied to the wrong git tree, please drop us a note
> to help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/c_traja-qti-qualcomm-com/ath10k-Add-support-for-BTCOEX-feature/20161109-043718
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
> ath-next
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 4.9.0
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=xtensa
>
> All warnings (new ones prefixed by >>):
>
> drivers/net/wireless/ath/ath10k/mac.c:7548:2: error: unknown field
> 'set_btcoex' specified in initializer
> .set_btcoex = ath10k_mac_op_set_btcoex,
> ^
>>> drivers/net/wireless/ath/ath10k/mac.c:7548:2: warning: initialization
>>> from incompatible pointer type
> drivers/net/wireless/ath/ath10k/mac.c:7548:2: warning: (near
> initialization for 'ath10k_ops.reconfig_complete')
This patch has dependency of "cfg80211: mac80211: BTCOEX feature
support" patchset.
>
> vim +7548 drivers/net/wireless/ath/ath10k/mac.c
>
> 7532 .reconfig_complete = ath10k_reconfig_complete,
> 7533 .get_survey = ath10k_get_survey,
> 7534 .set_bitrate_mask = ath10k_mac_op_set_bitrate_mask,
> 7535 .sta_rc_update = ath10k_sta_rc_update,
> 7536 .get_tsf = ath10k_get_tsf,
> 7537 .set_tsf = ath10k_set_tsf,
> 7538 .ampdu_action = ath10k_ampdu_action,
> 7539 .get_et_sset_count = ath10k_debug_get_et_sset_count,
> 7540 .get_et_stats = ath10k_debug_get_et_stats,
> 7541 .get_et_strings = ath10k_debug_get_et_strings,
> 7542 .add_chanctx = ath10k_mac_op_add_chanctx,
> 7543 .remove_chanctx = ath10k_mac_op_remove_chanctx,
> 7544 .change_chanctx = ath10k_mac_op_change_chanctx,
> 7545 .assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
> 7546 .unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
> 7547 .switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
>> 7548 .set_btcoex = ath10k_mac_op_set_btcoex,
> 7549
> 7550 CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
> 7551
> 7552 #ifdef CONFIG_PM
> 7553 .suspend = ath10k_wow_op_suspend,
> 7554 .resume = ath10k_wow_op_resume,
> 7555 #endif
> 7556 #ifdef CONFIG_MAC80211_DEBUGFS
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology
> Center
> https://lists.01.org/pipermail/kbuild-all Intel
> Corporation
^ permalink raw reply
* Re: [PATCH 2/4] ath10k: Add support to update btcoex priority value via nl80211
From: Tamizh chelvam @ 2016-11-09 10:46 UTC (permalink / raw)
To: kbuild test robot; +Cc: c_traja, kbuild-all, ath10k, linux-wireless
In-Reply-To: <201611090753.f8QniYub%fengguang.wu@intel.com>
On 2016-11-09 05:19, kbuild test robot wrote:
> Hi Tamizh,
>
> [auto build test ERROR on ath6kl/ath-next]
> [cannot apply to v4.9-rc4 next-20161108]
> [if your patch is applied to the wrong git tree, please drop us a note
> to help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/c_traja-qti-qualcomm-com/ath10k-Add-support-for-BTCOEX-feature/20161109-043718
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
> ath-next
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 4.9.0
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=xtensa
>
> All error/warnings (new ones prefixed by >>):
>
>>> drivers/net/wireless/ath/ath10k/mac.c:7508:35: warning: 'struct
>>> cfg80211_btcoex_priority' declared inside parameter list
> ath10k_mac_get_btcoex_prio(struct cfg80211_btcoex_priority
> *btcoex_priority)
> ^
>>> drivers/net/wireless/ath/ath10k/mac.c:7508:35: warning: its scope is
>>> only this definition or declaration, which is probably not what you
>>> want
> drivers/net/wireless/ath/ath10k/mac.c: In function
> 'ath10k_mac_get_btcoex_prio':
>>> drivers/net/wireless/ath/ath10k/mac.c:7512:21: error: dereferencing
>>> pointer to incomplete type
> if (btcoex_priority->wlan_be_preferred)
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7513:18: error:
> 'WIPHY_WLAN_BE_PREFERRED' undeclared (first use in this function)
> btcoex_prio |= WIPHY_WLAN_BE_PREFERRED;
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7513:18: note: each
> undeclared identifier is reported only once for each function it
> appears in
> drivers/net/wireless/ath/ath10k/mac.c:7515:21: error: dereferencing
> pointer to incomplete type
> if (btcoex_priority->wlan_bk_preferred)
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7516:18: error:
> 'WIPHY_WLAN_BK_PREFERRED' undeclared (first use in this function)
> btcoex_prio |= WIPHY_WLAN_BK_PREFERRED;
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7518:21: error: dereferencing
> pointer to incomplete type
> if (btcoex_priority->wlan_vi_preferred)
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7519:18: error:
> 'WIPHY_WLAN_VI_PREFERRED' undeclared (first use in this function)
> btcoex_prio |= WIPHY_WLAN_VI_PREFERRED;
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7521:21: error: dereferencing
> pointer to incomplete type
> if (btcoex_priority->wlan_vo_preferred)
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7522:18: error:
> 'WIPHY_WLAN_VO_PREFERRED' undeclared (first use in this function)
> btcoex_prio |= WIPHY_WLAN_VO_PREFERRED;
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7524:21: error: dereferencing
> pointer to incomplete type
> if (btcoex_priority->wlan_beacon_preferred)
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7525:18: error:
> 'WIPHY_WLAN_BEACON_PREFERRED' undeclared (first use in this function)
> btcoex_prio |= WIPHY_WLAN_BEACON_PREFERRED;
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7527:21: error: dereferencing
> pointer to incomplete type
> if (btcoex_priority->wlan_mgmt_preferred)
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7528:18: error:
> 'WIPHY_WLAN_MGMT_PREFERRED' undeclared (first use in this function)
> btcoex_prio |= WIPHY_WLAN_MGMT_PREFERRED;
> ^
> drivers/net/wireless/ath/ath10k/mac.c: At top level:
> drivers/net/wireless/ath/ath10k/mac.c:7534:11: warning: 'struct
> cfg80211_btcoex_priority' declared inside parameter list
> struct cfg80211_btcoex_priority *btcoex_priority)
> ^
> drivers/net/wireless/ath/ath10k/mac.c: In function
> 'ath10k_mac_op_set_btcoex_priority':
>>> drivers/net/wireless/ath/ath10k/mac.c:7553:16: warning: passing
>>> argument 1 of 'ath10k_mac_get_btcoex_prio' from incompatible pointer
>>> type
> btcoex_prio = ath10k_mac_get_btcoex_prio(btcoex_priority);
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7508:1: note: expected
> 'struct cfg80211_btcoex_priority *' but argument is of type 'struct
> cfg80211_btcoex_priority *'
> ath10k_mac_get_btcoex_prio(struct cfg80211_btcoex_priority
> *btcoex_priority)
> ^
> drivers/net/wireless/ath/ath10k/mac.c: At top level:
> drivers/net/wireless/ath/ath10k/mac.c:7611:2: error: unknown field
> 'set_btcoex' specified in initializer
> .set_btcoex = ath10k_mac_op_set_btcoex,
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7611:2: warning:
> initialization from incompatible pointer type
> drivers/net/wireless/ath/ath10k/mac.c:7611:2: warning: (near
> initialization for 'ath10k_ops.reconfig_complete')
> drivers/net/wireless/ath/ath10k/mac.c:7612:2: error: unknown field
> 'set_btcoex_priority' specified in initializer
> .set_btcoex_priority = ath10k_mac_op_set_btcoex_priority,
> ^
> drivers/net/wireless/ath/ath10k/mac.c:7612:2: warning:
> initialization from incompatible pointer type
> drivers/net/wireless/ath/ath10k/mac.c:7612:2: warning: (near
> initialization for 'ath10k_ops.ipv6_addr_change')
> drivers/net/wireless/ath/ath10k/mac.c: In function
> 'ath10k_mac_register':
> drivers/net/wireless/ath/ath10k/mac.c:8203:16: error: 'struct
> wiphy' has no member named 'btcoex_support_flags'
> ar->hw->wiphy->btcoex_support_flags =
> ^
> drivers/net/wireless/ath/ath10k/mac.c:8204:4: error:
> 'WIPHY_WLAN_BE_PREFERRED' undeclared (first use in this function)
> WIPHY_WLAN_BE_PREFERRED |
> ^
> drivers/net/wireless/ath/ath10k/mac.c:8205:4: error:
> 'WIPHY_WLAN_BK_PREFERRED' undeclared (first use in this function)
> WIPHY_WLAN_BK_PREFERRED |
> ^
> drivers/net/wireless/ath/ath10k/mac.c:8206:4: error:
> 'WIPHY_WLAN_VI_PREFERRED' undeclared (first use in this function)
> WIPHY_WLAN_VI_PREFERRED |
> ^
> drivers/net/wireless/ath/ath10k/mac.c:8207:4: error:
> 'WIPHY_WLAN_VO_PREFERRED' undeclared (first use in this function)
> WIPHY_WLAN_VO_PREFERRED |
> ^
> drivers/net/wireless/ath/ath10k/mac.c:8208:4: error:
> 'WIPHY_WLAN_BEACON_PREFERRED' undeclared (first use in this function)
> WIPHY_WLAN_BEACON_PREFERRED |
> ^
> drivers/net/wireless/ath/ath10k/mac.c:8209:4: error:
> 'WIPHY_WLAN_MGMT_PREFERRED' undeclared (first use in this function)
> WIPHY_WLAN_MGMT_PREFERRED;
> ^
> drivers/net/wireless/ath/ath10k/mac.c:8211:20: error: 'struct
> wiphy' has no member named 'btcoex_support_flags'
> ar->hw->wiphy->btcoex_support_flags);
> ^
>
This patch has dependency of "cfg80211: mac80211: BTCOEX feature
support" patchset.
> vim +7512 drivers/net/wireless/ath/ath10k/mac.c
>
> 7502 mutex_unlock(&ar->conf_mutex);
> 7503
> 7504 return ret;
> 7505 }
> 7506
> 7507 u32
>> 7508 ath10k_mac_get_btcoex_prio(struct cfg80211_btcoex_priority
>> *btcoex_priority)
> 7509 {
> 7510 u32 btcoex_prio = 0;
> 7511
>> 7512 if (btcoex_priority->wlan_be_preferred)
> 7513 btcoex_prio |= WIPHY_WLAN_BE_PREFERRED;
> 7514
> 7515 if (btcoex_priority->wlan_bk_preferred)
> 7516 btcoex_prio |= WIPHY_WLAN_BK_PREFERRED;
> 7517
> 7518 if (btcoex_priority->wlan_vi_preferred)
> 7519 btcoex_prio |= WIPHY_WLAN_VI_PREFERRED;
> 7520
> 7521 if (btcoex_priority->wlan_vo_preferred)
> 7522 btcoex_prio |= WIPHY_WLAN_VO_PREFERRED;
> 7523
> 7524 if (btcoex_priority->wlan_beacon_preferred)
> 7525 btcoex_prio |= WIPHY_WLAN_BEACON_PREFERRED;
> 7526
> 7527 if (btcoex_priority->wlan_mgmt_preferred)
>> 7528 btcoex_prio |= WIPHY_WLAN_MGMT_PREFERRED;
> 7529
> 7530 return btcoex_prio;
> 7531 }
> 7532
> 7533 static int ath10k_mac_op_set_btcoex_priority(struct ieee80211_hw
> *hw,
> 7534 struct cfg80211_btcoex_priority *btcoex_priority)
> 7535 {
> 7536 u32 btcoex_prio;
> 7537 struct ath10k *ar = hw->priv;
> 7538 int ret;
> 7539
> 7540 if (!(test_bit(ATH10K_FLAG_BTCOEX, &ar->dev_flags))) {
> 7541 ret = -EINVAL;
> 7542 goto exit;
> 7543 }
> 7544
> 7545 mutex_lock(&ar->conf_mutex);
> 7546
> 7547 if (ar->state != ATH10K_STATE_ON &&
> 7548 ar->state != ATH10K_STATE_RESTARTED) {
> 7549 ret = -ENETDOWN;
> 7550 goto exit;
> 7551 }
> 7552
>> 7553 btcoex_prio = ath10k_mac_get_btcoex_prio(btcoex_priority);
> 7554
> 7555 if (btcoex_prio > 0x3f)
> 7556 return -E2BIG;
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology
> Center
> https://lists.01.org/pipermail/kbuild-all Intel
> Corporation
^ 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