* Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Masashi Honma @ 2016-07-26 3:41 UTC (permalink / raw)
To: Yaniv Machani, linux-kernel
Cc: Meirav Kama, Johannes Berg, David S. Miller, linux-wireless,
netdev
In-Reply-To: <40a34537-486e-a466-5a7e-e253f19d81c3@gmail.com>
On 2016年07月22日 14:26, Masashi Honma wrote:
> On 2016年07月14日 05:07, Yaniv Machani wrote:
>> +
>> + /* if channel width is 20MHz - configure HT capab accordingly*/
>> + if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
>> + cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
>> + cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
>> + }
>
> I have tested this part of your patch and this works for me.
>
> Previouly, "Supported Channel Width Set bit" in HT Capabilities element
> was 1 even though disable_ht40=1 existed in wpa_supplicant.conf.
> After appllication of patch, the bit was 0.
>
>
# I retransmit this because of mail delivery errors.
I forgot to mention I have used this patch to test.
http://lists.infradead.org/pipermail/hostap/2016-July/036029.html
^ permalink raw reply
* Re: [v3] UCC_GETH/UCC_FAST: Use IS_ERR_VALUE_U32 API to avoid IS_ERR_VALUE abuses.
From: David Miller @ 2016-07-26 0:48 UTC (permalink / raw)
To: arvind.yadav.cs
Cc: zajec5, leoli, qiang.zhao, scottwood, viresh.kumar, akpm,
linux-wireless, netdev, linuxppc-dev, linux, arnd
In-Reply-To: <1469297151-9763-1-git-send-email-arvind.yadav.cs@gmail.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Sat, 23 Jul 2016 23:35:51 +0530
> However, anything that passes an 'unsigned short' or 'unsigned int'
> argument into IS_ERR_VALUE() is guaranteed to be broken, as are
> 8-bit integers and types that are wider than 'unsigned long'.
...
> Passing value in IS_ERR_VALUE() is wrong, as they pass an
> 'unsigned int' into a function that takes an 'unsigned long'
> argument.This happens to work because the type is sign-extended
> on 64-bit architectures before it gets converted into an
> unsigned type.
This commit log message is a complete mess, you're saying exactly
the same thing over and over again.
Also your Subject line is not formatted correctly, do not list
the subsystem prefix in ALL CAPS. Just plain "ucc_geth/ucc_fast: "
would be fine.
^ permalink raw reply
* [NetDev] [ANNOUNCE] Netdev 1.2 updates (Tokyo, Japan, October 5-7)
From: Hajime Tazaki @ 2016-07-25 22:36 UTC (permalink / raw)
To: netdev, netfilter-devel, linux-wireless, netdev-conference
Hello,
We'd like to share the interesting updates of coming netdev
1.2, held in Tokyo, Japan on October 5-7.
We have already accepted a great series of sessions and more
to coming soon.
http://netdevconf.org/1.2/accepted-sessions.html
* Workshop
- XDP workshop: Introduction, experience, and future
development (Tom Herbert)
- TC extended workshop proposal (Jamal Hadi Salim)
* Talk
- Encapsulation Offloads LCO, GSO_PARTIAL, TSO_MANGLEID, and
Why Less is More (Alexander Duyck)
- User Space TCP - Getting LKL ready for the Prime Time Use
(Jerry Chu, Yuan Liu)
The call for proposals is still opened so we'd be waiting
for your great talk proposals too.
Twitter: https://twitter.com/netdev01
Web: http://netdevconf.org/1.2/
Registration: http://netdevconf.org/1.2/registration.html
We also got new sponsors from Google as a Gold Sponsor, and
Netronome as a Silver Sponsor. Thank you for all your
supports !
-- Hajime
^ permalink raw reply
* BRCM4339 NVRAM file
From: Fabio Estevam @ 2016-07-25 20:36 UTC (permalink / raw)
To: frankyl, Arend van Spriel, pieterpg, John Linville; +Cc: linux-wireless
Hi,
I am trying to use brcm4339 on a imx6ul-pico board running kernel 4.7.
According to commit bed89b64bcbc7 (" brcmfmac: add firmware and nvram
file name for bcm4339") we need to provide brcmfmac4339-sdio.bin and
brcmfmac4339-sdio.txt files.
Was able to get the brcmfmac4339-sdio.bin from linux-firmware git
tree, but could not find the nvram file: brcmfmac4339-sdio.txt.
Does anyone know where brcmfmac4339-sdio.txt can be found?
Thanks,
Fabio Estevam
^ permalink raw reply
* Re: [PATCH 3/3] staging: wilc1000: Reduce scope for a few variables in mac_ioctl()
From: walter harms @ 2016-07-25 19:32 UTC (permalink / raw)
To: Lino Sanfilippo; +Cc: SF Markus Elfring, LKML, kernel-janitors, linux-wireless
In-Reply-To: <1c4cac35-dded-ea88-45aa-3f8ac098289d@gmx.de>
Am 25.07.2016 21:17, schrieb Lino Sanfilippo:
>>
>> - if (strncasecmp(buff, "RSSI", length) == 0) {
>> + if (strncasecmp(buff, "RSSI", 0) == 0) {
>> + s8 rssi;
>> +
>
> Um, please think a second about if it makes any sense at all to compare
> zero chars of two strings.
>
> Lino
also:
the switch has only one case and default.
re,
wh
^ permalink raw reply
* Re: [PATCH 3/3] staging: wilc1000: Reduce scope for a few variables in mac_ioctl()
From: Lino Sanfilippo @ 2016-07-25 19:17 UTC (permalink / raw)
To: SF Markus Elfring; +Cc: LKML, kernel-janitors, linux-wireless
>
> - if (strncasecmp(buff, "RSSI", length) == 0) {
> + if (strncasecmp(buff, "RSSI", 0) == 0) {
> + s8 rssi;
> +
Um, please think a second about if it makes any sense at all to compare
zero chars of two strings.
Lino
^ permalink raw reply
* [PATCH] bcma: support BCM53573 series of wireless SoCs
From: Rafał Miłecki @ 2016-07-25 18:33 UTC (permalink / raw)
To: Kalle Valo
Cc: Rafał Miłecki,
open list:BROADCOM SPECIFIC AMBA DRIVER (BCMA), open list
BCM53573 seems to be the first series of Northstar family with wireless
on the chip. The base models are BCM53573-s (A0, A1) and there is also
BCM47189B0 which seems to be some small modification.
The only problem with these chipsets seems to be watchdog. It's totally
unavailable on 53573A0 / 53573A1 and preferable PMU watchdog is broken
on 53573B0 / 53573B1.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/bcma/driver_chipcommon.c | 32 +++++++++++++++++++++++++++++---
include/linux/bcma/bcma.h | 3 +++
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/bcma/driver_chipcommon.c b/drivers/bcma/driver_chipcommon.c
index 921ce18..b4f6520 100644
--- a/drivers/bcma/driver_chipcommon.c
+++ b/drivers/bcma/driver_chipcommon.c
@@ -36,12 +36,31 @@ u32 bcma_chipco_get_alp_clock(struct bcma_drv_cc *cc)
}
EXPORT_SYMBOL_GPL(bcma_chipco_get_alp_clock);
+static bool bcma_core_cc_has_pmu_watchdog(struct bcma_drv_cc *cc)
+{
+ struct bcma_bus *bus = cc->core->bus;
+
+ if (cc->capabilities & BCMA_CC_CAP_PMU) {
+ if (bus->chipinfo.id == BCMA_CHIP_ID_BCM53573) {
+ WARN(bus->chipinfo.rev <= 1, "No watchdog available\n");
+ /* 53573B0 and 53573B1 have bugged PMU watchdog. It can
+ * be enabled but timer can't be bumped. Use CC one
+ * instead.
+ */
+ return false;
+ }
+ return true;
+ } else {
+ return false;
+ }
+}
+
static u32 bcma_chipco_watchdog_get_max_timer(struct bcma_drv_cc *cc)
{
struct bcma_bus *bus = cc->core->bus;
u32 nb;
- if (cc->capabilities & BCMA_CC_CAP_PMU) {
+ if (bcma_core_cc_has_pmu_watchdog(cc)) {
if (bus->chipinfo.id == BCMA_CHIP_ID_BCM4706)
nb = 32;
else if (cc->core->id.rev < 26)
@@ -95,9 +114,16 @@ static int bcma_chipco_watchdog_ticks_per_ms(struct bcma_drv_cc *cc)
int bcma_chipco_watchdog_register(struct bcma_drv_cc *cc)
{
+ struct bcma_bus *bus = cc->core->bus;
struct bcm47xx_wdt wdt = {};
struct platform_device *pdev;
+ if (bus->chipinfo.id == BCMA_CHIP_ID_BCM53573 &&
+ bus->chipinfo.rev <= 1) {
+ pr_debug("No watchdog on 53573A0 / 53573A1\n");
+ return 0;
+ }
+
wdt.driver_data = cc;
wdt.timer_set = bcma_chipco_watchdog_timer_set_wdt;
wdt.timer_set_ms = bcma_chipco_watchdog_timer_set_ms_wdt;
@@ -105,7 +131,7 @@ int bcma_chipco_watchdog_register(struct bcma_drv_cc *cc)
bcma_chipco_watchdog_get_max_timer(cc) / cc->ticks_per_ms;
pdev = platform_device_register_data(NULL, "bcm47xx-wdt",
- cc->core->bus->num, &wdt,
+ bus->num, &wdt,
sizeof(wdt));
if (IS_ERR(pdev))
return PTR_ERR(pdev);
@@ -217,7 +243,7 @@ u32 bcma_chipco_watchdog_timer_set(struct bcma_drv_cc *cc, u32 ticks)
u32 maxt;
maxt = bcma_chipco_watchdog_get_max_timer(cc);
- if (cc->capabilities & BCMA_CC_CAP_PMU) {
+ if (bcma_core_cc_has_pmu_watchdog(cc)) {
if (ticks == 1)
ticks = 2;
else if (ticks > maxt)
diff --git a/include/linux/bcma/bcma.h b/include/linux/bcma/bcma.h
index e6b41f4..478e5cf 100644
--- a/include/linux/bcma/bcma.h
+++ b/include/linux/bcma/bcma.h
@@ -204,6 +204,9 @@ struct bcma_host_ops {
#define BCMA_PKG_ID_BCM4709 0
#define BCMA_CHIP_ID_BCM47094 53030
#define BCMA_CHIP_ID_BCM53018 53018
+#define BCMA_CHIP_ID_BCM53573 53573
+#define BCMA_PKG_ID_BCM53573 0
+#define BCMA_PKG_ID_BCM47189 1
/* Board types (on PCI usually equals to the subsystem dev id) */
/* BCM4313 */
--
1.8.4.5
^ permalink raw reply related
* Re: pull-request: wireless-drivers-next 2016-07-22
From: David Miller @ 2016-07-25 18:10 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel, computersforpeace
In-Reply-To: <87fur1rbkz.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Fri, 22 Jul 2016 17:28:44 +0300
> I'm sick so I have to keep this short, but here's the last pull request
> to net-next. This time there's a trivial conflict with mtd tree:
>
> http://lkml.kernel.org/g/20160720123133.44dab209@canb.auug.org.au
>
> We concluded with Brian (CCed) that it's best that we ask Linus to fix
> this. The patches have been in linux-next for a couple of days. This
> time I haven't done any merge tests so I don't know if there are any
> other conflicts etc.
>
> Please let me know if there are any problems.
Ok, pulled, thanks Kalle.
Feel better soon.
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Dan Williams @ 2016-07-25 16:17 UTC (permalink / raw)
To: Christopher Williamson, linux-wireless@vger.kernel.org,
Arend Van Spriel
In-Reply-To: <CANXHH3m3xzq1cmX+Xni8NnB9tQ+587to2D4oJij8dK3RGg1Yug@mail.gmail.com>
On Sat, 2016-07-23 at 06:26 -0700, Christopher Williamson wrote:
> Quick follow-up - I suspected the issue may be with wpa_supplicant
> rather than udev / kernel config.
>
> Since this does connect properly on open wireless networks the issue
> is now only with WPA/WPA2.
>
> It seems even the latest dev builds of Ubuntu are still stuck using
> wpa_supplicant 2.4.x rather than hopping over to 2.5 which I believe
> contains a fix needed for the libertas chipset to properly
> authenticate with WPA/WPA2 networks.
>
> I therefore decided to compile version 2.5 of wpa_supplicant myself
> and install it on a Ubuntu 16.04.1 clean install - looks like that
> actually fixed the problem.
>
> So the end result is - the ubuntu 2.4 wpa_supplicant doesn’t work
> with
> libertas+libertas_sdio but it *does* work properly with
> wpa_supplicant
> 2.5.
Can you get supplicant logs for both 2.4 and 2.5 and we can maybe
figure out what the difference is, just for the record?
Dan
> Christopher Williamson
>
>
> On 23 July 2016 at 13:29:41, Christopher Williamson
> (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> >
> > Just to follow up on this - I performed a minimal ubuntu server
> > install (16.04.1), commented out the crda udev rule (since that was
> > setting the weird country: 98 issue) and tried again and it still
> > didn’t work.
> >
> > I did confirm that the md5 sums for the firmware included with Arch
> > is the exact same as the firmware included for Ubuntu 16.04.1 so
> > there was no difference there.
> >
> > At this point I’m thinking it’s either:
> >
> > - Some Ubuntu-specific udev rule breaking things or:
> > - A difference in the kernel config between Arch and Ubuntu
> >
> > I think I’m going to forfeit for now and switch over to Arch -
> > spent several days on this already. If anyone has any other ideas
> > on what could be causing this please do let me know and I’ll follow
> > up if I experiment this with again.
> >
> > Christopher Williamson
> >
> >
> >
> >
> > On 22 July 2016 at 22:47:15, Christopher Williamson (home@chrisaw.c
> > om(mailto:home@chrisaw.com)) wrote:
> >
> > >
> > >
> > > Hi all,
> > >
> > > So I decided to have another fiddle with this and managed to get
> > > the WiFi working perfectly first time on an ArchLinux LiveCD so
> > > it looks like this issue is Ubuntu specific.
> > >
> > > I’m going to copy the firmware files and check if they’re
> > > responsible and work my way through the various differences but
> > > at least I know this device can work properly on the Linux 4.6.3
> > > (which the livecd is based on.)
> > >
> > > I’ll follow up if and when I find out what the cause of the
> > > problem was.
> > >
> > > Christopher Williamson
> > >
> > >
> > >
> > >
> > > On 22 July 2016 at 22:42:50, Christopher Williamson (home@chrisaw
> > > .com(mailto:home@chrisaw.com)) wrote:
> > >
> > > >
> > > > Hi all,
> > > >
> > > > So I decided to have another fiddle with this and managed to
> > > > get the WiFi working perfectly first time on an ArchLinux
> > > > LiveCD so it looks like this issue is Ubuntu specific.
> > > >
> > > > I’m going to copy the firmware files and check if they’re
> > > > responsible and work my way through the various differences but
> > > > at least I know this device can work properly on the Linux
> > > > 4.6.3 (which the livecd is based on.)
> > > >
> > > > I’ll follow up if and when I find out what the cause of the
> > > > problem was.
> > > > Christopher Williamson
> > > > www.chrisaw.com(http://www.chrisaw.com)
> > > >
> > > >
> > > >
> > > >
> > > > On 22 July 2016 at 18:17:20, Christopher Williamson (home@chris
> > > > aw.com(mailto:home@chrisaw.com)) wrote:
> > > >
> > > > >
> > > > > I haven’t managed to get connected to a WPA network either so
> > > > > it looks like open only at the moment but I fear that may
> > > > > just have been a fluke.
> > > > >
> > > > > A big problem I’m facing is that editing /etc/default/crda to
> > > > > REGDOMAIN=GB wasn’t enough to set the wifi regulation mode to
> > > > > GB and I have to set it manually. This sometimes works and
> > > > > sometimes reports the following:
> > > > >
> > > > > country 98: DFS-UNSET
> > > > > (2402 - 2472 @ 40), (N/A, 20), (N/A)
> > > > > (2457 - 2472 @ 15), (N/A, 20), (N/A), NO-IR
> > > > > (5170 - 5250 @ 80), (N/A, 17), (N/A), NO-IR
> > > > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, NO-IR
> > > > > (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR
> > > > > (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR
> > > > > (57240 - 63720 @ 2160), (N/A, 0), (N/A)
> > > > >
> > > > > At best this is simply an annoyance but at worst I’m thinking
> > > > > this may be responsible for the issues I’m seeing.
> > > > >
> > > > > Is there anywhere else I can force this to be set to GB?
> > > > >
> > > > > Christopher Williamson
> > > > >
> > > > >
> > > > > On 22 July 2016 at 17:54:40, Christopher Williamson (home@chr
> > > > > isaw.com(mailto:home@chrisaw.com)) wrote:
> > > > >
> > > > > >
> > > > > > Disregard - I have actually managed to get this to connect
> > > > > > to a open network!
> > > > > >
> > > > > > # iw reg set GB
> > > > > > # iw reg get
> > > > > > country GB: DFS-ETSI
> > > > > > (2402 - 2482 @ 40), (N/A, 20), (N/A)
> > > > > > (5170 - 5250 @ 80), (N/A, 20), (N/A)
> > > > > > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
> > > > > > (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> > > > > > (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> > > > > > # iwconfig wlan0 essid "shaunthesheep-guest”
> > > > > > # dhclient wlan0
> > > > > >
> > > > > > It’s good to have some progress - so it looks like the
> > > > > > issue preventing the previous connection was the iw reg not
> > > > > > being set properly (or possibly just wpa_supplicant borking
> > > > > > the connection in some way. I stopped that this time
> > > > > > around. I’ll try wpa1 now and report back.
> > > > > >
> > > > > >
> > > > > > Christopher Williamson
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 22 July 2016 at 17:39:50, Christopher Williamson (home@c
> > > > > > hrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Ok so I created a guest wifi network without any
> > > > > > > encryption enabled at all and the client still refuses to
> > > > > > > connect.
> > > > > > >
> > > > > > > Again, the connection is made perfectly using the USB
> > > > > > > dongle I have but not the built in libertas sd8686
> > > > > > > chipset.
> > > > > > >
> > > > > > > I do currently use pfSense as a firewall box behind my
> > > > > > > wireless router (acting as an AP) and can see that no
> > > > > > > DHCP request is making it to the pfSense box. I believe
> > > > > > > you are right in the point about the firmware being the
> > > > > > > problem here.
> > > > > > >
> > > > > > > I should also confirm - the firmware in use is the latest
> > > > > > > from the linux-firmware Ubuntu 16.04 package. I did read
> > > > > > > around the net about being having various issues with
> > > > > > > various firmware sources and not others but despite
> > > > > > > trying firmware linked directly from Marvell I seem to
> > > > > > > always get one of two issues:
> > > > > > >
> > > > > > > 1.) I am unable to connect and keep getting asked for
> > > > > > > passphrases, or:
> > > > > > > 2.) The system completely freezes up (with the v8
> > > > > > > firmwares I tried)
> > > > > > >
> > > > > > > I’m not really sure what else to try at this point.
> > > > > > > Christopher Williamson
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 22 July 2016 at 17:24:52, Christopher Williamson (home
> > > > > > > @chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Dan,
> > > > > > > >
> > > > > > > > I will check out the WPA2 vs WPA vs open wireless thing
> > > > > > > > in a few mins.
> > > > > > > >
> > > > > > > > For now though - the iwlist scan results for both a USB
> > > > > > > > device and the
> > > > > > > > libertas device:
> > > > > > > >
> > > > > > > > USB: http://termbin.com/hdwl
> > > > > > > > Libertas: http://termbin.com/jxh7
> > > > > > > >
> > > > > > > > Will follow up shortly with WPA and Open network
> > > > > > > > configs.
> > > > > > > >
> > > > > > > > Christopher Williamson
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 22 July 2016 at 17:16:29, Dan Williams (dcbw@redhat.
> > > > > > > > com(mailto:dcbw@redhat.com)) wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Dan,
> > > > > > > > >
> > > > > > > > > I will check out the WPA2 vs WPA vs open wireless
> > > > > > > > > thing in a few mins.
> > > > > > > > >
> > > > > > > > > For now though - the iwlist scan results for both a
> > > > > > > > > USB device and the
> > > > > > > > > libertas device:
> > > > > > > > >
> > > > > > > > > USB: http://termbin.com/hdwl
> > > > > > > > > Libertas: http://termbin.com/jxh7
> > > > > > > > >
> > > > > > > > > Will follow up shortly with WPA and Open network
> > > > > > > > > configs.
> > > > > > > > >
> > > > > > > > > *Christopher Williamson*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 8/8] mwifiex: fix radar detection issue
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Ganapathi Bhat, Amitkumar Karwar
In-Reply-To: <1469461871-3135-1-git-send-email-akarwar@marvell.com>
From: Ganapathi Bhat <gbhat@marvell.com>
It's been observed that firmware sends RADAR detected event without
specifying bss_num/bss_type. Also, the event body is empty.
Currently the event is being ignored by driver.
This patch checks on which interface 11H is active, accordingly fills
bss_num/bss_type and handles the event. Condition
"if (le32_to_cpu(rdr_event->passed))" which always fails is also removed.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/11h.c | 27 +++++++++++----------------
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 18 ++++++++++++++++--
2 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11h.c b/drivers/net/wireless/marvell/mwifiex/11h.c
index 81c60d0..43dccd5 100644
--- a/drivers/net/wireless/marvell/mwifiex/11h.c
+++ b/drivers/net/wireless/marvell/mwifiex/11h.c
@@ -260,22 +260,17 @@ int mwifiex_11h_handle_radar_detected(struct mwifiex_private *priv,
rdr_event = (void *)(skb->data + sizeof(u32));
- if (le32_to_cpu(rdr_event->passed)) {
- mwifiex_dbg(priv->adapter, MSG,
- "radar detected; indicating kernel\n");
- if (mwifiex_stop_radar_detection(priv, &priv->dfs_chandef))
- mwifiex_dbg(priv->adapter, ERROR,
- "Failed to stop CAC in FW\n");
- cfg80211_radar_event(priv->adapter->wiphy, &priv->dfs_chandef,
- GFP_KERNEL);
- mwifiex_dbg(priv->adapter, MSG, "regdomain: %d\n",
- rdr_event->reg_domain);
- mwifiex_dbg(priv->adapter, MSG, "radar detection type: %d\n",
- rdr_event->det_type);
- } else {
- mwifiex_dbg(priv->adapter, MSG,
- "false radar detection event!\n");
- }
+ mwifiex_dbg(priv->adapter, MSG,
+ "radar detected; indicating kernel\n");
+ if (mwifiex_stop_radar_detection(priv, &priv->dfs_chandef))
+ mwifiex_dbg(priv->adapter, ERROR,
+ "Failed to stop CAC in FW\n");
+ cfg80211_radar_event(priv->adapter->wiphy, &priv->dfs_chandef,
+ GFP_KERNEL);
+ mwifiex_dbg(priv->adapter, MSG, "regdomain: %d\n",
+ rdr_event->reg_domain);
+ mwifiex_dbg(priv->adapter, MSG, "radar detection type: %d\n",
+ rdr_event->det_type);
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index c29f26d..d433aa0 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -480,13 +480,27 @@ int mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter)
*/
int mwifiex_process_event(struct mwifiex_adapter *adapter)
{
- int ret;
+ int ret, i;
struct mwifiex_private *priv =
mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
struct sk_buff *skb = adapter->event_skb;
- u32 eventcause = adapter->event_cause;
+ u32 eventcause;
struct mwifiex_rxinfo *rx_info;
+ if ((adapter->event_cause & EVENT_ID_MASK) == EVENT_RADAR_DETECTED) {
+ for (i = 0; i < adapter->priv_num; i++) {
+ priv = adapter->priv[i];
+ if (priv && mwifiex_is_11h_active(priv)) {
+ adapter->event_cause |=
+ ((priv->bss_num & 0xff) << 16) |
+ ((priv->bss_type & 0xff) << 24);
+ break;
+ }
+ }
+ }
+
+ eventcause = adapter->event_cause;
+
/* Save the last event to debug log */
adapter->dbg.last_event_index =
(adapter->dbg.last_event_index + 1) % DBG_CMD_NUM;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 7/8] mwifiex: add HT aggregation support for adhoc mode
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1469461871-3135-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
This patch adds HT support for adhoc station. Firmware will upload
ibss sta connect event with beacon data, whenever new station joins
the adhoc network. Driver will check the HT IE and decide whether to
support HT aggreagation or not.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/11n.h | 7 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 9 ++
drivers/net/wireless/marvell/mwifiex/sta_event.c | 132 ++++++++++++++++++++++-
3 files changed, 144 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n.h b/drivers/net/wireless/marvell/mwifiex/11n.h
index afdd58a..ea0fa68 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n.h
+++ b/drivers/net/wireless/marvell/mwifiex/11n.h
@@ -171,9 +171,10 @@ mwifiex_find_stream_to_delete(struct mwifiex_private *priv, int ptr_tid,
static inline int mwifiex_is_sta_11n_enabled(struct mwifiex_private *priv,
struct mwifiex_sta_node *node)
{
-
- if (!node || (priv->bss_role != MWIFIEX_BSS_ROLE_UAP) ||
- !priv->ap_11n_enabled)
+ if (!node || ((priv->bss_role == MWIFIEX_BSS_ROLE_UAP) &&
+ !priv->ap_11n_enabled) ||
+ ((priv->bss_mode == NL80211_IFTYPE_ADHOC) &&
+ !priv->adapter->adhoc_11n_enabled))
return 0;
return node->is_11n_enabled;
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 3b40e0d..a88030a 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -210,6 +210,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define MWIFIEX_TX_DATA_BUF_SIZE_4K 4096
#define MWIFIEX_TX_DATA_BUF_SIZE_8K 8192
+#define MWIFIEX_TX_DATA_BUF_SIZE_12K 12288
#define ISSUPP_11NENABLED(FwCapInfo) (FwCapInfo & BIT(11))
#define ISSUPP_TDLS_ENABLED(FwCapInfo) (FwCapInfo & BIT(14))
@@ -506,6 +507,8 @@ enum P2P_MODES {
#define EVENT_RSSI_HIGH 0x0000001c
#define EVENT_SNR_HIGH 0x0000001d
#define EVENT_IBSS_COALESCED 0x0000001e
+#define EVENT_IBSS_STA_CONNECT 0x00000020
+#define EVENT_IBSS_STA_DISCONNECT 0x00000021
#define EVENT_DATA_RSSI_LOW 0x00000024
#define EVENT_DATA_SNR_LOW 0x00000025
#define EVENT_DATA_RSSI_HIGH 0x00000026
@@ -1686,6 +1689,12 @@ struct mwifiex_ie_types_wmm_param_set {
u8 wmm_ie[1];
};
+struct mwifiex_ie_types_mgmt_frame {
+ struct mwifiex_ie_types_header header;
+ __le16 frame_control;
+ u8 frame_contents[0];
+};
+
struct mwifiex_ie_types_wmm_queue_status {
struct mwifiex_ie_types_header header;
u8 queue_index;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index b973ee8..9df0c4d 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -25,6 +25,99 @@
#include "wmm.h"
#include "11n.h"
+#define MWIFIEX_IBSS_CONNECT_EVT_FIX_SIZE 12
+
+static int mwifiex_check_ibss_peer_capabilties(struct mwifiex_private *priv,
+ struct mwifiex_sta_node *sta_ptr,
+ struct sk_buff *event)
+{
+ int evt_len, ele_len;
+ u8 *curr;
+ struct ieee_types_header *ele_hdr;
+ struct mwifiex_ie_types_mgmt_frame *tlv_mgmt_frame;
+ const struct ieee80211_ht_cap *ht_cap;
+ const struct ieee80211_vht_cap *vht_cap;
+
+ skb_pull(event, MWIFIEX_IBSS_CONNECT_EVT_FIX_SIZE);
+ evt_len = event->len;
+ curr = event->data;
+
+ mwifiex_dbg_dump(priv->adapter, EVT_D, "ibss peer capabilties:",
+ event->data, event->len);
+
+ skb_push(event, MWIFIEX_IBSS_CONNECT_EVT_FIX_SIZE);
+
+ tlv_mgmt_frame = (void *)curr;
+ if (evt_len >= sizeof(*tlv_mgmt_frame) &&
+ le16_to_cpu(tlv_mgmt_frame->header.type) ==
+ TLV_TYPE_UAP_MGMT_FRAME) {
+ /* Locate curr pointer to the start of beacon tlv,
+ * timestamp 8 bytes, beacon intervel 2 bytes,
+ * capability info 2 bytes, totally 12 byte beacon header
+ */
+ evt_len = le16_to_cpu(tlv_mgmt_frame->header.len);
+ curr += (sizeof(*tlv_mgmt_frame) + 12);
+ } else {
+ mwifiex_dbg(priv->adapter, MSG,
+ "management frame tlv not found!\n");
+ return 0;
+ }
+
+ while (evt_len >= sizeof(*ele_hdr)) {
+ ele_hdr = (struct ieee_types_header *)curr;
+ ele_len = ele_hdr->len;
+
+ if (evt_len < ele_len + sizeof(*ele_hdr))
+ break;
+
+ switch (ele_hdr->element_id) {
+ case WLAN_EID_HT_CAPABILITY:
+ sta_ptr->is_11n_enabled = true;
+ ht_cap = (void *)(ele_hdr + 2);
+ sta_ptr->max_amsdu = le16_to_cpu(ht_cap->cap_info) &
+ IEEE80211_HT_CAP_MAX_AMSDU ?
+ MWIFIEX_TX_DATA_BUF_SIZE_8K :
+ MWIFIEX_TX_DATA_BUF_SIZE_4K;
+ mwifiex_dbg(priv->adapter, INFO,
+ "11n enabled!, max_amsdu : %d\n",
+ sta_ptr->max_amsdu);
+ break;
+
+ case WLAN_EID_VHT_CAPABILITY:
+ sta_ptr->is_11ac_enabled = true;
+ vht_cap = (void *)(ele_hdr + 2);
+ /* check VHT MAXMPDU capability */
+ switch (le32_to_cpu(vht_cap->vht_cap_info) & 0x3) {
+ case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
+ sta_ptr->max_amsdu =
+ MWIFIEX_TX_DATA_BUF_SIZE_12K;
+ break;
+ case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
+ sta_ptr->max_amsdu =
+ MWIFIEX_TX_DATA_BUF_SIZE_8K;
+ break;
+ case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
+ sta_ptr->max_amsdu =
+ MWIFIEX_TX_DATA_BUF_SIZE_4K;
+ default:
+ break;
+ }
+
+ mwifiex_dbg(priv->adapter, INFO,
+ "11ac enabled!, max_amsdu : %d\n",
+ sta_ptr->max_amsdu);
+ break;
+ default:
+ break;
+ }
+
+ curr += (ele_len + sizeof(*ele_hdr));
+ evt_len -= (ele_len + sizeof(*ele_hdr));
+ }
+
+ return 0;
+}
+
/*
* This function resets the connection state.
*
@@ -519,6 +612,8 @@ void mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
* - EVENT_LINK_QUALITY
* - EVENT_PRE_BEACON_LOST
* - EVENT_IBSS_COALESCED
+ * - EVENT_IBSS_STA_CONNECT
+ * - EVENT_IBSS_STA_DISCONNECT
* - EVENT_WEP_ICV_ERR
* - EVENT_BW_CHANGE
* - EVENT_HOSTWAKE_STAIE
@@ -547,9 +642,11 @@ void mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
int mwifiex_process_sta_event(struct mwifiex_private *priv)
{
struct mwifiex_adapter *adapter = priv->adapter;
- int ret = 0;
+ int ret = 0, i;
u32 eventcause = adapter->event_cause;
u16 ctrl, reason_code;
+ u8 ibss_sta_addr[ETH_ALEN];
+ struct mwifiex_sta_node *sta_ptr;
switch (eventcause) {
case EVENT_DUMMY_HOST_WAKEUP_SIGNAL:
@@ -775,6 +872,39 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
HostCmd_CMD_802_11_IBSS_COALESCING_STATUS,
HostCmd_ACT_GEN_GET, 0, NULL, false);
break;
+ case EVENT_IBSS_STA_CONNECT:
+ ether_addr_copy(ibss_sta_addr, adapter->event_body + 2);
+ mwifiex_dbg(adapter, EVENT, "event: IBSS_STA_CONNECT %pM\n",
+ ibss_sta_addr);
+ sta_ptr = mwifiex_add_sta_entry(priv, ibss_sta_addr);
+ if (sta_ptr && adapter->adhoc_11n_enabled) {
+ mwifiex_check_ibss_peer_capabilties(priv, sta_ptr,
+ adapter->event_skb);
+ if (sta_ptr->is_11n_enabled)
+ for (i = 0; i < MAX_NUM_TID; i++)
+ sta_ptr->ampdu_sta[i] =
+ priv->aggr_prio_tbl[i].ampdu_user;
+ else
+ for (i = 0; i < MAX_NUM_TID; i++)
+ sta_ptr->ampdu_sta[i] =
+ BA_STREAM_NOT_ALLOWED;
+ memset(sta_ptr->rx_seq, 0xff, sizeof(sta_ptr->rx_seq));
+ }
+
+ break;
+ case EVENT_IBSS_STA_DISCONNECT:
+ ether_addr_copy(ibss_sta_addr, adapter->event_body + 2);
+ mwifiex_dbg(adapter, EVENT, "event: IBSS_STA_DISCONNECT %pM\n",
+ ibss_sta_addr);
+ sta_ptr = mwifiex_get_sta_entry(priv, ibss_sta_addr);
+ if (sta_ptr && sta_ptr->is_11n_enabled) {
+ mwifiex_11n_del_rx_reorder_tbl_by_ta(priv,
+ ibss_sta_addr);
+ mwifiex_del_tx_ba_stream_tbl_by_ra(priv, ibss_sta_addr);
+ }
+ mwifiex_wmm_del_peer_ra_list(priv, ibss_sta_addr);
+ mwifiex_del_sta_entry(priv, ibss_sta_addr);
+ break;
case EVENT_ADDBA:
mwifiex_dbg(adapter, EVENT, "event: ADDBA Request\n");
mwifiex_send_cmd(priv, HostCmd_CMD_11N_ADDBA_RSP,
--
1.9.1
^ permalink raw reply related
* [PATCH v2 6/8] mwifiex: remove misleading disconnect message
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1469461871-3135-1-git-send-email-akarwar@marvell.com>
Disconnect message in mwifiex_reset_connect_state() would displays
necessary information. We unnecessarily have exactly same message in
cfg80211_disconnect(). As priv->cfg_bssid is cleared at this point of
time, it prints incorrect(all zero) MAC.
This message is removed here.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 871ad8a..235fb39 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2012,10 +2012,6 @@ mwifiex_cfg80211_disconnect(struct wiphy *wiphy, struct net_device *dev,
if (mwifiex_deauthenticate(priv, NULL))
return -EFAULT;
- mwifiex_dbg(priv->adapter, MSG,
- "info: successfully disconnected from %pM:\t"
- "reason code %d\n", priv->cfg_bssid, reason_code);
-
eth_zero_addr(priv->cfg_bssid);
priv->hs2_enabled = false;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/8] mwifiex: support random MAC address for scanning
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Ganapathi Bhat, Amitkumar Karwar
In-Reply-To: <1469461871-3135-1-git-send-email-akarwar@marvell.com>
From: Ganapathi Bhat <gbhat@marvell.com>
This patch advertises RANDOM_MAC_ADDR feature to cfg80211. It allow the
application to issue scan with a MAC address and mask. Random MACs are
generated and used in probe requests sent for scanning until it is changed
by the application or device is restarted.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 15 ++++++++++++++-
drivers/net/wireless/marvell/mwifiex/fw.h | 7 +++++++
drivers/net/wireless/marvell/mwifiex/main.h | 1 +
drivers/net/wireless/marvell/mwifiex/scan.c | 16 ++++++++++++++++
4 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index a8ff969..871ad8a 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2485,6 +2485,16 @@ mwifiex_cfg80211_scan(struct wiphy *wiphy,
priv->scan_request = request;
+ if (request->flags & NL80211_SCAN_FLAG_RANDOM_ADDR) {
+ ether_addr_copy(priv->random_mac, request->mac_addr);
+ for (i = 0; i < ETH_ALEN; i++) {
+ priv->random_mac[i] &= request->mac_addr_mask[i];
+ priv->random_mac[i] |= get_random_int() &
+ ~(request->mac_addr_mask[i]);
+ }
+ }
+
+ ether_addr_copy(user_scan_cfg->random_mac, priv->random_mac);
user_scan_cfg->num_ssids = request->n_ssids;
user_scan_cfg->ssid_list = request->ssids;
@@ -4173,7 +4183,10 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
wiphy->features |= NL80211_FEATURE_HT_IBSS |
NL80211_FEATURE_INACTIVITY_TIMER |
NL80211_FEATURE_LOW_PRIORITY_SCAN |
- NL80211_FEATURE_NEED_OBSS_SCAN;
+ NL80211_FEATURE_NEED_OBSS_SCAN |
+ NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR |
+ NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR |
+ NL80211_FEATURE_ND_RANDOM_MAC_ADDR;
if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info))
wiphy->features |= NL80211_FEATURE_TDLS_CHANNEL_SWITCH;
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index c46267b..3797ef4 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -188,6 +188,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define TLV_BTCOEX_WL_AGGR_WINSIZE (PROPRIETARY_TLV_BASE_ID + 202)
#define TLV_BTCOEX_WL_SCANTIME (PROPRIETARY_TLV_BASE_ID + 203)
#define TLV_TYPE_BSS_MODE (PROPRIETARY_TLV_BASE_ID + 206)
+#define TLV_TYPE_RANDOM_MAC (PROPRIETARY_TLV_BASE_ID + 236)
#define MWIFIEX_TX_DATA_BUF_SIZE_2K 2048
@@ -780,6 +781,11 @@ struct mwifiex_ie_types_scan_chan_gap {
__le16 chan_gap;
} __packed;
+struct mwifiex_ie_types_random_mac {
+ struct mwifiex_ie_types_header header;
+ u8 mac[ETH_ALEN];
+} __packed;
+
struct mwifiex_ietypes_chanstats {
struct mwifiex_ie_types_header header;
struct mwifiex_fw_chan_stats chanstats[0];
@@ -1464,6 +1470,7 @@ struct mwifiex_user_scan_cfg {
/* Variable number (fixed maximum) of channels to scan up */
struct mwifiex_user_scan_chan chan_list[MWIFIEX_USER_SCAN_CHAN_MAX];
u16 scan_chan_gap;
+ u8 random_mac[ETH_ALEN];
} __packed;
#define MWIFIEX_BG_SCAN_CHAN_MAX 38
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 9f6bb40..5902600 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -675,6 +675,7 @@ struct mwifiex_private {
struct mwifiex_user_scan_chan hidden_chan[MWIFIEX_USER_SCAN_CHAN_MAX];
u8 assoc_resp_ht_param;
bool ht_param_present;
+ u8 random_mac[ETH_ALEN];
};
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index 21ec847..8daf0d86 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -820,6 +820,7 @@ mwifiex_config_scan(struct mwifiex_private *priv,
struct mwifiex_adapter *adapter = priv->adapter;
struct mwifiex_ie_types_num_probes *num_probes_tlv;
struct mwifiex_ie_types_scan_chan_gap *chan_gap_tlv;
+ struct mwifiex_ie_types_random_mac *random_mac_tlv;
struct mwifiex_ie_types_wildcard_ssid_params *wildcard_ssid_tlv;
struct mwifiex_ie_types_bssid_list *bssid_tlv;
u8 *tlv_pos;
@@ -835,6 +836,7 @@ mwifiex_config_scan(struct mwifiex_private *priv,
u8 ssid_filter;
struct mwifiex_ie_types_htcap *ht_cap;
struct mwifiex_ie_types_bss_mode *bss_mode;
+ const u8 zero_mac[6] = {0, 0, 0, 0, 0, 0};
/* The tlv_buf_len is calculated for each scan command. The TLVs added
in this routine will be preserved since the routine that sends the
@@ -967,6 +969,18 @@ mwifiex_config_scan(struct mwifiex_private *priv,
tlv_pos +=
sizeof(struct mwifiex_ie_types_scan_chan_gap);
}
+
+ if (!ether_addr_equal(user_scan_in->random_mac, zero_mac)) {
+ random_mac_tlv = (void *)tlv_pos;
+ random_mac_tlv->header.type =
+ cpu_to_le16(TLV_TYPE_RANDOM_MAC);
+ random_mac_tlv->header.len =
+ cpu_to_le16(sizeof(random_mac_tlv->mac));
+ ether_addr_copy(random_mac_tlv->mac,
+ user_scan_in->random_mac);
+ tlv_pos +=
+ sizeof(struct mwifiex_ie_types_random_mac);
+ }
} else {
scan_cfg_out->bss_mode = (u8) adapter->scan_mode;
num_probes = adapter->scan_probes;
@@ -1922,6 +1936,7 @@ mwifiex_active_scan_req_for_passive_chan(struct mwifiex_private *priv)
}
adapter->active_scan_triggered = true;
+ ether_addr_copy(user_scan_cfg->random_mac, priv->random_mac);
user_scan_cfg->num_ssids = priv->scan_request->n_ssids;
user_scan_cfg->ssid_list = priv->scan_request->ssids;
@@ -2761,6 +2776,7 @@ static int mwifiex_scan_specific_ssid(struct mwifiex_private *priv,
if (!scan_cfg)
return -ENOMEM;
+ ether_addr_copy(scan_cfg->random_mac, priv->random_mac);
scan_cfg->ssid_list = req_ssid;
scan_cfg->num_ssids = 1;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 5/8] mwifiex: process rxba_sync event
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1469461871-3135-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
Firmware may filter and drop packets under certain condition, for
example, ARP SA=DA packet. this event will be used to synchronize
the Rx Block Acknowledgment (BA) window bitmap and to fill any holes
in driver side.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 78 +++++++++++++++++++++-
.../net/wireless/marvell/mwifiex/11n_rxreorder.h | 3 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 12 ++++
drivers/net/wireless/marvell/mwifiex/sta_event.c | 6 ++
drivers/net/wireless/marvell/mwifiex/uap_event.c | 7 +-
5 files changed, 103 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index a74cc43..9448012 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -78,8 +78,15 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
*/
static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload)
{
- int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
+ int ret;
+
+ if (!payload) {
+ mwifiex_dbg(priv->adapter, INFO, "info: fw drop data\n");
+ return 0;
+ }
+
+ ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
if (!ret)
return 0;
@@ -921,3 +928,72 @@ void mwifiex_coex_ampdu_rxwinsize(struct mwifiex_adapter *adapter)
else
mwifiex_update_ampdu_rxwinsize(adapter, false);
}
+
+/* This function handles rxba_sync event
+ */
+void mwifiex_11n_rxba_sync_event(struct mwifiex_private *priv,
+ u8 *event_buf, u16 len)
+{
+ struct mwifiex_ie_types_rxba_sync *tlv_rxba = (void *)event_buf;
+ u16 tlv_type, tlv_len;
+ struct mwifiex_rx_reorder_tbl *rx_reor_tbl_ptr;
+ u8 i, j;
+ u16 seq_num, tlv_seq_num, tlv_bitmap_len;
+ int tlv_buf_left = len;
+ int ret;
+ u8 *tmp;
+
+ mwifiex_dbg_dump(priv->adapter, EVT_D, "RXBA_SYNC event:",
+ event_buf, len);
+ while (tlv_buf_left >= sizeof(*tlv_rxba)) {
+ tlv_type = le16_to_cpu(tlv_rxba->header.type);
+ tlv_len = le16_to_cpu(tlv_rxba->header.len);
+ if (tlv_type != TLV_TYPE_RXBA_SYNC) {
+ mwifiex_dbg(priv->adapter, ERROR,
+ "Wrong TLV id=0x%x\n", tlv_type);
+ return;
+ }
+
+ tlv_seq_num = le16_to_cpu(tlv_rxba->seq_num);
+ tlv_bitmap_len = le16_to_cpu(tlv_rxba->bitmap_len);
+ mwifiex_dbg(priv->adapter, INFO,
+ "%pM tid=%d seq_num=%d bitmap_len=%d\n",
+ tlv_rxba->mac, tlv_rxba->tid, tlv_seq_num,
+ tlv_bitmap_len);
+
+ rx_reor_tbl_ptr =
+ mwifiex_11n_get_rx_reorder_tbl(priv, tlv_rxba->tid,
+ tlv_rxba->mac);
+ if (!rx_reor_tbl_ptr) {
+ mwifiex_dbg(priv->adapter, ERROR,
+ "Can not find rx_reorder_tbl!");
+ return;
+ }
+
+ for (i = 0; i < tlv_bitmap_len; i++) {
+ for (j = 0 ; j < 8; j++) {
+ if (tlv_rxba->bitmap[i] & (1 << j)) {
+ seq_num = (MAX_TID_VALUE - 1) &
+ (tlv_seq_num + i * 8 + j);
+
+ mwifiex_dbg(priv->adapter, ERROR,
+ "drop packet,seq=%d\n",
+ seq_num);
+
+ ret = mwifiex_11n_rx_reorder_pkt
+ (priv, seq_num, tlv_rxba->tid,
+ tlv_rxba->mac, 0, NULL);
+
+ if (ret)
+ mwifiex_dbg(priv->adapter,
+ ERROR,
+ "Fail to drop packet");
+ }
+ }
+ }
+
+ tlv_buf_left -= (sizeof(*tlv_rxba) + tlv_len);
+ tmp = (u8 *)tlv_rxba + tlv_len + sizeof(*tlv_rxba);
+ tlv_rxba = (struct mwifiex_ie_types_rxba_sync *)tmp;
+ }
+}
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.h b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.h
index 63ecea8..22d991f 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.h
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.h
@@ -81,5 +81,6 @@ struct mwifiex_rx_reorder_tbl *
mwifiex_11n_get_rx_reorder_tbl(struct mwifiex_private *priv, int tid, u8 *ta);
void mwifiex_11n_del_rx_reorder_tbl_by_ta(struct mwifiex_private *priv, u8 *ta);
void mwifiex_update_rxreor_flags(struct mwifiex_adapter *adapter, u8 flags);
-
+void mwifiex_11n_rxba_sync_event(struct mwifiex_private *priv,
+ u8 *event_buf, u16 len);
#endif /* _MWIFIEX_11N_RXREORDER_H_ */
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 3797ef4..3b40e0d 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -176,6 +176,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define TLV_TYPE_PWK_CIPHER (PROPRIETARY_TLV_BASE_ID + 145)
#define TLV_TYPE_GWK_CIPHER (PROPRIETARY_TLV_BASE_ID + 146)
#define TLV_TYPE_TX_PAUSE (PROPRIETARY_TLV_BASE_ID + 148)
+#define TLV_TYPE_RXBA_SYNC (PROPRIETARY_TLV_BASE_ID + 153)
#define TLV_TYPE_COALESCE_RULE (PROPRIETARY_TLV_BASE_ID + 154)
#define TLV_TYPE_KEY_PARAM_V2 (PROPRIETARY_TLV_BASE_ID + 156)
#define TLV_TYPE_REPEAT_COUNT (PROPRIETARY_TLV_BASE_ID + 176)
@@ -532,6 +533,7 @@ enum P2P_MODES {
#define EVENT_CHANNEL_REPORT_RDY 0x00000054
#define EVENT_TX_DATA_PAUSE 0x00000055
#define EVENT_EXT_SCAN_REPORT 0x00000058
+#define EVENT_RXBA_SYNC 0x00000059
#define EVENT_BG_SCAN_STOPPED 0x00000065
#define EVENT_REMAIN_ON_CHAN_EXPIRED 0x0000005f
#define EVENT_MULTI_CHAN_INFO 0x0000006a
@@ -735,6 +737,16 @@ struct mwifiex_ie_types_chan_list_param_set {
struct mwifiex_chan_scan_param_set chan_scan_param[1];
} __packed;
+struct mwifiex_ie_types_rxba_sync {
+ struct mwifiex_ie_types_header header;
+ u8 mac[ETH_ALEN];
+ u8 tid;
+ u8 reserved;
+ __le16 seq_num;
+ __le16 bitmap_len;
+ u8 bitmap[1];
+} __packed;
+
struct chan_band_param_set {
u8 radio_type;
u8 chan_number;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index 7e394d4..b973ee8 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -873,6 +873,12 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
mwifiex_bt_coex_wlan_param_update_event(priv,
adapter->event_skb);
break;
+ case EVENT_RXBA_SYNC:
+ dev_dbg(adapter->dev, "EVENT: RXBA_SYNC\n");
+ mwifiex_11n_rxba_sync_event(priv, adapter->event_body,
+ adapter->event_skb->len -
+ sizeof(eventcause));
+ break;
default:
mwifiex_dbg(adapter, ERROR, "event: unknown event id: %#x\n",
eventcause);
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_event.c b/drivers/net/wireless/marvell/mwifiex/uap_event.c
index 86ff542..d24eca3 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_event.c
@@ -306,7 +306,12 @@ int mwifiex_process_uap_event(struct mwifiex_private *priv)
mwifiex_dbg(adapter, EVENT, "event: multi-chan info\n");
mwifiex_process_multi_chan_event(priv, adapter->event_skb);
break;
-
+ case EVENT_RXBA_SYNC:
+ dev_dbg(adapter->dev, "EVENT: RXBA_SYNC\n");
+ mwifiex_11n_rxba_sync_event(priv, adapter->event_body,
+ adapter->event_skb->len -
+ sizeof(eventcause));
+ break;
default:
mwifiex_dbg(adapter, EVENT,
"event: unknown event id: %#x\n", eventcause);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/8] mwifiex: fix failed to reconnect after interface disabled/enabled
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1469461871-3135-1-git-send-email-akarwar@marvell.com>
Recent patch "mwifiex: fix NULL pointer" skips extended scan event
handling when suspend is in progress. It created a problem for scan
after interface disabled/enabled case.
This patch solves the problem by checking netif_running() status.
Fixes:16d25da94f3d654 ("mwifiex: fix NULL pointer dereference during suspend")
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/sta_event.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index a422f33..7e394d4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -708,7 +708,11 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
case EVENT_EXT_SCAN_REPORT:
mwifiex_dbg(adapter, EVENT, "event: EXT_SCAN Report\n");
- if (adapter->ext_scan && !priv->scan_aborting)
+ /* We intend to skip this event during suspend, but handle
+ * it in interface disabled case
+ */
+ if (adapter->ext_scan && (!priv->scan_aborting ||
+ !netif_running(priv->netdev)))
ret = mwifiex_handle_event_ext_scan_report(priv,
adapter->event_skb->data);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/8] mwifiex: add region code information in debugfs
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Karthik D A, Amitkumar Karwar
In-Reply-To: <1469461871-3135-1-git-send-email-akarwar@marvell.com>
From: Karthik D A <karthida@marvell.com>
region code is an EEPROM setting received from firmware. Let's display
this in debugfs along with other information.
Signed-off-by: Karthik D A <karthida@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/debugfs.c b/drivers/net/wireless/marvell/mwifiex/debugfs.c
index bccf17a..b9284b5 100644
--- a/drivers/net/wireless/marvell/mwifiex/debugfs.c
+++ b/drivers/net/wireless/marvell/mwifiex/debugfs.c
@@ -118,6 +118,8 @@ mwifiex_info_read(struct file *file, char __user *ubuf,
p += sprintf(p, "bssid=\"%pM\"\n", info.bssid);
p += sprintf(p, "channel=\"%d\"\n", (int) info.bss_chan);
p += sprintf(p, "country_code = \"%s\"\n", info.country_code);
+ p += sprintf(p, "region_code=\"0x%x\"\n",
+ priv->adapter->region_code);
netdev_for_each_mc_addr(ha, netdev)
p += sprintf(p, "multicast_address[%d]=\"%pM\"\n",
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/8] mwifiex: Fixed endianness problem for big endian platform
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Karthik D A, Amitkumar Karwar
In-Reply-To: <1469461871-3135-1-git-send-email-akarwar@marvell.com>
From: Karthik D A <karthida@marvell.com>
The driver sends and recives information to and from the firmware.
Correct endianness should be ensured as firmware follows little
endian format and host can be little/big endian.
Signed-off-by: Karthik D A <karthida@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/fw.h | 30 +++++++++++-----------
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 27 ++++++++++---------
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 2 +-
3 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 5596b6b..c46267b 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -1646,7 +1646,7 @@ struct mwifiex_ie_types_sta_info {
};
struct host_cmd_ds_sta_list {
- u16 sta_count;
+ __le16 sta_count;
u8 tlv[0];
} __packed;
@@ -2034,26 +2034,26 @@ struct host_cmd_ds_set_bss_mode {
struct host_cmd_ds_pcie_details {
/* TX buffer descriptor ring address */
- u32 txbd_addr_lo;
- u32 txbd_addr_hi;
+ __le32 txbd_addr_lo;
+ __le32 txbd_addr_hi;
/* TX buffer descriptor ring count */
- u32 txbd_count;
+ __le32 txbd_count;
/* RX buffer descriptor ring address */
- u32 rxbd_addr_lo;
- u32 rxbd_addr_hi;
+ __le32 rxbd_addr_lo;
+ __le32 rxbd_addr_hi;
/* RX buffer descriptor ring count */
- u32 rxbd_count;
+ __le32 rxbd_count;
/* Event buffer descriptor ring address */
- u32 evtbd_addr_lo;
- u32 evtbd_addr_hi;
+ __le32 evtbd_addr_lo;
+ __le32 evtbd_addr_hi;
/* Event buffer descriptor ring count */
- u32 evtbd_count;
+ __le32 evtbd_count;
/* Sleep cookie buffer physical address */
- u32 sleep_cookie_addr_lo;
- u32 sleep_cookie_addr_hi;
+ __le32 sleep_cookie_addr_lo;
+ __le32 sleep_cookie_addr_hi;
} __packed;
struct mwifiex_ie_types_rssi_threshold {
@@ -2093,8 +2093,8 @@ struct mwifiex_ie_types_mc_group_info {
u8 chan_buf_weight;
u8 band_config;
u8 chan_num;
- u32 chan_time;
- u32 reserved;
+ __le32 chan_time;
+ __le32 reserved;
union {
u8 sdio_func_num;
u8 usb_ep_num;
@@ -2185,7 +2185,7 @@ struct host_cmd_ds_robust_coex {
} __packed;
struct host_cmd_ds_wakeup_reason {
- u16 wakeup_reason;
+ __le16 wakeup_reason;
} __packed;
struct host_cmd_ds_gtk_rekey_params {
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 7897037..108c11c 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1244,20 +1244,23 @@ mwifiex_cmd_pcie_host_spec(struct mwifiex_private *priv,
return 0;
/* Send the ring base addresses and count to firmware */
- host_spec->txbd_addr_lo = (u32)(card->txbd_ring_pbase);
- host_spec->txbd_addr_hi = (u32)(((u64)card->txbd_ring_pbase)>>32);
- host_spec->txbd_count = MWIFIEX_MAX_TXRX_BD;
- host_spec->rxbd_addr_lo = (u32)(card->rxbd_ring_pbase);
- host_spec->rxbd_addr_hi = (u32)(((u64)card->rxbd_ring_pbase)>>32);
- host_spec->rxbd_count = MWIFIEX_MAX_TXRX_BD;
- host_spec->evtbd_addr_lo = (u32)(card->evtbd_ring_pbase);
- host_spec->evtbd_addr_hi = (u32)(((u64)card->evtbd_ring_pbase)>>32);
- host_spec->evtbd_count = MWIFIEX_MAX_EVT_BD;
+ host_spec->txbd_addr_lo = cpu_to_le32((u32)(card->txbd_ring_pbase));
+ host_spec->txbd_addr_hi =
+ cpu_to_le32((u32)(((u64)card->txbd_ring_pbase) >> 32));
+ host_spec->txbd_count = cpu_to_le32(MWIFIEX_MAX_TXRX_BD);
+ host_spec->rxbd_addr_lo = cpu_to_le32((u32)(card->rxbd_ring_pbase));
+ host_spec->rxbd_addr_hi =
+ cpu_to_le32((u32)(((u64)card->rxbd_ring_pbase) >> 32));
+ host_spec->rxbd_count = cpu_to_le32(MWIFIEX_MAX_TXRX_BD);
+ host_spec->evtbd_addr_lo = cpu_to_le32((u32)(card->evtbd_ring_pbase));
+ host_spec->evtbd_addr_hi =
+ cpu_to_le32((u32)(((u64)card->evtbd_ring_pbase) >> 32));
+ host_spec->evtbd_count = cpu_to_le32(MWIFIEX_MAX_EVT_BD);
if (card->sleep_cookie_vbase) {
host_spec->sleep_cookie_addr_lo =
- (u32)(card->sleep_cookie_pbase);
- host_spec->sleep_cookie_addr_hi =
- (u32)(((u64)(card->sleep_cookie_pbase)) >> 32);
+ cpu_to_le32((u32)(card->sleep_cookie_pbase));
+ host_spec->sleep_cookie_addr_hi = cpu_to_le32((u32)(((u64)
+ (card->sleep_cookie_pbase)) >> 32));
mwifiex_dbg(priv->adapter, INFO,
"sleep_cook_lo phy addr: 0x%x\n",
host_spec->sleep_cookie_addr_lo);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index ccf54932..90e191b 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -962,7 +962,7 @@ static int mwifiex_ret_uap_sta_list(struct mwifiex_private *priv,
int i;
struct mwifiex_sta_node *sta_node;
- for (i = 0; i < sta_list->sta_count; i++) {
+ for (i = 0; i < (le16_to_cpu(sta_list->sta_count)); i++) {
sta_node = mwifiex_get_sta_entry(priv, sta_info->mac);
if (unlikely(!sta_node))
continue;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/8] mwifiex patches
From: Amitkumar Karwar @ 2016-07-25 15:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
This patch series includes couple of fixes and enhancements.
Changes in v2:
1) Dropped "[5/9] mwifiex: cfg80211 set_default_mgmt_key handler"
patch in v1 series. We are working on review comment from Jouni
Malinen.
2) Removed MWIFIEX_RX_PKT_DROPPED_IN_FW macro in "[6/9] mwifiex:
process rxba_sync event" and used NULL pointer to indicate dropped
packet(Kalle Valo).
Amitkumar Karwar (2):
mwifiex: fix failed to reconnect after interface disabled/enabled
mwifiex: remove misleading disconnect message
Ganapathi Bhat (2):
mwifiex: support random MAC address for scanning
mwifiex: fix radar detection issue
Karthik D A (2):
mwifiex: Fixed endianness problem for big endian platform
mwifiex: add region code information in debugfs
Xinming Hu (2):
mwifiex: process rxba_sync event
mwifiex: add HT aggregation support for adhoc mode
drivers/net/wireless/marvell/mwifiex/11h.c | 27 ++--
drivers/net/wireless/marvell/mwifiex/11n.h | 7 +-
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 78 ++++++++++-
.../net/wireless/marvell/mwifiex/11n_rxreorder.h | 3 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 19 ++-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 18 ++-
drivers/net/wireless/marvell/mwifiex/debugfs.c | 2 +
drivers/net/wireless/marvell/mwifiex/fw.h | 58 ++++++---
drivers/net/wireless/marvell/mwifiex/main.h | 1 +
drivers/net/wireless/marvell/mwifiex/scan.c | 16 +++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 27 ++--
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 2 +-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 144 ++++++++++++++++++++-
drivers/net/wireless/marvell/mwifiex/uap_event.c | 7 +-
14 files changed, 350 insertions(+), 59 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCHv5 wl-drv-next 0/2] register-field manipulation macros
From: Jakub Kicinski @ 2016-07-25 14:45 UTC (permalink / raw)
To: kvalo, linux-wireless; +Cc: netdev, linux-kernel
In-Reply-To: <1467821977-11777-1-git-send-email-jakub.kicinski@netronome.com>
On Wed, 6 Jul 2016 17:19:35 +0100, Jakub Kicinski wrote:
> Hi!
>
> I've added few lines about the compilation problems in
> the commit message of patch 1. I would prefer the mass
> rename of macros in mt7601u not to be part of this series
> so patch 2 is left as it was and I'll follow up once this
> is accepted.
Hi Kalle,
what's the status of this set? It's marked as 'Deferred' in
linux-wireless patchwork.
^ permalink raw reply
* RE: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
From: Amitkumar Karwar @ 2016-07-25 9:33 UTC (permalink / raw)
To: Jouni Malinen
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam
In-Reply-To: <20160722165517.GA14456@w1.fi>
Hi Jouni,
> From: Jouni Malinen [mailto:j@w1.fi]
> Sent: Friday, July 22, 2016 10:25 PM
> To: Amitkumar Karwar
> Cc: Kalle Valo; linux-wireless@vger.kernel.org; Cathy Luo; Nishant
> Sarmukadam
> Subject: Re: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
>
> On Fri, Jul 22, 2016 at 03:59:47PM +0000, Amitkumar Karwar wrote:
> > I am trying to understand the problem you mentioned during IGTK
> rekeying. Today I ran tests with two stations connecting an AP. MFP is
> enabled on all of them.
> >
> > On hostapd side, my observation is add_key() is always called followed
> by set_default_mgmt_key(). set_default_mgmt_key() sets the key added by
> add_key() as default key.
> >
> > We are ignoring set_default_mgmt_key() and updating Tx key index
> during add_key() itself.
> >
> > Your concerns is we should not update Tx key index during add_key().
> Reason is IGTK rekeying is not yet completed with all stations. Right?
>
> Correct. set_default_mgmt_key() does not have much effect for the very
> first IGTK configuration, but whenever doing IGTK rekeying, hostapd
> behaves just like it does with GTK rekeying. In other words, a different
> Key ID is selected (alternating between 4 and 5), a random new IGTK is
> generated, the new IGTK is configured to the local driver (but the old
> IGTK is still supposed to be used for TX), each associated STA is
> notified of the new IGTK, the new IGTK is taken into use once the group
> key handshake has completed with each associated STA. It is that last
> operation that needs set_default_mgmt_key() to allow this rekeying to
> work correctly. If you update the TX Key ID on add_key(), you'll risk
> sending out frames that some of the associated STAs do not yet have a
> key to validate.
>
Got it. We will implement set_default_mgmt_key() and check if any firmware changes required.
Regards,
Amitkumar
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Emmanuel Grumbach @ 2016-07-25 7:51 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Prarit Bhargava, Arend Van Spriel, Stanislaw Gruszka,
Michal Kazior, Kalle Valo, linux-wireless, ath10k,
Arend van Spriel, Greg Kroah-Hartman, Ming Lei
In-Reply-To: <20160722221929.GN5537@wotan.suse.de>
On Sat, Jul 23, 2016 at 1:19 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Fri, Jul 22, 2016 at 08:51:36AM -0400, Prarit Bhargava wrote:
>> On 07/22/2016 08:21 AM, Arend Van Spriel wrote:
>> >> Another option to solve to problem would be stop requesting not
>> >> available publicly firmware. However, I assume some drivers would
>> >> like to preserve that option.
>> >
>> > Actually, this is not the case with brcmfmac. We do need a firmware
>> > file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file,
>> > ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device
>> > works fine without it.
>> >
>> > What is still unclear to me is when request_firmware_direct() would fail
>> > and in what circumstances the udev helper is a valid callback. Can you
>> > explain such a scenario. Another question I have is what the reasons are
>> > behind the 60 seconds timeout.
>>
>> request_firmware_direct() will fail when the specified FW file is not present.
>> This is different from request_firmware() which implements a usermode helper to
>> potentially download firmware, or unpack a firmware image.
>>
>> Re: 60 second timeout ... The 60 second timeout with request_firmware() is
>> completely arbitrary. There is no way for udev to signal back to the kernel
>> that userspace helper has not completed its actions, so the kernel has a 60 dead
>> man timer-ish delay.
>
> Lets call it what it was: the 60 second timeout thing was simply a mistake.
> Its no longer 60 seconds anyway, and in fact its accepted a dreaded issue.
> What *we* should be doing is thinking about proper long term architecture now.
> Async probe was one solution to some issues, a new flexible firmware API
> that avoids the usermode helper 100% is another.
>
> Distros stuck with the fallback option should review their strategies,
> either disabling the fallback option, upgrade systemd, or use alternative
> solutions (opensuse has a good one).
>
>> >>>> However I wonder if changing that will not broke the case when
>> >>>> driver is build-in in the kernel and f/w is not yet available when
>> >>>> driver start to initialize. Or maybe nowadays this is not the case
>> >>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
>> >>>> images are build-in in the kernel or copied to initramfs?
>> >>>
>> >>> That is a nice idea, but I have not seen any change in that area. Could
>> >>> have missed it.
>> >>
>> >> I believe this is how the things are already done, IOW switching to
>> >> request_firmware_direct() in the driver should be no harm.
>> >
>> > Ok. What are the consequences when:
>> > - driver is built-in.
>> > - driver+firmware present on initramfs.
>> > - driver on initramfs, firmware only present on rootfs.
>> > - driver+firmware only on rootfs.
>> >
>> > I assume the third one would be considered a configuration issue.
>>
>> I think your question here can be answered by reading drivers/base/Kconfig:88,
>> and reading about those 4 config options.
>
> No, this documentation is terrible, I've posted some patches to help with this
> mess.
>
>> I could paraphrase it butI think the
>> Kconfig notes are better than I could explain it. Note that this is how things
>> currently work with request_firmware_nowait(). IIRC request_firmware_nowait()
>> is just an asynchronous version of request_firmware().
>
> ... its a mess.
>
Awesome. I leave the code as is and ignore any RHEL bugs that are
related to that. If someone wants to improve all this, I'd be thankful
if he could do the work in the subsystem as Arend suggested.
^ permalink raw reply
* [RFD] mac80211: Handling local operating class in (E)CSA
From: Krishna Chaitanya @ 2016-07-25 7:26 UTC (permalink / raw)
To: linux-wireless, wireless-regdb
Hi,
Some AP's use local operating class in (E)CSA IE's. Currently
mac80211 fails the parsing of those IE's and results in a
disconnection.
What is the best way to add support for local operating classes?
a) Maintaining a per country operating class table in cfg80211
b) Embed operating class info in regdb.txt (crda)
c) Remove the usage of band to calculate frequency? I dont know
of a generic formula to calculate this across bands. So not possible.
--
Thanks,
Regards,
Chaitanya T K.
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Michal Kazior @ 2016-07-25 5:15 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <87fur4nxhn.fsf@toke.dk>
On 20 July 2016 at 17:24, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
>> Felix Fietkau <nbd@nbd.name> writes:
>>
>>> - if I put a hack in the fq code to force the hash to a constant value
>>> (effectively disabling fq without disabling codel), the problem
>>> disappears and even multiple streams get proper performance.
>>
>> There's definitely something iffy about the hashing. Here's the output
>> relevant line from the aqm debug file after running a single TCP stream
>> for 60 seconds to that station:
>>
>> ifname addr tid ac backlog-bytes backlog-packets flows drops marks overlimit collisions
>> tx-bytes tx-packets
>> wlp2s0 04:f0:21:1e:74:20 0 2 0 0 146 16 0 0 0 717758966 467925
>>
>> (there are two extra fields here; I added per-txq CoDel stats, will send
>> a patch later).
>>
>> This shows that the txq has 146 flows associated from that one TCP flow.
>> Looking at this over time, it seems that each time the queue runs empty
>> (which happens way too often, which is what I was originally
>> investigating), another flow is assigned.
>>
>> Michal, any idea why? :)
>
> And to answer this: because the flow is being freed to be reassigned
> when it runs empty, but the counter is not decremented. Is this
> deliberate? I.e. is the 'flows' var supposed to be a total 'new_flows'
> counter and not a measure of the current number of assigned flows?
Yes, it is deliberate. fq_codel qdisc does the same thing and I just
mimicked it.
Michał
^ permalink raw reply
* [PATCH 3/3] staging: wilc1000: Reduce scope for a few variables in mac_ioctl()
From: SF Markus Elfring @ 2016-07-24 20:23 UTC (permalink / raw)
To: linux-wireless, devel, Austin Shin, Chris Park, Glen Lee,
Greg Kroah-Hartman, Johnny Kim, Leo Kim, Tony Cho
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <dbc8c4f3-a234-9b6a-b6a4-9c7ef45d5d31@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Jul 2016 21:45:37 +0200
Three local variables were used only within a single case branch.
* Thus move the data type definition for "rssi" and "size" into the
corresponding code block.
* The variable "length" was not modified after its initialisation.
Thus pass a constant value in the affected function call instead.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/staging/wilc1000/linux_wlan.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
index 7b1ebcc..173be16 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1094,8 +1094,6 @@ int wilc_mac_close(struct net_device *ndev)
static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
{
u8 *buff = NULL;
- s8 rssi;
- u32 size = 0, length = 0;
struct wilc_vif *vif;
s32 ret = 0;
struct wilc *wilc;
@@ -1110,8 +1108,7 @@ static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
case SIOCSIWPRIV:
{
struct iwreq *wrq = (struct iwreq *)req;
-
- size = wrq->u.data.length;
+ u32 size = wrq->u.data.length;
if (size && wrq->u.data.pointer) {
buff = memdup_user(wrq->u.data.pointer,
@@ -1119,7 +1116,9 @@ static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
if (IS_ERR(buff))
return PTR_ERR(buff);
- if (strncasecmp(buff, "RSSI", length) == 0) {
+ if (strncasecmp(buff, "RSSI", 0) == 0) {
+ s8 rssi;
+
ret = wilc_get_rssi(vif, &rssi);
netdev_info(ndev, "RSSI :%d\n", rssi);
--
2.9.2
^ permalink raw reply related
* [PATCH 2/3] staging: wilc1000: One function call less in mac_ioctl() after error detection
From: SF Markus Elfring @ 2016-07-24 20:22 UTC (permalink / raw)
To: linux-wireless, devel, Austin Shin, Chris Park, Glen Lee,
Greg Kroah-Hartman, Johnny Kim, Leo Kim, Tony Cho
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <dbc8c4f3-a234-9b6a-b6a4-9c7ef45d5d31@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Jul 2016 21:15:23 +0200
The kfree() function was called in two cases by the mac_ioctl() function
during error handling even if the passed variable did not contain a pointer
for a valid data item.
Improve this implementation detail by the introduction of another
jump label.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/staging/wilc1000/linux_wlan.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
index cdef645..7b1ebcc 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1130,7 +1130,7 @@ static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
if (copy_to_user(wrq->u.data.pointer, buff, size)) {
netdev_err(ndev, "failed to copy\n");
ret = -EFAULT;
- goto done;
+ goto free_buffer;
}
}
}
@@ -1144,11 +1144,9 @@ static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
goto done;
}
}
-
-done:
-
+free_buffer:
kfree(buff);
-
+done:
return ret;
}
--
2.9.2
^ permalink raw reply related
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