* (no subject)
From: Rajat Jain @ 2016-09-27 16:50 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain, Rajat Jain
From: Wei-Ning Huang <wnhuang@google.com>
Date: Thu, 17 Mar 2016 11:43:16 +0800
Subject: [PATCH] mwifiex: report wakeup for wowlan
Enable notifying wakeup source to the PM core. This allow darkresume to
correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
source.
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
}
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+ cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
}
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
} while (0)
struct mwifiex_plt_wake_cfg {
+ struct device *dev;
int irq_wifi;
bool wake_by_wifi;
};
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [ANNOUNCE] Netdev 1.2 updates (27th September, 2016)
From: Hajime Tazaki @ 2016-09-27 16:18 UTC (permalink / raw)
To: netdev, netfilter-devel, linux-wireless, netdev-conference, lwn
Hello folks,
The Linux netdev 1.2 conference will start on next week and
I hope everyone is ready to join us.
== program ==
The full list of accepted sessions (keynotes, workshops,
talks, bofs) are available at the following page.
http://netdevconf.org/1.2/accepted-sessions.html
We will have a great series of the talks; thank you for
your contributions for the great conference.
We're heavily working on finalizing the program; we will
announce it very soon on the web page. Stay tuned.
== travel information ==
You might be the first time to visit Tokyo/Japan (or even
Asian countries). Several trip tips (transportation, venue
access, etc) are listed in our web page; please check it
out before your trip.
http://netdevconf.org/1.2/travel.html
== mailing list ==
We have received a couple of requests to prepare one-time
mailing list only for the netdev 1.2 attendees. We will
prepare the list asap; please freely use the list to
chat/discuss/communicate among the conference attendees.
== sponsors ==
We have finally a great list of our sponsors. Without such
a huge support, the conference never makes it happen. Many
many thanks !
- Platinum
Verizon, Facebook, Cumulus Networks
- Gold
Mojatatu Networks, VMWare, Google, NTT, LinkedIn, Cisco
- Silver
NetApp, IIJ, Netronome, SolarFlare, Mellanox, Sophos,
RedHat, Intel (new)
- Bronze
Zen Load Balancer
- Media sponsor
LWN.net
We're really looking forward to seeing you in Tokyo. We
hope you will have a safe and great trip.
-- Hajime
^ permalink raw reply
* [PATCH] hostap: Mark the Host AP driver obsolete
From: Jouni Malinen @ 2016-09-27 15:42 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
This is old code for old hardware and it is not really accurate to claim
this to be maintained anymore. Change the status to "Obsolete" to make
it clearer that minor cleanup and other unnecessary changes from
automated tools is not necessarily beneficial and has larger risk of
breaking something without being quickly noticed due to lack of testing.
In addition, remove the old mailing list that does not work anymore and
point the web-page to a more accurate URL.
Signed-off-by: Jouni Malinen <j@w1.fi>
---
MAINTAINERS | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index efd69c76..20de5f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5593,10 +5593,9 @@ F: Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
HOST AP DRIVER
M: Jouni Malinen <j@w1.fi>
-L: hostap@shmoo.com (subscribers-only)
L: linux-wireless@vger.kernel.org
-W: http://hostap.epitest.fi/
-S: Maintained
+W: http://w1.fi/hostap-driver.html
+S: Obsolete
F: drivers/net/wireless/intersil/hostap/
HP COMPAQ TC1100 TABLET WMI EXTRAS DRIVER
--
1.9.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* Re: [V2, 4.9] brcmfmac: use correct skb freeing helper when deleting flowring
From: Kalle Valo @ 2016-09-27 15:48 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: <20160927121104.5771-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Flowrings contain skbs waiting for transmission that were passed to us
> by netif. It means we checked every one of them looking for 802.1x
> Ethernet type. When deleting flowring we have to use freeing function
> that will check for 802.1x type as well.
>
> Freeing skbs without a proper check was leading to counter not being
> properly decreased. This was triggering a WARNING every time
> brcmf_netdev_wait_pend8021x was called.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend@broadcom.com>
> Cc: stable@vger.kernel.org # 4.5+
Patch applied to wireless-drivers-next.git, thanks.
7f00ee2bbc63 brcmfmac: use correct skb freeing helper when deleting flowring
--
https://patchwork.kernel.org/patch/9351797/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: replace WARNING on timeout with a simple error message
From: Kalle Valo @ 2016-09-27 15:47 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: <20160927101224.3534-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Even with timeout increased to 950 ms we get WARNINGs from time to time.
> It mostly happens on A-MPDU stalls (e.g. when station goes out of
> range). It may take up to 5-10 secods for the firmware to recover and
> for that time it doesn't process packets.
>
> It's still useful to have a message on time out as it may indicate some
> firmware problem and incorrect key update. Raising a WARNING however
> wasn't really that necessary, it doesn't point to any driver bug anymore
> and backtrace wasn't much useful.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
2f0e56fa37cc brcmfmac: replace WARNING on timeout with a simple error message
--
https://patchwork.kernel.org/patch/9351657/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] rtlwifi: Add HAL_DEF_WOWLAN case to *_get_hw() routines
From: Kalle Valo @ 2016-09-27 15:46 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Larry Finger
In-Reply-To: <1474736239-9826-2-git-send-email-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Only rtl8821ae implements WOWLAN; however, the other drivers may receive
> a call requesting information about this mode. The other drivers need to
> ignore the request rather than logging that the default branch of the
> switch statement has been reached.
>
> Reported by: Jean Delvare <jdelvare@suse.de>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
2 patches applied to wireless-drivers-next.git, thanks.
1cc49a5b5466 rtlwifi: Add HAL_DEF_WOWLAN case to *_get_hw() routines
8334ffdc8290 rtlwifi: Add explicit values to hw_variables enum
--
https://patchwork.kernel.org/patch/9349217/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: Add switch variable to 'switch case not processed' messages
From: Kalle Valo @ 2016-09-27 15:45 UTC (permalink / raw)
To: Joe Perches
Cc: Larry Finger, Jean Delvare, Chaoming Li, linux-wireless, netdev,
linux-kernel
In-Reply-To: <d091f73a6adf3bdaa09ab0399c22a9fdfe9b188c.1474654979.git.joe@perches.com>
Joe Perches <joe@perches.com> wrote:
> Help along debugging by showing what switch/case variable is not
> being processed in these messages.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Patch applied to wireless-drivers-next.git, thanks.
ad5748893b27 rtlwifi: Add switch variable to 'switch case not processed' messages
--
https://patchwork.kernel.org/patch/9348573/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2016-09-26
From: Kalle Valo @ 2016-09-27 15:36 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1474921450.8149.57.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> One more small pull-request intended for 4.9. =C2=A0It seems that I'm
> actually catching up with our internal tree! :) Nothing major here,
> mostly clean-ups and small bug fixes and improvements.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 0979a913f879ea39504200d83fb9f275a555a5=
8d:
>
> iwlwifi: pcie: use LIST_HEAD() macro (2016-09-19 11:29:35 +0300)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git =
tags/iwlwifi-next-for-kalle-2016-09-26
Pulled, thanks.
--=20
Kalle Valo
^ permalink raw reply
* RE: [PATCH v8] cfg80211: Provision to allow the support for different beacon intervals
From: Undekari, Sunil Dutt @ 2016-09-27 15:36 UTC (permalink / raw)
To: Johannes Berg, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <1474981379.5141.37.camel@sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4+IDIuIFNpbmNlICJkaWZmX2JlYWNvbl9pbnRfZ2NkX21pbiLCoMKg
aXMgb25seSBzcGVjaWZpZWQgLyBhZHZlcnRpc2VkIGluIA0KPj4gdGhlIGludGVyZmFjZSBjb21i
aW5hdGlvbnMgLCBvdXIgbG9naWMgd2FzIHRvIGdldCB0aGUgbWluaW1hbCANCj4+ICJkaWZmX2Jl
YWNvbl9pbnRfZ2NkX21pbiIgb2YgYWxsIHRoZSBtYXRjaGluZyBjb21iaW5hdGlvbnMgYW5kIGxh
dGVyDQo+PiDCoMKgwqDCoGNvbXBhcmUgd2l0aCB0aGUgbmV3IGJlYWNvbiBpbnRlcnZhbC4gKEFQ
SSANCj4+ICJjZmc4MDIxMV9pdGVyX2NvbWJpbmF0aW9ucyIgaGFzIHRvIGJlIGludm9rZWQgdG8g
Z2V0IHRoZSANCj4+IGNvcnJlc3BvbmRpbmcgImRpZmZfYmVhY29uX2ludF9nY2RfbWluIikNCg0K
PlllYWgsIGJ1dCB5b3UgZ2V0IHRoZSBkaWZmX2JlYWNvbl9pbnRfZ2NkX21pbiBmb3IgYWxsIGNv
bWJpbmF0aW9ucyB0aGF0IGFsbG93IHRoZSAqY3VycmVudCogY29tYmluYXRpb24gb2YgaW50ZXJm
YWNlcywgbm90IHRoZSBjb21iaW5hdGlvbnMgdGhhdCBhbGxvdyB0aGUgbmV3ICpuZXcqIGNvbWJp
bmF0aW9uIG9mIGludGVyZmFjZXMsIG5vPw0KDQo+SSBtZWFuLCBjb25zaWRlciB0aGUgY2FzZSB0
aGF0IHlvdSBoYXZlIGEgc2luZ2xlIEFQIGludGVyZmFjZSwgd2l0aCBiZWFjb24gaW50ZXJ2YWwg
MzAwLCBhbmQgeW91J3JlIGFkZGluZyBhbm90aGVyIEFQLCB3aXRoIGJlYWNvbiBpbnRlcnZhbCAx
NTAsIGFuZCB0aGUgZm9sbG93aW5nIGFsbG93ZWQgY29tYmluYXRpb25zOg0KDQrCoD4qIGFwID0g
MQ0KwqA+wqBtZXNoID0gMQ0KwqA+IMKgZGlmZl9iZWFjb25faW50X2djZF9taW4gPSAxMDANCsKg
PiAqIGFwID0gMg0KPiDCoGRpZmZfYmVhY29uX2ludF9nY2RfbWluID0gNTANCg0KPiBXb3VsZG4n
dCB5b3UgcHJldmVudCB0aGF0LCBvciBzb21ldGhpbmc/DQoNCj4gT3Igc2F5IHlvdSBoYXZlDQoN
Cj7CoCogYXAgPSAxDQo+wqAgwqBtZXNoID0gMQ0KPsKgIMKgZGlmZl9iZWFjb25faW50X2djZF9t
aW4gPSAxMDANCj4gwqAqIGFwID3CoDINCj7CoCDCoGRpZmZfYmVhY29uX2ludF9nY2RfbWluID0g
MjAwDQoNCj4gUHJvYmFibHkgZG9lc24ndCByZWFsbHkgbWFrZSBzZW5zZSwgYnV0IG5vdyBpZiB5
b3UgaGF2ZSBhbiBleGlzdGluZyBBUCBpbnRlcmZhY2UsIHlvdSB3b3VsZCB0aGluayB0aGUgbWlu
IGlzIDEwMCwgd2hlbiByZWFsbHkgd2hpbGUgYWRkaW5nIGFub3RoZXIgQVAgaXQgc2hvdWxkIGJl
IDIwMC4NCg0KSW4gUEFUQ0ggdjggLCBjZmc4MDIxMV92YWxpZGF0ZV9iZWFjb25faW50IC0+IGNm
ZzgwMjExX2l0ZXJfY29tYmluYXRpb25zIGNhcnJpZXMgdGhlIGFyZ3VtZW50IGlmdHlwZV9udW0g
LCB3aGljaCBhbHNvIGNvbnNpZGVycyB0aGUgIm5ldyBpbnRlcmZhY2UiIHRoYXQgaXMgZ2V0dGlu
ZyBhZGRlZC4gDQpUaHVzICwgaW4gdGhlIGV4YW1wbGUgeW91IGhhdmUgcXVvdGVkIGFib3ZlICwg
dGhlIGlmdHlwZV9udW0gc2hhbGwgcmVwcmVzZW50IDIgKCBBUCArIEFQICkgLCBhbmQgdGh1cyB0
aGUgbWluX2djZCBvYnRhaW5lZCBvdXQgb2YgY2ZnODAyMTFfaXRlcl9jb21iaW5hdGlvbnMgKGNm
ZzgwMjExX2dldF9iZWFjb25faW50X21pbl9nY2QpIHNoYWxsIGJlIDUwIGZvciB0aGUgZXhhbXBs
ZSAxIGFuZCAyMDAgZm9yIHRoZSBleGFtcGxlIDIgLiANClRodXMgLCBjb25zaWRlcmluZyB0aGUg
dHdvIGV4YW1wbGVzIG1lbnRpb25lZCBhYm92ZSAsIHRoZSBzZWNvbmQgQVAgc2hvdWxkIHN1Y2Nl
ZWQgZm9yICJleGFtcGxlIDEiIHZzIGZhaWx1cmUgZm9yICJleGFtcGxlIDIiIHdpdGggcGF0Y2gg
VjggLCBpc24ndCA/ICANCg0KPj4gSWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5ICwgYXJl
IHlvdSBzYXlpbmcgdGhhdCB0aGlzIG5ldyBhcmd1bWVudCANCj4+IHRvIGNmZzgwMjExX2l0ZXJf
Y29tYmluYXRpb25zIHNoYWxsIGJlIHRoZSBHQ0Qgb2YgYWxsIHRoZSBleGlzdGluZyANCj4+IGJl
YWNvbiBpbnRlcnZhbHMgYW5kIHdvdWxkIGJlIHVzZWQgdG8gbWF0Y2ggd2l0aCB0aGUgY29ycmVz
cG9uZGluZyANCj4+ICJkaWZmX2JlYWNvbl9pbnRfZ2NkX21pbiIgb2YgdGhlIGludGVyZmFjZSBj
b21iaW5hdGlvbnMgaW4gDQo+PiAiY2ZnODAyMTFfaXRlcl9jb21iaW5hdGlvbnMiLg0KDQo+WWVz
LCB0aGF0J3Mgd2hhdCBJIHdhcyB0aGlua2luZy4NCg0KPj4gSWYgeWVzICwgdGhpcyBHQ0QgYXJn
dW1lbnQgZG9lcyBub3QgcmVwcmVzZW50ICwgaWYgdGhlIGJlYWNvbiANCj4+IGludGVydmFscyBv
ZiBhbGwgdGhlIGV4aXN0aW5nIGludGVyZmFjZXMgZGlmZmVyIG9yIG5vdCAsIGlzbuKAmXQgPyBJ
ZiANCj4+IHRoZSAiZGlmZl9iZWFjb25faW50X2djZF9taW4iwqDCoG9mIHRoZSBhbGwgdGhlIG1h
dGNoaW5nIGludGVyZmFjZSANCj4+IGNvbWJpbmF0aW9ucyBpcyAwICwgc3VjaCBkaWZmZXJlZCBi
ZWFjb24gaW50ZXJ2YWxzIHdvdWxkIHBhc3MgdGhlIA0KPj4gY2hlY2sgLCBjb250cmFkaWN0aW5n
IHRoZSBleGlzdGluZyBsb2dpYyAoIG5vdCBhbGxvd2luZyB0aGUgZGlmZmVyZWQgDQo+PiBiZWFj
b24gaW50ZXJ2YWxzKSwgaXNuJ3QgPw0KDQo+T2gsIHdlbGwsIG9rIC0gaWYgYWxsIGV4aXN0aW5n
IGFuZCBuZXcgYmVhY29uIGludGVydmFscyBhcmUgdGhlIHNhbWUgd2UnZCBoYXZlIHRvIGRvIHRo
ZSBsb29rdXAgd2l0aG91dCB0aGUgZXhpc3RpbmcgYmVhY29uIGludGVydmFsIEdDRCBhbmQgc3Rp
bGwgY29tcGFyZSB0byB0aGUgbWluIHNlcGFyYXRlbHkuDQoNCkxldCBtZSByZWl0ZXJhdGUgb3Vy
IHByb2JsZW0gaGVyZSB3aXRoIHRoaXMgYXBwcm9hY2guDQoNClRoZSBjdXJyZW50IGJlaGF2aW9y
IG9mIHRoZSBrZXJuZWwgaXMgdG8gbm90IGFsbG93IHRoZSBjb25maWd1cmF0aW9uIG9mIGRpZmZl
cmVudCBiZWFjb24gaW50ZXJ2YWxzIGFuZCBvdXIgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGlzIG5l
dyBwYXRjaCBzaG91bGQgYmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIHRoZSBleGlzdGluZyBi
ZWhhdmlvci4NCk5vdyAsIGlmIHdlIGdvIHdpdGggdGhpcyBhcHByb2FjaCBvZiAiaW50cm9kdWNp
bmcgYSBuZXcgYXJndW1lbnQgdG8gY2ZnODAyMTFfaXRlcl9jb21iaW5hdGlvbnMgd2hpY2ggc2hh
bGwgYmUgdGhlIEdDRCBvZiBhbGwgdGhlIGV4aXN0aW5nIGNvbWJpbmF0aW9ucyB0byBjaGVjayBh
Z2FpbnN0IHRoZSByZXNwZWN0aXZlICJkaWZmX2JlYWNvbl9pbnRfZ2NkX21pbiIiICwgIGNvbnNp
ZGVyIHRoZSBjYXNlICggc2FtZSBvbmUgd2hpY2ggaXMgbWVudGlvbmVkIGFib3ZlICkgdGhhdCB3
ZSBoYXZlIGEgc2luZ2xlIEFQIGludGVyZmFjZSAoIGJlYWNvbiBpbnRlcnZhbCA9IDMwMCApICwg
YW5kIGEgbmV3IEFQIGlzIGdldHRpbmcgYWRkZWQgKCBiZWFjb24gaW50ZXJ2YWwgPSAxNTAgKSwg
IHdpdGggdGhlIGZvbGxvd2luZyBhbGxvd2VkIGNvbWJpbmF0aW9uczoNCg0KMSkgKiBhcCA9IDIN
CiAgICAgICAgZGlmZl9iZWFjb25faW50X2djZF9taW4gPSAwICggcmF0aGVyIG5vdCBzcGVjaWZp
ZWQgKSANCjIpICAqIGFwID0gMg0KICAgICAgZGlmZl9iZWFjb25faW50X2djZF9taW4gPSAxMDAN
Cg0KVGhlIEdDRCBjYWxjdWxhdGVkIGlzIDE1MCAuIGNmZzgwMjExX2l0ZXJfY29tYmluYXRpb25z
IHNoYWxsIHJldHVybiBzdWNjZXNzIGZvciBib3RoIHRoZSBzY2VuYXJpb3MgKCAxIGFuZCAyICkg
KFRoZSBpbnRlbnRpb24gaGVyZSBpcyB0byBjb21wYXJlIHdpdGggb25seSB0aGUgbm9uemVybyAi
IGRpZmZfYmVhY29uX2ludF9nY2RfbWluIiApDQoNClRoaXMgc3VjY2VzcyBmcm9tICJjZmc4MDIx
MV9pdGVyX2NvbWJpbmF0aW9ucyIgZG9lcyBub3QgcmVwcmVzZW50IGlmIHRoZSBHQ0QgcGFzc2Vk
IGlzIGNvbXBhcmVkIGFnYWluc3QgYSAwIC8gbm9uIHplcm8gImRpZmZfYmVhY29uX2ludF9nY2Rf
bWluIiAsIGlzbid0ID8NCg0KVGh1cyAsIHdlIGFyZSB0cnlpbmcgdG8gc29sdmUgdGhpcyBwcm9i
bGVtICwgYnkgZ2V0dGluZyB0aGUgImRpZmZfYmVhY29uX2ludF9nY2RfbWluIiBmb3IgdGhlIHJl
c3BlY3RpdmUgaW50ZXJmYWNlIGNvbWJpbmF0aW9uICwgYmVmb3JlIGNvbXBhcmluZyBpdCB3aXRo
IHRoZSBjYWxjdWxhdGVkIEdDRC4gDQoNClBsZWFzZSBjb3JyZWN0IHVzLg0KDQpSZWdhcmRzLA0K
U3VuaWwNCg0KIA0KDQo=
^ permalink raw reply
* Re: staging: wilc1000: kernel Oops while opening the device
From: Greg KH @ 2016-09-27 15:21 UTC (permalink / raw)
To: Aditya.Shankar; +Cc: Ganesh.Krishna, nicolas.ferre, linux-wireless, luisbg
In-Reply-To: <1FA4CE79C3B5BA4CB1930722261ABC02CAF99066@CHN-SV-EXMX03.mchp-main.com>
On Mon, Sep 26, 2016 at 05:17:37AM +0000, Aditya.Shankar@microchip.com wrote:
> On Friday 23 September 2016 08:37 PM, Greg KH wrote:
> > On Fri, Sep 23, 2016 at 01:17:08PM +0000, Aditya.Shankar@microchip.com wrote:
> >> On Thursday 22 September 2016 06:04 PM, Ganesh Krishna - I00112 wrote:
> >>>> -----Original Message-----
> >>>> From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
> >>>> Sent: Monday, September 19, 2016 7:12 PM
> >>>> To: Nicolas Ferre
> >>>> Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh Krishna - I00112; luisbg@osg.samsung.com
> >>>> Subject: Re: staging: wilc1000: kernel Oops while opening the device
> >>>>
> >>>> On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> While using the wilc1000 driver with latest 4.8-rc7, I have
> >>>>> difficulties to open the device and actually use it as I have this
> >>>>> kernel Oops right after the loading of the firmware (wilc1003_firmware.bin).
> >>>>>
> >>>>> If I revert back the driver to its
> >>>>> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did
> >>>>> this because I tend to think that it might be related to the latest move on this driver to "completion" or "work queues".
> >>>>> It seems to be a regression from 4.7.
> >>>>
> >>>> Ick, not good at all.
> >>>>
> >>>> Any chance you can run 'git bisect' to see if you can find the offending patch?
> >>>>
> >>>> I thought the maintainers were testing this driver over time :(
> >>>
> >>>> thanks,
> >>>>
> >>>> greg k-h
> >>>
> >>> Ick indeed. Maintainers are on it full time. Thank you very much for the flag. While I am only reporting activity, hope to have results soon.
> >>> Regards,
> >>> ganesh k
> >>>
> >> Hi All,
> >>
> >> bisecting changes on the wilc1000 host driver, I find that this problem seems to occur after the below change.
> >> As of now, I only know the where and not the why. So I will continue to figure out why this happens.
> >>
> >> commit 2518ac59eb27ed003c5a97e8f9588adafdfe4a8a
> >> Author: Binoy Jayan <binoy.jayan@linaro.org>
> >> Date: Thu Jun 23 11:11:51 2016 +0530
> >>
> >> staging: wilc1000: Replace kthread with workqueue for host interface
> >>
> >> Deconstruct the kthread / message_queue logic, replacing it with
> >> create_singlethread_workqueue() / queue_work() setup, by adding a
> >> 'struct work_struct' to 'struct host_if_msg'. The current kthread
> >> hostIFthread() is converted to a work queue helper with the name
> >> 'host_if_work'.
> >
> > So if you revert this, it works?
> >
> > If so, let us know and I will gladly revert it, as breaking things is
> > not ok.
> >
> > thanks,
> >
> > greg k-h
> >
> Unfortunately no. We will have to revert this commit and the one submitted after this.
> The commit a5c84b2 after 2518ac5 is heavily reliant on its parent 2518ac5.
>
> Note that reverting 2518ac5 throws up a couple of minor merge conflicts which can be
> resolved by dropping changes in HEAD and retaining the parent commit of 2518ac5.
> With this, the crash is not seen anymore.
Can you send me a patch, or series of patches, that does all of this so
I know I get it correct?
thanks,
greg k-h
^ permalink raw reply
* Re: [v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Stephan Mueller @ 2016-09-27 15:17 UTC (permalink / raw)
To: Kalle Valo
Cc: Ted Tso, herbert, linux-kernel, linux-crypto, ath9k-devel,
linux-wireless, ath9k-devel, Kalle Valo, Jason Cooper
In-Reply-To: <2ba03f89daee4f09a88a1238943eb49d@euamsexm01a.eu.qualcomm.com>
Am Dienstag, 27. September 2016, 16:44:16 CEST schrieb Kalle Valo:
Hi Kalle,
> Stephan Mueller <smueller@chronox.de> wrote:
> > The ATH9K driver implements an RNG which is completely bypassing the
> > standard Linux HW generator logic.
> >
> > The RNG may or may not deliver entropy. Considering the conservative
> > approach in treating entropy with respect to non-auditable sources, this
> > patch changes the delivered entropy value to zero. The RNG still feeds
> > data into the input_pool but it is assumed to have no entropy.
> >
> > When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
> > the entropy estimation considering that a user can change that value at
> > boot and runtime.
> >
> > Reviewed-by: Jason Cooper <jason@lakedaemon.net>
> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
>
> Based on the discussion I'm dropping this patch. But the discussion was
> hard to follow so please let me know if I misunderstood.
I guess the rejection is appropriate, but something needs to be done:
add_hwgenerator_randomness should not be used in this scenario.
>
> Patch set to Rejected.
Ciao
Stephan
^ permalink raw reply
* Re: wil6200
From: Lior David @ 2016-09-27 15:04 UTC (permalink / raw)
To: Vikram; +Cc: linux-wireless
In-Reply-To: <CALZLQ=anWS6ThxEOnifRcxgYyk3BvWwMUFqTtZdOMcqZYA+igA@mail.gmail.com>
On 9/26/2016 9:05 PM, Vikram wrote:
> Hi Lior,
>
> On 26 September 2016 at 18:19, Lior David <liord@codeaurora.org> wrote:
>> On 9/25/2016 6:15 PM, Vikram wrote:
>>> Hi,
>>>
>>> Could you please let me know as to how to change the mode of wil6200
>>> chip from WBE to WiFi?
>>>
>>> Regards,
>>> Vikram
>>>
>> What is the exact device you are using? Older devices have firmware that only
>> supports WBE mode.
>>
>> Thanks,
>> Lior
>
> I'm using Dell Wireless DW1601 7Gbps WiGig 802.11ad 802.11n 2*2 WiFi
> Half Mini Card abgn+ad 2*2:2
Unfortunately it looks like this is an old chip which does not support WIFI
mode. There are 2 main problems:
1. The chip has its firmware burned into flash and cannot be upgraded, unlike
newer chips where firmware can be loaded into memory (so wil6210 driver can use
the firmware file from /lib/firmware).
2. Based on the product description this card was specifically used to connect
to the Dell wireless dock which used WBE, so it has a firmware with only WBE
support.
Thanks,
Lior
>
> Regards,
> Vikram
>
^ permalink raw reply
* Re: [1/2] ath9k: change entropy formula for easier understanding
From: Kalle Valo @ 2016-09-27 14:53 UTC (permalink / raw)
To: miaoqing pan
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-1-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> The quality of ADC entropy is 10 bits of min-entropy for
> a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
> '(((x) * 8 * 10) >> 5)' for easier understanding.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
I need some help here, it this patch ok to take or should I drop it? The
discussion is available from the patchwork link below if someone needs to
refresh the memory.
--
https://patchwork.kernel.org/patch/9270463/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Kalle Valo @ 2016-09-27 14:44 UTC (permalink / raw)
To: Stephan Mueller
Cc: Ted Tso, herbert, linux-kernel, linux-crypto, ath9k-devel,
linux-wireless, ath9k-devel, Kalle Valo, Jason Cooper
In-Reply-To: <1654172.XfclnXhRmn@positron.chronox.de>
Stephan Mueller <smueller@chronox.de> wrote:
> The ATH9K driver implements an RNG which is completely bypassing the
> standard Linux HW generator logic.
>
> The RNG may or may not deliver entropy. Considering the conservative
> approach in treating entropy with respect to non-auditable sources, this
> patch changes the delivered entropy value to zero. The RNG still feeds
> data into the input_pool but it is assumed to have no entropy.
>
> When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
> the entropy estimation considering that a user can change that value at
> boot and runtime.
>
> Reviewed-by: Jason Cooper <jason@lakedaemon.net>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Based on the discussion I'm dropping this patch. But the discussion was
hard to follow so please let me know if I misunderstood.
Patch set to Rejected.
--
https://patchwork.kernel.org/patch/9266265/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Shajakhan, Mohammed Shafi (Mohammed Shafi) @ 2016-09-27 13:04 UTC (permalink / raw)
To: ath10k@lists.infradead.org
Cc: mohammed@codeaurora.org, linux-wireless@vger.kernel.org
In-Reply-To: <1474981300-15945-1-git-send-email-mohammed@qca.qualcomm.com>
apologies please ignore this , wrong patch due to confusing v4 tag=0A=
=0A=
please review,=0A=
=0A=
[PATCH] ath10k: Cleanup calling ath10k_htt_rx_h_unchain=0A=
=0A=
________________________________________=0A=
From: Shajakhan, Mohammed Shafi (Mohammed Shafi)=0A=
Sent: 27 September 2016 18:31=0A=
To: ath10k@lists.infradead.org=0A=
Cc: mohammed@codeaurora.org; linux-wireless@vger.kernel.org; Shajakhan, Moh=
ammed Shafi (Mohammed Shafi)=0A=
Subject: [PATCH v4] ath10k: Cleanup calling ath10k_htt_rx_h_unchain=0A=
=0A=
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>=0A=
=0A=
'ath10k_htt_rx_h_unchain' is need to be called only if the return=0A=
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this=0A=
change makes it more explicit and avoids doing a skb_peek, fetching=0A=
rx descriptor pointer, checking rx msdu decap format for the case of=0A=
ret =3D 0 (unchained msdus). Found this change during code walk through,=0A=
not sure if this addresses any issue.=0A=
=0A=
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>=0A=
---=0A=
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++------=0A=
1 file changed, 6 insertions(+), 6 deletions(-)=0A=
=0A=
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireles=
s/ath/ath10k/htt_rx.c=0A=
index 7ae9349..e51dace 100644=0A=
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c=0A=
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c=0A=
@@ -1459,8 +1459,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *a=
msdu)=0A=
}=0A=
=0A=
static void ath10k_htt_rx_h_unchain(struct ath10k *ar,=0A=
- struct sk_buff_head *amsdu,=0A=
- bool chained)=0A=
+ struct sk_buff_head *amsdu)=0A=
{=0A=
struct sk_buff *first;=0A=
struct htt_rx_desc *rxd;=0A=
@@ -1471,9 +1470,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar=
,=0A=
decap =3D MS(__le32_to_cpu(rxd->msdu_start.common.info1),=0A=
RX_MSDU_START_INFO1_DECAP_FORMAT);=0A=
=0A=
- if (!chained)=0A=
- return;=0A=
-=0A=
/* FIXME: Current unchaining logic can only handle simple case of r=
aw=0A=
* msdu chaining. If decapping is other than raw the chaining may b=
e=0A=
* more complex and this isn't handled by the current code. Don't e=
ven=0A=
@@ -1550,7 +1546,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_=
htt *htt)=0A=
}=0A=
=0A=
ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);=0A=
- ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);=0A=
+=0A=
+ /* only for ret =3D 1 indicates chained msdus */=0A=
+ if (ret > 0)=0A=
+ ath10k_htt_rx_h_unchain(ar, &amsdu);=0A=
+=0A=
ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);=0A=
ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);=0A=
ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);=0A=
--=0A=
1.9.1=0A=
=0A=
^ permalink raw reply related
* [PATCH] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Mohammed Shafi Shajakhan @ 2016-09-27 13:01 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
'ath10k_htt_rx_h_unchain' is need to be called only if the return
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
change makes it more explicit and avoids doing a skb_peek, fetching
rx descriptor pointer, checking rx msdu decap format for the case of
ret = 0 (unchained msdus). Found this change during code walk through,
not sure if this addresses any issue.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 7ae9349..e51dace 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1459,8 +1459,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *amsdu)
}
static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
- struct sk_buff_head *amsdu,
- bool chained)
+ struct sk_buff_head *amsdu)
{
struct sk_buff *first;
struct htt_rx_desc *rxd;
@@ -1471,9 +1470,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
decap = MS(__le32_to_cpu(rxd->msdu_start.common.info1),
RX_MSDU_START_INFO1_DECAP_FORMAT);
- if (!chained)
- return;
-
/* FIXME: Current unchaining logic can only handle simple case of raw
* msdu chaining. If decapping is other than raw the chaining may be
* more complex and this isn't handled by the current code. Don't even
@@ -1550,7 +1546,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
}
ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);
- ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
+
+ /* only for ret = 1 indicates chained msdus */
+ if (ret > 0)
+ ath10k_htt_rx_h_unchain(ar, &amsdu);
+
ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);
ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);
ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v8] cfg80211: Provision to allow the support for different beacon intervals
From: Johannes Berg @ 2016-09-27 13:02 UTC (permalink / raw)
To: Undekari, Sunil Dutt, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <c6f1a958d7f941b5a7dc8564d3f1c371@aphydexm01f.ap.qualcomm.com>
Hi,
Sorry for the long delay.
> > In order to validate a new beacon interval, you're first looking up
> > the min GCD value of all the combinations that allow the *current*
> > scenario, but doing that matching without the right # of channels
> > or radar detect parameters? And then you're trying to match that to
> > the new beacon interval?
> Yes . Please allow us to explain the rationale for doing so.
> 1. The intention here is to ensure that the beacon interval
> configured for any single interface is greater than the
> "diff_beacon_int_gcd_min" specified in the respective
> combinations.
Sure, ok, so far so good - not that I think it would really be
necessary to validate it this way, but ok.
> 2. Since "diff_beacon_int_gcd_min" is only specified / advertised in
> the interface combinations , our logic was to get the minimal
> "diff_beacon_int_gcd_min" of all the matching combinations and later
> compare with the new beacon interval. (API
> "cfg80211_iter_combinations" has to be invoked to get the
> corresponding "diff_beacon_int_gcd_min")
Yeah, but you get the diff_beacon_int_gcd_min for all combinations that
allow the *current* combination of interfaces, not the combinations
that allow the new *new* combination of interfaces, no?
I mean, consider the case that you have a single AP interface, with
beacon interval 300, and you're adding another AP, with beacon interval
150, and the following allowed combinations:
* ap = 1
mesh = 1
diff_beacon_int_gcd_min = 100
* ap = 2
diff_beacon_int_gcd_min = 50
Wouldn't you prevent that, or something?
Or say you have
* ap = 1
mesh = 1
diff_beacon_int_gcd_min = 100
* ap = 2
diff_beacon_int_gcd_min = 200
Probably doesn't really make sense, but now if you have an existing AP
interface, you would think the min is 100, when really while adding
another AP it should be 200.
> 3. If the beacon interval configured needs to be ensured to be
> greater than the "diff_beacon_int_gcd_min" configured for both the
> "single interface" and "interface combination" , we have resorted to
> "2" (get the minimal of "diff_beacon_int_gcd_min" among all the
> matched interface combinations and then compare it with the
> configured beacon interval).
Yeah, I think you're just matching the interface combinations wrong; I
think it needs to take into account the new interfaces and the existing
beacon intervals.
> > If the driver specified diff_beacon_int_gcd_min, then don't do
> > anything in cfg80211_validate_beacon_int(), other than perhaps a
> > minimal range check against the minimum of all
> > >diff_beacon_int_gcd_min values for all combinations.
> > That new argument could be made the GCD of all existing beaconing
> > interfaces (or 0 if no such exists), since that's sufficient for
> > checking against a new min_gcd.
> If I understand this correctly , are you saying that this new
> argument to cfg80211_iter_combinations shall be the GCD of all the
> existing beacon intervals and would be used to match with the
> corresponding "diff_beacon_int_gcd_min" of the interface combinations
> in "cfg80211_iter_combinations".
Yes, that's what I was thinking.
> If yes , this GCD argument does not represent , if the beacon
> intervals of all the existing interfaces differ or not , isn’t ? If
> the "diff_beacon_int_gcd_min" of the all the matching interface
> combinations is 0 , such differed beacon intervals would pass the
> check , contradicting the existing logic ( not allowing the differed
> beacon intervals), isn't ?
Oh, well, ok - if all existing and new beacon intervals are the same
we'd have to do the lookup without the existing beacon interval GCD and
still compare to the min separately.
> Thus, wouldn't it be a better option to first get the
> "diff_beacon_int_gcd_min" advertised by the respective interface
> combinations and then later compare it with the configured /
> calculated beacon interval's GCD .
As above, I think you might find a combination that no longer applies
after the new interface is added, thus causing a situation that isn't
actually covered by the allowed combinations.
> Also , not quite sure how would your comment " matching without the
> right # of channels or radar detect parameters" get addressed with
> your new proposal ( adding a new argument to
> "cfg80211_iter_combinations" )
That's just addressed by not doing the "get min min_gcd" first step,
where you used it wrong, afaict.
johannes
^ permalink raw reply
* [PATCH v4] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Mohammed Shafi Shajakhan @ 2016-09-27 13:01 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
'ath10k_htt_rx_h_unchain' is need to be called only if the return
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
change makes it more explicit and avoids doing a skb_peek, fetching
rx descriptor pointer, checking rx msdu decap format for the case of
ret = 0 (unchained msdus). Found this change during code walk through,
not sure if this addresses any issue.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 7ae9349..e51dace 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1459,8 +1459,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *amsdu)
}
static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
- struct sk_buff_head *amsdu,
- bool chained)
+ struct sk_buff_head *amsdu)
{
struct sk_buff *first;
struct htt_rx_desc *rxd;
@@ -1471,9 +1470,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
decap = MS(__le32_to_cpu(rxd->msdu_start.common.info1),
RX_MSDU_START_INFO1_DECAP_FORMAT);
- if (!chained)
- return;
-
/* FIXME: Current unchaining logic can only handle simple case of raw
* msdu chaining. If decapping is other than raw the chaining may be
* more complex and this isn't handled by the current code. Don't even
@@ -1550,7 +1546,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
}
ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);
- ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
+
+ /* only for ret = 1 indicates chained msdus */
+ if (ret > 0)
+ ath10k_htt_rx_h_unchain(ar, &amsdu);
+
ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);
ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);
ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: add key management offload feature
From: Johannes Berg @ 2016-09-27 12:36 UTC (permalink / raw)
To: Amitkumar Karwar, linux-wireless, hostap, Jouni Malinen,
Ilan Peer
Cc: yangzy, Cathy Luo, Nishant Sarmukadam, lihz
In-Reply-To: <1474973796-1873-1-git-send-email-akarwar@marvell.com>
> #define WLAN_CIPHER_SUITE_SMS4 0x00147201
> +#define WLAN_CIPHER_SUITE_PMK 0x00147202
> +#define WLAN_CIPHER_SUITE_PMK_R0 0x00147203
> +#define WLAN_CIPHER_SUITE_PMK_R0_NAME 0x00147204
Err, what? No, things can't work that way. This is the Chinese
company's OUI, you can't just assign it to PMK stuff.
> + * @NL80211_ATTR_AUTHORIZED: flag attribute, if set indicates that the
> + * connection is authorized.
> + *
> * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> @@ -2267,6 +2270,8 @@ enum nl80211_attrs {
>
> NL80211_ATTR_MESH_PEER_AID,
>
> + NL80211_ATTR_AUTHORIZED,
This already exists, no?
NL80211_STA_FLAG_AUTHORIZED should be more or less equivalent, if you
do it per station (or just for the AP in case of managed connection)
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> @@ -3687,6 +3692,9 @@ enum nl80211_key_attributes {
> NL80211_KEY_DEFAULT_MGMT,
> NL80211_KEY_TYPE,
> NL80211_KEY_DEFAULT_TYPES,
> + NL80211_KEY_REPLAY_CTR,
> + NL80211_KEY_KCK,
> + NL80211_KEY_KEK,
I don't think we should conflate the (P)MK and *TK concepts in nl80211,
they're both keys, but they're completely separate in terms of expected
usage.
Ilan and I looked at this, considering 4-way-HS offload after 1X
authentication, and think that the more natural API would be to add all
the necessary data to the PMKSA cache entry. Thus, a PMKSA cache entry
for a device that does 4-way-handshake offloading would include the PMK
(or perhaps MSK?), and for FT it would also including the PMK-R0,
PMKR0Name (and possibly the MDID, or can it be derived?)
However, I'm wondering what exactly the offloads here do. Jouni, could
you also chime in with the QCA (vendor command) design?
In particular, with key management offloaded, it's not clear to me what
exactly the roles of the device and host are here. I'm considering that
the device would handle the 4-way and 2-way handshakes, but then you
wouldn't need the KEK/KCK/ReplayCounter in the host, so there wouldn't
be much point in giving them to it.
But if the device doesn't do that, what exactly *does* it do?
Thanks,
johannes
^ permalink raw reply
* Re: [v2,02/21] ath10k: fix typo in logging message
From: Kalle Valo @ 2016-09-27 12:19 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, Ben Greear, linux-wireless
In-Reply-To: <1462986153-16318-3-git-send-email-greearb@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
3 patches applied to ath-next branch of ath.git, thanks.
aa66ba0c31c6 ath10k: fix typo in logging message
15138fdf327d ath10k: document cycle count related counters
30d2049b3277 ath10k: support up to 64 vdevs
--
https://patchwork.kernel.org/patch/9073591/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Fix rfc1042 header retrieval in QCA4019 with eth decap mode
From: Kalle Valo @ 2016-09-27 12:16 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: ath10k, Vasanthakumar Thiagarajan, linux-wireless
In-Reply-To: <1469623085-13942-1-git-send-email-vthiagar@qti.qualcomm.com>
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> wrote:
> Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
> rx_hdr_status is not padded to align in 4-byte boundary. Define a
> new hw_params field to handle different alignment behaviour between
> different hw. This patch fixes improper retrieval of rfc1042 header
> with QCA4019. This patch along with "ath10k: Properly remove padding
> from the start of rx payload" will fix traffic failure in ethernet
> decap mode for QCA4019.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
2f38c3c01de9 ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap mode
--
https://patchwork.kernel.org/patch/9249751/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/3] ath10k: use devm_clk_get() instead of clk_get()
From: Kalle Valo @ 2016-09-27 12:14 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-wireless, Luis R. Rodriguez, netdev, linux-kernel, ath10k,
Masahiro Yamada, Johannes Berg
In-Reply-To: <1473165598-28683-2-git-send-email-yamada.masahiro@socionext.com>
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Use the managed variant of clk_get() to simplify the failure path
> and the .remove callback.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
3 patches applied to ath-next branch of ath.git, thanks.
828662753d60 ath10k: use devm_clk_get() instead of clk_get()
c5d8a34675d9 ath10k: use devm_reset_control_get() instead of reset_control_get()
65901a9e7058 ath10k: do not check if reset is NULL
--
https://patchwork.kernel.org/patch/9316579/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH V2 4.9] brcmfmac: use correct skb freeing helper when deleting flowring
From: Rafał Miłecki @ 2016-09-27 12:11 UTC (permalink / raw)
To: Kalle Valo
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: <20160927091428.19223-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
Flowrings contain skbs waiting for transmission that were passed to us
by netif. It means we checked every one of them looking for 802.1x
Ethernet type. When deleting flowring we have to use freeing function
that will check for 802.1x type as well.
Freeing skbs without a proper check was leading to counter not being
properly decreased. This was triggering a WARNING every time
brcmf_netdev_wait_pend8021x was called.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend@broadcom.com>
Cc: stable@vger.kernel.org # 4.5+
---
V2: Add Cc for stable 4.5+. It doesn't apply cleanly to 4.4 and is not
possible for 4.3- due to missing brcmf_get_ifp.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
index b16b367..d0b738d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
@@ -234,13 +234,20 @@ static void brcmf_flowring_block(struct brcmf_flowring *flow, u16 flowid,
void brcmf_flowring_delete(struct brcmf_flowring *flow, u16 flowid)
{
+ struct brcmf_bus *bus_if = dev_get_drvdata(flow->dev);
struct brcmf_flowring_ring *ring;
+ struct brcmf_if *ifp;
u16 hash_idx;
+ u8 ifidx;
struct sk_buff *skb;
ring = flow->rings[flowid];
if (!ring)
return;
+
+ ifidx = brcmf_flowring_ifidx_get(flow, flowid);
+ ifp = brcmf_get_ifp(bus_if->drvr, ifidx);
+
brcmf_flowring_block(flow, flowid, false);
hash_idx = ring->hash_id;
flow->hash[hash_idx].ifidx = BRCMF_FLOWRING_INVALID_IFIDX;
@@ -249,7 +256,7 @@ void brcmf_flowring_delete(struct brcmf_flowring *flow, u16 flowid)
skb = skb_dequeue(&ring->skblist);
while (skb) {
- brcmu_pkt_buf_free_skb(skb);
+ brcmf_txfinalize(ifp, skb, false);
skb = skb_dequeue(&ring->skblist);
}
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 4.9] brcmfmac: use correct skb freeing helper when deleting flowring
From: Kalle Valo @ 2016-09-27 12:08 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend Van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Network Development, Linux Kernel Mailing List,
Rafał Miłecki
In-Reply-To: <CACna6rxDb_KMwGTFKu1Mf9azmk_PLO0aLR3foRtkqyywa1DNVQ@mail.gmail.com>
Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
>>>>> Kalle: this isn't important enough for 4.8 as it's too late for that.
>>>>>
>>>>> I'd like to get it for 4.9 however, as this fixes bug that could lead
>>>>> to WARNING on every add_key/del_key call. We was struggling with these
>>>>> WARNINGs for some time and this fixes one of two problems causing the=
m.
>>>
>>> Ok, I'll queue this for 4.9.
>>>
>>>> Please mark it for stable as well.
>>>
>>> I can add that. Any ideas how old releases stable releases should this
>>> go to?
>>
>> I was analyzing this.
>> 1) This patch uses brcmf_get_ifp which is available in 4.4+ only.
>> 2) It applies cleanly to 4.5+ only due to 32f90caa7debd ("brcmfmac:
>> Increase nr of supported flowrings.")
>> 3) 4.4 would also require applying to the patch without broadcom/ subdir
>>
>> That said I suggest 4.5+. Any objections?
>
> Let me see if patchwork with pick Cc tag as it does for others.
>
> Cc: stable@vger.kernel.org # 4.5+
An excellent idea but no luck:
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend@broadcom.com>
I'll add this to my patchwork wishlist though, I think it would be a
really useful feature to have.
(The question marks are because of my buggy copy paste, ignore those)
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 4.9] brcmfmac: use correct skb freeing helper when deleting flowring
From: Rafał Miłecki @ 2016-09-27 12:07 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Network Development, Linux Kernel Mailing List,
Rafał Miłecki
In-Reply-To: <41e5f45f-1956-8c9d-49d4-cd73e2c5c7c0@broadcom.com>
On 27 September 2016 at 14:04, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 27-9-2016 13:58, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 27 September 2016 at 13:44, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com=
> wrote:
>>> On 27 September 2016 at 13:27, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>> Arend Van Spriel <arend.vanspriel@broadcom.com> writes:
>>>>
>>>>> On 27-9-2016 11:14, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>>
>>>>>> Flowrings contain skbs waiting for transmission that were passed to =
us
>>>>>> by netif. It means we checked every one of them looking for 802.1x
>>>>>> Ethernet type. When deleting flowring we have to use freeing functio=
n
>>>>>> that will check for 802.1x type as well.
>>>>>>
>>>>>> Freeing skbs without a proper check was leading to counter not being
>>>>>> properly decreased. This was triggering a WARNING every time
>>>>>> brcmf_netdev_wait_pend8021x was called.
>>>>>
>>>>> Acked-by: Arend van Spriel <arend@broadcom.com>
>>>>>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>> ---
>>>>>> Kalle: this isn't important enough for 4.8 as it's too late for that=
.
>>>>>>
>>>>>> I'd like to get it for 4.9 however, as this fixes bug that could lea=
d
>>>>>> to WARNING on every add_key/del_key call. We was struggling with the=
se
>>>>>> WARNINGs for some time and this fixes one of two problems causing th=
em.
>>>>
>>>> Ok, I'll queue this for 4.9.
>>>>
>>>>> Please mark it for stable as well.
>>>>
>>>> I can add that. Any ideas how old releases stable releases should this
>>>> go to?
>>>
>>> I was analyzing this.
>>> 1) This patch uses brcmf_get_ifp which is available in 4.4+ only.
>>> 2) It applies cleanly to 4.5+ only due to 32f90caa7debd ("brcmfmac:
>>> Increase nr of supported flowrings.")
>>> 3) 4.4 would also require applying to the patch without broadcom/ subdi=
r
>>>
>>> That said I suggest 4.5+. Any objections?
>
> No objections. Just a tip. I tend to look at kernel.org main page to see
> the stable and long-term kernel listed. So 4.7+ and 4.5+ have same
> meaning as 4.5 and 4.6 are not stable/long-term kernels.
Some projects may work on their own stable kernels, e.g. Ubuntu, see:
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
That's why I don't always look strictly at upstream stable releases only.
--=20
Rafa=C5=82
^ 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