* Re: [PATCH V2] mac80211: Ignore VHT IE from peer with wrong rx_mcs_map
From: Johannes Berg @ 2016-11-15 13:20 UTC (permalink / raw)
To: Filip Matusiak, linux-wireless
Cc: marek.kwaczynski, davem, netdev, linux-kernel
In-Reply-To: <1478077466-4308-1-git-send-email-filip.matusiak@tieto.com>
On Wed, 2016-11-02 at 10:04 +0100, Filip Matusiak wrote:
> This is a workaround for VHT-enabled STAs which break the spec
> and have the VHT-MCS Rx map filled in with value 3 for all eight
> spacial streams, an example is AR9462 in AP mode.
>
> As per spec, in section 22.1.1 Introduction to the VHT PHY
> A VHT STA shall support at least single spactial stream VHT-MCSs
> 0 to 7 (transmit and receive) in all supported channel widths.
>
> Some devices in STA mode will get firmware assert when trying to
> associate, examples are QCA9377 & QCA6174.
>
> Packet example of broken VHT Cap IE of AR9462:
>
> [...]
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH] Revert "mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE"
From: Johannes Berg @ 2016-11-15 13:32 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: emmanuel.grumbach
In-Reply-To: <20161103111247.18086-1-nbd@nbd.name>
On Thu, 2016-11-03 at 12:12 +0100, Felix Fietkau wrote:
> This reverts commit c68df2e7be0c1238ea3c281fd744a204ef3b15a0.
>
> __sta_info_recalc_tim turns into a no-op if local->ops->set_tim is
> not
> set. This prevents the beacon TIM bit from being set for all drivers
> that do not implement this op (almost all of them), thus thoroughly
> essential AP mode powersave functionality.
>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH RESEND v2] cfg80211: add bitrate for 20MHz MCS 9
From: Johannes Berg @ 2016-11-15 13:34 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless
In-Reply-To: <20161031182840.5984-1-twp@qca.qualcomm.com>
On Mon, 2016-10-31 at 11:28 -0700, Thomas Pedersen wrote:
> Some drivers (ath10k) report MCS 9 @ 20MHz, which
> technically isn't defined. To get more meaningful value
> than 0 out of this however, just extrapolate a bitrate
> from ratio of MCS 7 and 9 in channels where it is allowed.
>
applied.
johannes
^ permalink raw reply
* RE: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value
From: Nicola Smaldone @ 2016-11-15 13:18 UTC (permalink / raw)
To: Gianfranco Costamagna, Kalle Valo
Cc: Arend Van Spriel, brcm80211-dev-list@broadcom.com,
linux-wireless@vger.kernel.org, Marco.Arlone@roj.com
In-Reply-To: <1967239621.630327.1479215628178@mail.yahoo.com>
Tm8gcHJvYmxlbSBmb3IgbWUsIHRoYW5rcy4NCg0KTmljb2xhIFNNQUxET05F
DQp3d3cudGllcnJhdGVsZW1hdGljcy5jb20NCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IEdpYW5mcmFuY28gQ29zdGFtYWduYSBbbWFp
bHRvOmxvY3V0dXNvZmJvcmdAZGViaWFuLm9yZ10gDQpTZW50OiBtYXJ0ZWTD
rCAxNSBub3ZlbWJyZSAyMDE2IDE0OjE0DQpUbzogS2FsbGUgVmFsbyA8a3Zh
bG9AY29kZWF1cm9yYS5vcmc+DQpDYzogQXJlbmQgVmFuIFNwcmllbCA8YXJl
bmQudmFuc3ByaWVsQGJyb2FkY29tLmNvbT47IGJyY204MDIxMS1kZXYtbGlz
dEBicm9hZGNvbS5jb207IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9y
ZzsgTmljb2xhIFNtYWxkb25lIDxuc21hbGRvbmVAdGllcnJhdGVsZW1hdGlj
cy5jb20+OyBNYXJjby5BcmxvbmVAcm9qLmNvbQ0KU3ViamVjdDogUmU6IFtQ
QVRDSF0gYnJvYWRjb20vYnJjbTgwMjExL2JyY21mbWFjL2NmZzgwMjExIGRy
aXZlciwgYmFkIHJlZ3VsYXRvcnkgZG9tYWluIGZyZXF1ZW5jeSB2YWx1ZQ0K
DQpIaSwNCg0KDQo+IFNpZ25lZC1vZmYtYnk6IE5pY29sYSBTbWFsZG9uZSA8
bmljb2xhLnNtYWxkb25lQHRpZXJyYXNlcnZpY2UuY29tPg0KDQo+IFNpZ25l
ZC1vZmYtYnk6IEFybG9uZSBNYXJjbyA8bWFyY28uYXJsb25lQHJvai5jb20+
DQoNCj5QbGVhc2Ugbm90ZSB0aGF0IHlvdSBjYW5ub3QgYWRkIFNpZ25lZC1v
ZmYtYnkgZm9yIG90aGVyIHBlb3BsZSB3aXRob3V0IA0KPnRoZWlyIGV4cGxp
Y2l0IGFwcHJvdmFsIChzZWUgRG9jdW1lbnRhdGlvbi9TdWJtaXR0aW5nUGF0
Y2hlcykuIEkgZG9uJ3QgDQo+a25vdyBpZiB0aGV5IGRpZCBpdCBpbiB0aGlz
IGNhc2Ugb3Igbm90LCBidXQgd2FudGVkIHRvIHBvaW50IG91dCB0aGlzIA0K
PmFueXdheS4NCg0KDQpUaGUgZmlyc3Qgc2lnbm9mZiBpcyBteXNlbGYsIHdp
dGggdGhlIGNvbXBhbnkgZW1haWwsIHRoZSBvdGhlciB0d28gc2lnbm9mZnMg
YXJlIGZyb206IHRoZSBhdXRob3IsIGFuZCBOaWNvbGEsIHdobyBkaWQgd29y
ayB3aXRoIG1lIHRvIHRlc3QgaXQgKGV2ZW4gaWYgYSB0eXBvIGZpeCBpcyBu
b3QgInRlc3RhYmxlIikuDQoNCk5pY29sYSwgTWFyY28sIGlzIGl0IG9rIHRv
IGFkZCB5b3VyIHR3byBuYW1lcyBpbiB0aGUgc2lnbm9mZiBwYXJ0Pw0KKHRo
YXQgd2FzIGEgdmVyYmFsIHRhbGssIEkgZG9uJ3QgaGF2ZSBhbnl0aGluZyB3
cml0dGVuKQ0KDQpHaWFuZnJhbmNvDQoKQ29uZmlkZW50aWFsaXR5IE5vdGlj
ZTogVGhpcyBtZXNzYWdlIChpbmNsdWRpbmcgYXR0YWNobWVudHMpIGlzIGEg
cHJpdmF0ZSBjb21tdW5pY2F0aW9uIHNvbGVseQ0KZm9yIHVzZSBvZiB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50KHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
ZW5kZWQgcmVjaXBpZW50KHMpIG9yIGJlbGlldmUgeW91DQpyZWNlaXZlZCB0
aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk
aWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSB0aGlzIG1lc3NhZ2UuIEFueQ0Kb3Ro
ZXIgdXNlLCByZXRlbnRpb24sIGRpc3NlbWluYXRpb24gb3IgY29weWluZyBp
cyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgYSB2aW9sYXRpb24gb2YgbGF3LA0K
aW5jbHVkaW5nIHRoZSBFbGVjdHJvbmljIENvbW11bmljYXRpb24gUHJpdmFj
eSBBY3Qgb2YgMTk4Ni4=
^ permalink raw reply
* R: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value
From: Arlone Marco @ 2016-11-15 13:21 UTC (permalink / raw)
To: 'Nicola Smaldone', Gianfranco Costamagna, Kalle Valo
Cc: Arend Van Spriel, brcm80211-dev-list@broadcom.com,
linux-wireless@vger.kernel.org
In-Reply-To: <8947AB956BCA3E4E9A143D07C3F63F22D6A0B215@LIV-EXCHMBX1.TOPCON.com>
Tm8gcHJvYmxlbSBmb3IgbWUsIGFsc28uDQoNCk1hcmNvIEFybG9uZQ0KDQotLS0tLU1lc3Nh
Z2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IE5pY29sYSBTbWFsZG9uZSBbbWFpbHRvOm5zbWFs
ZG9uZUB0aWVycmF0ZWxlbWF0aWNzLmNvbV0gDQpJbnZpYXRvOiBtYXJ0ZWTDrCAxNSBub3Zl
bWJyZSAyMDE2IDE0OjE4DQpBOiBHaWFuZnJhbmNvIENvc3RhbWFnbmE7IEthbGxlIFZhbG8N
CkNjOiBBcmVuZCBWYW4gU3ByaWVsOyBicmNtODAyMTEtZGV2LWxpc3RAYnJvYWRjb20uY29t
OyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IEFybG9uZSBNYXJjbw0KT2dnZXR0
bzogUkU6IFtQQVRDSF0gYnJvYWRjb20vYnJjbTgwMjExL2JyY21mbWFjL2NmZzgwMjExIGRy
aXZlciwgYmFkIHJlZ3VsYXRvcnkgZG9tYWluIGZyZXF1ZW5jeSB2YWx1ZQ0KDQpObyBwcm9i
bGVtIGZvciBtZSwgdGhhbmtzLg0KDQpOaWNvbGEgU01BTERPTkUNCnd3dy50aWVycmF0ZWxl
bWF0aWNzLmNvbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogR2lhbmZy
YW5jbyBDb3N0YW1hZ25hIFttYWlsdG86bG9jdXR1c29mYm9yZ0BkZWJpYW4ub3JnXQ0KU2Vu
dDogbWFydGVkw6wgMTUgbm92ZW1icmUgMjAxNiAxNDoxNA0KVG86IEthbGxlIFZhbG8gPGt2
YWxvQGNvZGVhdXJvcmEub3JnPg0KQ2M6IEFyZW5kIFZhbiBTcHJpZWwgPGFyZW5kLnZhbnNw
cmllbEBicm9hZGNvbS5jb20+OyBicmNtODAyMTEtZGV2LWxpc3RAYnJvYWRjb20uY29tOyBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE5pY29sYSBTbWFsZG9uZSA8bnNtYWxk
b25lQHRpZXJyYXRlbGVtYXRpY3MuY29tPjsgTWFyY28uQXJsb25lQHJvai5jb20NClN1Ympl
Y3Q6IFJlOiBbUEFUQ0hdIGJyb2FkY29tL2JyY204MDIxMS9icmNtZm1hYy9jZmc4MDIxMSBk
cml2ZXIsIGJhZCByZWd1bGF0b3J5IGRvbWFpbiBmcmVxdWVuY3kgdmFsdWUNCg0KSGksDQoN
Cg0KPiBTaWduZWQtb2ZmLWJ5OiBOaWNvbGEgU21hbGRvbmUgPG5pY29sYS5zbWFsZG9uZUB0
aWVycmFzZXJ2aWNlLmNvbT4NCg0KPiBTaWduZWQtb2ZmLWJ5OiBBcmxvbmUgTWFyY28gPG1h
cmNvLmFybG9uZUByb2ouY29tPg0KDQo+UGxlYXNlIG5vdGUgdGhhdCB5b3UgY2Fubm90IGFk
ZCBTaWduZWQtb2ZmLWJ5IGZvciBvdGhlciBwZW9wbGUgd2l0aG91dCANCj50aGVpciBleHBs
aWNpdCBhcHByb3ZhbCAoc2VlIERvY3VtZW50YXRpb24vU3VibWl0dGluZ1BhdGNoZXMpLiBJ
IGRvbid0IA0KPmtub3cgaWYgdGhleSBkaWQgaXQgaW4gdGhpcyBjYXNlIG9yIG5vdCwgYnV0
IHdhbnRlZCB0byBwb2ludCBvdXQgdGhpcyANCj5hbnl3YXkuDQoNCg0KVGhlIGZpcnN0IHNp
Z25vZmYgaXMgbXlzZWxmLCB3aXRoIHRoZSBjb21wYW55IGVtYWlsLCB0aGUgb3RoZXIgdHdv
IHNpZ25vZmZzIGFyZSBmcm9tOiB0aGUgYXV0aG9yLCBhbmQgTmljb2xhLCB3aG8gZGlkIHdv
cmsgd2l0aCBtZSB0byB0ZXN0IGl0IChldmVuIGlmIGEgdHlwbyBmaXggaXMgbm90ICJ0ZXN0
YWJsZSIpLg0KDQpOaWNvbGEsIE1hcmNvLCBpcyBpdCBvayB0byBhZGQgeW91ciB0d28gbmFt
ZXMgaW4gdGhlIHNpZ25vZmYgcGFydD8NCih0aGF0IHdhcyBhIHZlcmJhbCB0YWxrLCBJIGRv
bid0IGhhdmUgYW55dGhpbmcgd3JpdHRlbikNCg0KR2lhbmZyYW5jbw0KDQpDb25maWRlbnRp
YWxpdHkgTm90aWNlOiBUaGlzIG1lc3NhZ2UgKGluY2x1ZGluZyBhdHRhY2htZW50cykgaXMg
YSBwcml2YXRlIGNvbW11bmljYXRpb24gc29sZWx5IGZvciB1c2Ugb2YgdGhlIGludGVuZGVk
IHJlY2lwaWVudChzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChz
KSBvciBiZWxpZXZlIHlvdSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIG5vdGlm
eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSB0aGlzIG1lc3NhZ2Uu
IEFueSBvdGhlciB1c2UsIHJldGVudGlvbiwgZGlzc2VtaW5hdGlvbiBvciBjb3B5aW5nIGlz
IHByb2hpYml0ZWQgYW5kIG1heSBiZSBhIHZpb2xhdGlvbiBvZiBsYXcsIGluY2x1ZGluZyB0
aGUgRWxlY3Ryb25pYyBDb21tdW5pY2F0aW9uIFByaXZhY3kgQWN0IG9mIDE5ODYuDQoNCkZv
bGxvdyB1cyBvbiBZb3VUdWJlOiBodHRwczovL3d3dy55b3V0dWJlLmNvbS9jaGFubmVsL1VD
OW5US2plcThVZHhFeEtuQ05YRFBtQQ0KDQpQcmltYSBkaSBzdGFtcGFyZSwgcGVuc2EgYWxs
J2FtYmllbnRlICoqIFRoaW5rIGFib3V0IHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRp
bmcNCg0KDQpST0ogUy5yLmwuIC0gQmllbGxhIC0gSXRhbHkgICh3d3cucm9qLmNvbSkgDQpU
ZWw6ICszOS4wMTUuODQ4MDExMSAgIEZheDogKzM5LjAxNS40MDU4MTUvODQ4MDIwOQ0KDQpU
aGlzIGUtbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgaXMgY29uZmlk
ZW50aWFsIGFuZCBpbnRlbmRlZCBvbmx5IGZvciB0aGUgc3RhdGVkIGFkZHJlc3NlZShzKS4g
QW55IHVuYXV0aG9yaXNlZCBkaXNjbG9zdXJlLCB1c2Ugb3IgZGlzc2VtaW5hdGlvbiwgZWl0
aGVyIHdob2xlIG9yIHBhcnRpYWwsIGJ5IHBlcnNvbiBvciBlbnRpdGllcyBvdGhlciB0aGFu
IHRoZSBhZGRyZXNzZWUocykgaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBpZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUt
bWFpbCBieSBtaXN0YWtlIGFuZCBkZWxldGUgdGhpcyBlLW1haWwgZnJvbSB5b3VyIHN5c3Rl
bS4gDQpQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQg
aW4gdGhpcyBlLW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBhcmUg
bm90IG5lY2Vzc2FyaWx5IGVuZG9yc2VkIGJ5IHRoZSBjb21wYW55LiBBbHRob3VnaCB0aGUg
Y29tcGFueSBoYXMgdGFrZW4gcmVhc29uYWJsZSBwcmVjYXV0aW9ucyB0byBlbnN1cmUgbm8g
dmlydXNlcyBhcmUgcHJlc2VudCBpbiB0aGlzIGUtbWFpbCwgdGhlIGNvbXBhbnkgY2Fubm90
IGFjY2VwdCByZXNwb25zaWJpbGl0eSBmb3IgYW55IGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcg
ZnJvbSB0aGUgdXNlIG9mIHRoaXMgZS1tYWlsIG9yIGF0dGFjaG1lbnRzLiANCg0K
^ permalink raw reply
* [PATCH v4 1/3] mwifiex: Allow mwifiex early access to device structure
From: Amitkumar Karwar @ 2016-11-15 13:36 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
From: Rajat Jain <rajatja@google.com>
Today all the interface drivers (usb/pcie/sdio) assign the
adapter->dev in the register_dev() callback, although they
have this piece of info well before hand.
This patch makes the device structure available for mwifiex
right at the beginning, so that it can be used for early
initialization if needed.
This is needed for subsequent patches in this patchset that
intend to unify and consolidate some of the code that would
otherwise have to be duplicated among the interface drivers
(sdio, pcie, usb).
Signed-off-by: Rajat Jain <rajatja@google.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Same as v1
v3: Fixed checkpatch warnings
WARNING: function definition argument 'void *' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
WARNING: function definition argument 'struct semaphore *' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
WARNING: function definition argument 'struct mwifiex_if_ops *' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
WARNING: function definition argument 'u8' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
WARNING: function definition argument 'struct device *' should also have an identifier name
#59: FILE: drivers/net/wireless/marvell/mwifiex/main.h:1415:
+int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8,
v4: Rebase v3 on top of "[v7] mwifiex: parse device tree node for PCIe"
---
drivers/net/wireless/marvell/mwifiex/main.c | 4 +++-
drivers/net/wireless/marvell/mwifiex/main.h | 4 +++-
drivers/net/wireless/marvell/mwifiex/pcie.c | 4 +---
drivers/net/wireless/marvell/mwifiex/sdio.c | 5 +----
drivers/net/wireless/marvell/mwifiex/usb.c | 3 +--
5 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 2478ccd..dcceab2 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1567,7 +1567,8 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
*/
int
mwifiex_add_card(void *card, struct semaphore *sem,
- struct mwifiex_if_ops *if_ops, u8 iface_type)
+ struct mwifiex_if_ops *if_ops, u8 iface_type,
+ struct device *dev)
{
struct mwifiex_adapter *adapter;
@@ -1579,6 +1580,7 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
goto err_init_sw;
}
+ adapter->dev = dev;
adapter->iface_type = iface_type;
adapter->card_sem = sem;
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index d61fe3a..549e1ba 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1412,7 +1412,9 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
u32 func_init_shutdown);
-int mwifiex_add_card(void *, struct semaphore *, struct mwifiex_if_ops *, u8);
+int mwifiex_add_card(void *card, struct semaphore *sem,
+ struct mwifiex_if_ops *if_ops, u8 iface_type,
+ struct device *dev);
int mwifiex_remove_card(struct mwifiex_adapter *, struct semaphore *);
void mwifiex_get_version(struct mwifiex_adapter *adapter, char *version,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 83a41b5..745ecd6 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -231,7 +231,7 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
}
if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
- MWIFIEX_PCIE)) {
+ MWIFIEX_PCIE, &pdev->dev)) {
pr_err("%s failed\n", __func__);
return -1;
}
@@ -2995,11 +2995,9 @@ static void mwifiex_pcie_get_fw_name(struct mwifiex_adapter *adapter)
static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
- struct pci_dev *pdev = card->dev;
/* save adapter pointer in card */
card->adapter = adapter;
- adapter->dev = &pdev->dev;
if (mwifiex_pcie_request_irq(adapter))
return -1;
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 807af13..c95f41f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -206,7 +206,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
ret = mwifiex_add_card(card, &add_remove_card_sem, &sdio_ops,
- MWIFIEX_SDIO);
+ MWIFIEX_SDIO, &func->dev);
if (ret) {
dev_err(&func->dev, "add card failed\n");
goto err_disable;
@@ -2106,9 +2106,6 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
return ret;
}
-
- adapter->dev = &func->dev;
-
strcpy(adapter->fw_name, card->firmware);
if (card->fw_dump_enh) {
adapter->mem_type_mapping_tbl = generic_mem_type_map;
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index 73eb084..f847fff 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -476,7 +476,7 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
usb_set_intfdata(intf, card);
ret = mwifiex_add_card(card, &add_remove_card_sem, &usb_ops,
- MWIFIEX_USB);
+ MWIFIEX_USB, &card->udev->dev);
if (ret) {
pr_err("%s: mwifiex_add_card failed: %d\n", __func__, ret);
usb_reset_device(udev);
@@ -932,7 +932,6 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
struct usb_card_rec *card = (struct usb_card_rec *)adapter->card;
card->adapter = adapter;
- adapter->dev = &card->udev->dev;
switch (le16_to_cpu(card->udev->descriptor.idProduct)) {
case USB8997_PID_1:
--
1.9.1
^ permalink raw reply related
* [PATCH v4 2/3] mwifiex: Introduce mwifiex_probe_of() to parse common properties
From: Amitkumar Karwar @ 2016-11-15 13:36 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
In-Reply-To: <1479216964-3328-1-git-send-email-akarwar@marvell.com>
From: Rajat Jain <rajatja@google.com>
Introduce function mwifiex_probe_of() to parse common properties.
Interface drivers get to decide whether or not the device tree node
was a valid one (depending on the compatible property),
Lets fill "adapter->dt_node" in mwifiex_add_card().
The function mwifiex_probe_of() is currently only a place holder with
the next patch adding content to it.
Signed-off-by: Rajat Jain <rajatja@google.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Same as v1
v3: Redundant flag "of_node_valid" is removed (Brian)
v4: Same as v3
---
drivers/net/wireless/marvell/mwifiex/main.c | 12 ++++++++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 5 +----
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index dcceab2..835d330 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1552,6 +1552,16 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
}
EXPORT_SYMBOL_GPL(mwifiex_do_flr);
+static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
+{
+ struct device *dev = adapter->dev;
+
+ if (!dev->of_node)
+ return;
+
+ adapter->dt_node = dev->of_node;
+}
+
/*
* This function adds the card.
*
@@ -1581,6 +1591,8 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
}
adapter->dev = dev;
+ mwifiex_probe_of(adapter);
+
adapter->iface_type = iface_type;
adapter->card_sem = sem;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index b697b61..bcd6408 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2235,10 +2235,7 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
* The cal-data can be read from device tree and/or
* a configuration file and downloaded to firmware.
*/
- if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
- priv->adapter->iface_type == MWIFIEX_PCIE) &&
- adapter->dev->of_node) {
- adapter->dt_node = adapter->dev->of_node;
+ if (adapter->dt_node) {
if (of_property_read_u32(adapter->dt_node,
"marvell,wakeup-pin",
&data) == 0) {
--
1.9.1
^ permalink raw reply related
* [PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie
From: Amitkumar Karwar @ 2016-11-15 13:36 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov
In-Reply-To: <1479216964-3328-1-git-send-email-akarwar@marvell.com>
From: Rajat Jain <rajatja@google.com>
Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt
support") added WoWLAN feature only for sdio. This patch moves that
code to the common module so that all the interface drivers can use
it for free. It enables pcie and sdio for its use currently.
Signed-off-by: Rajat Jain <rajatja@google.com>
---
v2: v1 doesn't apply smoothly on latest code due to recently merged
patch "mwifiex: report error to PCIe for suspend failure". Minor
conflict is resolved in v2
v4: Same as v2, v3
---
drivers/net/wireless/marvell/mwifiex/main.c | 41 ++++++++++++++++
drivers/net/wireless/marvell/mwifiex/main.h | 25 ++++++++++
drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 72 ++---------------------------
drivers/net/wireless/marvell/mwifiex/sdio.h | 8 ----
5 files changed, 73 insertions(+), 75 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 835d330..948f5c2 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1552,14 +1552,55 @@ void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
}
EXPORT_SYMBOL_GPL(mwifiex_do_flr);
+static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
+{
+ struct mwifiex_adapter *adapter = priv;
+
+ if (adapter->irq_wakeup >= 0) {
+ dev_dbg(adapter->dev, "%s: wake by wifi", __func__);
+ adapter->wake_by_wifi = true;
+ disable_irq_nosync(irq);
+ }
+
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(adapter->dev, 0);
+
+ return IRQ_HANDLED;
+}
+
static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
{
+ int ret;
struct device *dev = adapter->dev;
if (!dev->of_node)
return;
adapter->dt_node = dev->of_node;
+ adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
+ if (!adapter->irq_wakeup) {
+ dev_info(dev, "fail to parse irq_wakeup from device tree\n");
+ return;
+ }
+
+ ret = devm_request_irq(dev, adapter->irq_wakeup,
+ mwifiex_irq_wakeup_handler, IRQF_TRIGGER_LOW,
+ "wifi_wake", adapter);
+ if (ret) {
+ dev_err(dev, "Failed to request irq_wakeup %d (%d)\n",
+ adapter->irq_wakeup, ret);
+ goto err_exit;
+ }
+
+ disable_irq(adapter->irq_wakeup);
+ if (device_init_wakeup(dev, true)) {
+ dev_err(dev, "fail to init wakeup for mwifiex\n");
+ goto err_exit;
+ }
+ return;
+
+err_exit:
+ adapter->irq_wakeup = 0;
}
/*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 549e1ba..ae5afe5 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1011,6 +1011,10 @@ struct mwifiex_adapter {
bool usb_mc_setup;
struct cfg80211_wowlan_nd_info *nd_info;
struct ieee80211_regdomain *regd;
+
+ /* Wake-on-WLAN (WoWLAN) */
+ int irq_wakeup;
+ bool wake_by_wifi;
};
void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
@@ -1410,6 +1414,27 @@ static inline u8 mwifiex_is_tdls_link_setup(u8 status)
return false;
}
+/* Disable platform specific wakeup interrupt */
+static inline void mwifiex_disable_wake(struct mwifiex_adapter *adapter)
+{
+ if (adapter->irq_wakeup >= 0) {
+ disable_irq_wake(adapter->irq_wakeup);
+ if (!adapter->wake_by_wifi)
+ disable_irq(adapter->irq_wakeup);
+ }
+}
+
+/* Enable platform specific wakeup interrupt */
+static inline void mwifiex_enable_wake(struct mwifiex_adapter *adapter)
+{
+ /* Enable platform specific wakeup interrupt */
+ if (adapter->irq_wakeup >= 0) {
+ adapter->wake_by_wifi = false;
+ enable_irq(adapter->irq_wakeup);
+ enable_irq_wake(adapter->irq_wakeup);
+ }
+}
+
int mwifiex_init_shutdown_fw(struct mwifiex_private *priv,
u32 func_init_shutdown);
int mwifiex_add_card(void *card, struct semaphore *sem,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 745ecd6..e8f4f90 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -131,6 +131,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
}
adapter = card->adapter;
+ mwifiex_enable_wake(adapter);
/* Enable the Host Sleep */
if (!mwifiex_enable_hs(adapter)) {
@@ -186,6 +187,7 @@ static int mwifiex_pcie_resume(struct device *dev)
mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
MWIFIEX_ASYNC_CMD);
+ mwifiex_disable_wake(adapter);
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index c95f41f..7055282 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -79,67 +79,18 @@
{ }
};
-static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
-{
- struct mwifiex_plt_wake_cfg *cfg = priv;
-
- if (cfg->irq_wifi >= 0) {
- pr_info("%s: wake by wifi", __func__);
- cfg->wake_by_wifi = true;
- disable_irq_nosync(irq);
- }
-
- /* Notify PM core we are wakeup source */
- pm_wakeup_event(cfg->dev, 0);
-
- return IRQ_HANDLED;
-}
-
/* This function parse device tree node using mmc subnode devicetree API.
* The device node is saved in card->plt_of_node.
* if the device tree node exist and include interrupts attributes, this
* function will also request platform specific wakeup interrupt.
*/
-static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
+static int mwifiex_sdio_probe_of(struct device *dev)
{
- struct mwifiex_plt_wake_cfg *cfg;
- int ret;
-
if (!of_match_node(mwifiex_sdio_of_match_table, dev->of_node)) {
dev_err(dev, "required compatible string missing\n");
return -EINVAL;
}
- card->plt_of_node = dev->of_node;
- card->plt_wake_cfg = devm_kzalloc(dev, sizeof(*card->plt_wake_cfg),
- 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,
- "fail to parse irq_wifi from device tree\n");
- } else {
- ret = devm_request_irq(dev, cfg->irq_wifi,
- mwifiex_wake_irq_wifi,
- IRQF_TRIGGER_LOW,
- "wifi_wake", cfg);
- if (ret) {
- dev_dbg(dev,
- "Failed to request irq_wifi %d (%d)\n",
- cfg->irq_wifi, ret);
- card->plt_wake_cfg = NULL;
- return 0;
- }
- disable_irq(cfg->irq_wifi);
- }
- }
-
- ret = device_init_wakeup(dev, true);
- if (ret)
- dev_err(dev, "fail to init wakeup for mwifiex");
-
return 0;
}
@@ -198,11 +149,9 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
/* device tree node parsing and platform specific configuration*/
if (func->dev.of_node) {
- ret = mwifiex_sdio_probe_of(&func->dev, card);
- if (ret) {
- dev_err(&func->dev, "SDIO dt node parse failed\n");
+ ret = mwifiex_sdio_probe_of(&func->dev);
+ if (ret)
goto err_disable;
- }
}
ret = mwifiex_add_card(card, &add_remove_card_sem, &sdio_ops,
@@ -267,12 +216,7 @@ static int mwifiex_sdio_resume(struct device *dev)
mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
MWIFIEX_SYNC_CMD);
- /* Disable platform specific wakeup interrupt */
- if (card->plt_wake_cfg && card->plt_wake_cfg->irq_wifi >= 0) {
- disable_irq_wake(card->plt_wake_cfg->irq_wifi);
- if (!card->plt_wake_cfg->wake_by_wifi)
- disable_irq(card->plt_wake_cfg->irq_wifi);
- }
+ mwifiex_disable_wake(adapter);
return 0;
}
@@ -352,13 +296,7 @@ static int mwifiex_sdio_suspend(struct device *dev)
}
adapter = card->adapter;
-
- /* Enable platform specific wakeup interrupt */
- if (card->plt_wake_cfg && card->plt_wake_cfg->irq_wifi >= 0) {
- card->plt_wake_cfg->wake_by_wifi = false;
- enable_irq(card->plt_wake_cfg->irq_wifi);
- enable_irq_wake(card->plt_wake_cfg->irq_wifi);
- }
+ mwifiex_enable_wake(adapter);
/* Enable the Host Sleep */
if (!mwifiex_enable_hs(adapter)) {
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index 07cdd23..b9fbc5c 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -154,12 +154,6 @@
a->mpa_rx.start_port = 0; \
} while (0)
-struct mwifiex_plt_wake_cfg {
- struct device *dev;
- int irq_wifi;
- bool wake_by_wifi;
-};
-
/* data structure for SDIO MPA TX */
struct mwifiex_sdio_mpa_tx {
/* multiport tx aggregation buffer pointer */
@@ -243,8 +237,6 @@ struct mwifiex_sdio_card_reg {
struct sdio_mmc_card {
struct sdio_func *func;
struct mwifiex_adapter *adapter;
- struct device_node *plt_of_node;
- struct mwifiex_plt_wake_cfg *plt_wake_cfg;
const char *firmware;
const struct mwifiex_sdio_card_reg *reg;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/3] mac80211: update A-MPDU flag on tx dequeue
From: Johannes Berg @ 2016-11-15 13:38 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: toke
In-Reply-To: <20161104092754.91649-1-nbd@nbd.name>
All three applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 3/4] dt: bindings: add new dt entry for BTCOEX feature in qcom, ath10k.txt
From: Valo, Kalle @ 2016-11-15 13:39 UTC (permalink / raw)
To: Raja, Tamizh Chelvam
Cc: ath10k@lists.infradead.org, tamizhchelvam@codeaurora.org,
linux-wireless@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <1478617462-28188-1-git-send-email-c_traja@qti.qualcomm.com>
(Adding devicetree list)
<c_traja@qti.qualcomm.com> writes:
> From: Tamizh chelvam <tamizhchelvam@codeaurora.org>
>
> There two things done in this patch.
>
> 1) 'btcoex_support' flag for BTCOEX feature support by the hardware.
> 2) 'wlan_btcoex_gpio' is used to fill wlan priority pin number for
> BTCOEX priority feature support.
>
> Signed-off-by: Tamizh chelvam <tamizhchelvam@codeaurora.org>
> ---
> .../bindings/net/wireless/qcom,ath10k.txt | 4 ++++
> 1 file changed, 4 insertions(+)
As this changes the device tree bindings you need to CC the device tree
list. Please resend the whole patchset (and mark it as v2).
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] fixed hwsim beacon delta calculation
From: Johannes Berg @ 2016-11-15 13:42 UTC (permalink / raw)
To: Benjamin Beichler, linux-wireless
In-Reply-To: <980aa1f8-42c3-4fe4-a930-d930474ad2eb@MAIL1.uni-rostock.de>
On Fri, 2016-11-11 at 17:37 +0100, Benjamin Beichler wrote:
> Due to the cast from uint32_t to int64_t, a wrong next beacon timing
> is
> calculated and effectively the beacon timer stops to work. This is
> especially bad for 802.11s mesh networks, because discovery breaks
> without beacons.
>
Applied. Please note how I changed the commit subject, and use that
scheme in the future.
johannes
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Valo, Kalle @ 2016-11-15 13:43 UTC (permalink / raw)
To: Bruno Antunes
Cc: OpenWrt Development List, linux-wireless, voncken,
ath10k@lists.infradead.org
In-Reply-To: <CABUTiXV8eFsW4MJET4spvjVQvFgi66NV7hLLxFC6Ttqs1znxjA@mail.gmail.com>
Bruno Antunes <baantunes@gmail.com> writes:
> On 7 November 2016 at 18:06, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>> Bruno Antunes <baantunes@gmail.com> writes:
>>
>>> On 4 November 2016 at 21:17, Valo, Kalle <kvalo@qca.qualcomm.com> wrote=
:
>>>
>>>> Can someone file a bug to bugzilla about this so that all the info is
>>>> properly stored? The more comprehensive the report is the better.
>>>>
>>>> https://bugzilla.kernel.org/
>>>
>>> I will file a bug report.
>>
>> Thanks, it's good to store all in one place so that it's easier to find
>> the relevant info.
>
> Just file the bug with the ID 187241 - VLAN support in ATH10k Feel
> free to ask for adicional info. I did not mention any names in the bug
> report fell free to take credit if wanted.
Thanks. I'll report it to the firmware team, let's see what happens. If
there's more information which might help to fix this feel free to
update that to the bug report.
https://bugzilla.kernel.org/show_bug.cgi?id=3D187241
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value
From: Kalle Valo @ 2016-11-15 13:52 UTC (permalink / raw)
To: Gianfranco Costamagna
Cc: Arend Van Spriel, brcm80211-dev-list@broadcom.com,
linux-wireless@vger.kernel.org, nsmaldone@tierratelematics.com,
Marco.Arlone@roj.com
In-Reply-To: <1967239621.630327.1479215628178@mail.yahoo.com>
Gianfranco Costamagna <locutusofborg@debian.org> writes:
>> Signed-off-by: Nicola Smaldone <nicola.smaldone@tierraservice.com>
>
>> Signed-off-by: Arlone Marco <marco.arlone@roj.com>
>
>>Please note that you cannot add Signed-off-by for other people without
>>their explicit approval (see Documentation/SubmittingPatches). I don't
>>know if they did it in this case or not, but wanted to point out this
>>anyway.
>
>
> The first signoff is myself, with the company email, the other two signoffs
> are from: the author, and Nicola, who did work with me to test it
> (even if a typo fix is not "testable").
>
> Nicola, Marco, is it ok to add your two names in the signoff part?
> (that was a verbal talk, I don't have anything written)
Good, so we got now approvals from both of them. Thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCHv2,1/2] ath10k: add per peer htt tx stats support for 10.4
From: Kalle Valo @ 2016-11-15 14:36 UTC (permalink / raw)
To: akolli; +Cc: ath10k, Anilkumar Kolli, akolli, linux-wireless
In-Reply-To: <1476783085-10724-2-git-send-email-akolli@qti.qualcomm.com>
akolli@qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
>
> Parse peer stats and update the tx rate information per STA.
>
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
I see a new sparse warning:
drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17: expected int [signed] peer_id
drivers/net/wireless/ath/ath10k/htt_rx.c:2290:17: got restricted __le16 [usertype] peer_id
2 patches set to Changes Requested.
9381691 [PATCHv2,1/2] ath10k: add per peer htt tx stats support for 10.4
9381693 [PATCHv2,2/2] ath10k: add support for per sta tx bitrate
--
https://patchwork.kernel.org/patch/9381691/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Valo, Kalle @ 2016-11-15 14:49 UTC (permalink / raw)
To: Vittorio Gambaletta (VittGam)
Cc: linux-wireless@vger.kernel.org, ath9k-devel,
ath9k-devel@venema.h4ckr.net, stable@vger.kernel.org
In-Reply-To: <8d77a285e16cdd9f3b79c9e8d8800d72@vittgam.net>
"Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
> Hello,
>
> On 12/10/2016 17:01:08 CEST, Valo, Kalle wrote:
>
>> So to tell the full story I'll change the commit log to something like
>> below. Does it look ok to you?
>
> Yes; but I'd change "So" to "This turned out to be wrong", and add a note
> about changing the order for 0x002A too:
>
> ----------------------------------------------------------------------
> ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.
>
> The active_high LED of my Wistron DNMA-92 is still being recognized as
> active_low on 4.7.6 mainline. When I was preparing my former commit
> 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
> cards.") to fix that I must have somehow messed up with testing, because
> I tested the final version of that patch before sending it, and it was
> apparently working; but now it is not working on 4.7.6 mainline.
>
> I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
> PCI_VDEVICE section for 0x0029; but then I moved the former below the
> latter after seeing how 0x002A sections were sorted in the file.
>
> This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
> both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
> specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
> match first and will be used.
>
> With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
>
> While I'm at it, let's fix 0x002A too by also moving its generic definiti=
on
> below its specific ones.
>
> Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB=
92 cards.")
> Cc: <stable@vger.kernel.org> #4.7+
> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
> [kvalo@qca.qualcomm.com: improve the commit log based on email discussion=
s]
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
> ----------------------------------------------------------------------
Thanks, I updated the commit with your changes.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Bruno Antunes @ 2016-11-15 14:53 UTC (permalink / raw)
To: Valo, Kalle
Cc: OpenWrt Development List, linux-wireless, voncken,
ath10k@lists.infradead.org, Ben Greear
In-Reply-To: <87polwq2nq.fsf@kamboji.qca.qualcomm.com>
On 15 November 2016 at 13:43, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
> Bruno Antunes <baantunes@gmail.com> writes:
>
>> On 7 November 2016 at 18:06, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>>> Bruno Antunes <baantunes@gmail.com> writes:
>>>
>>>> On 4 November 2016 at 21:17, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>>>>
>>>>> Can someone file a bug to bugzilla about this so that all the info is
>>>>> properly stored? The more comprehensive the report is the better.
>>>>>
>>>>> https://bugzilla.kernel.org/
>>>>
>>>> I will file a bug report.
>>>
>>> Thanks, it's good to store all in one place so that it's easier to find
>>> the relevant info.
>>
>> Just file the bug with the ID 187241 - VLAN support in ATH10k Feel
>> free to ask for adicional info. I did not mention any names in the bug
>> report fell free to take credit if wanted.
>
> Thanks. I'll report it to the firmware team, let's see what happens. If
> there's more information which might help to fix this feel free to
> update that to the bug report.
I'm finishing my tests and will update the bug report ASAP.
Turns out the bad throughput was the result of a failure in the switch port.
With Ben's firmware the VLAN support is working fine with security.
Thanks,
Bruno
>
> https://bugzilla.kernel.org/show_bug.cgi?id=187241
>
> --
> Kalle Valo
^ permalink raw reply
* Re: ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Kalle Valo @ 2016-11-15 14:53 UTC (permalink / raw)
To: Vittorio Gambaletta (VittGam); +Cc: kvalo, linux-wireless
In-Reply-To: <ath9k-patch-20161003@vittgam.net>
"Vittorio Gambaletta \(VittGam\)" <linux-wireless@vittgam.net> wrote:
> If generic entries are positioned above specific ones, then the
> former will be matched first and used instead of the latter.
>
> Cc: <linux-wireless@vger.kernel.org>
> Cc: <ath9k-devel@qca.qualcomm.com>
> Cc: <ath9k-devel@lists.ath9k.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -26,7 +26,6 @@
> { PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI */
> { PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
> { PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */
> - { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
>
> #ifdef CONFIG_ATH9K_PCOEM
> /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
> @@ -37,7 +36,7 @@
> .driver_data = ATH9K_PCI_LED_ACT_HI },
> #endif
>
> - { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
> + { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
>
> #ifdef CONFIG_ATH9K_PCOEM
> { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
> @@ -85,7 +84,11 @@
> 0x10CF, /* Fujitsu */
> 0x1536),
> .driver_data = ATH9K_PCI_D3_L1_WAR },
> +#endif
>
> + { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
> +
> +#ifdef CONFIG_ATH9K_PCOEM
> /* AR9285 card for Asus */
> { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
> 0x002B,
Patch applied to ath-next branch of ath.git, thanks.
79e57dd113d3 ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.
--
https://patchwork.kernel.org/patch/9360361/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Ben Greear @ 2016-11-15 14:55 UTC (permalink / raw)
To: voncken; +Cc: linux-wireless, 'OpenWrt Development List', ath10k
In-Reply-To: <001a01d23f4d$cd1df550$6759dff0$@acksys.fr>
The beta-18 release on my web page has the fix and should work fine.
Probably soon I will promote the beta-18 to final release
status. Any help in testing and verifying the beta works well
is welcome.
Thanks,
Ben
On 11/15/2016 06:37 AM, voncken wrote:
> Hi Ben,
>
> Do you plan to release a candelatech firmware with this fix?
>
> Regards.
>
> Cedric Voncken.
>> -----Message d'origine-----
>> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] De la part de Ben Greear
>> Envoyé : samedi 5 novembre 2016 15:35
>> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
>> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
>> Development List; ath10k@lists.infradead.org
>> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>>
>> Looks to me like 10.4 defaults to the right value, but possibly there
>> are other issues with it. I tested my CT 10.4 and it worked OK with
>> vlans for me.
>>
>> Thanks,
>> Ben
>>
>> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
>>> would be good if qca can fix this bug finally in all available
>>> firmwares. its a very annoying issue since a long time
>>>
>>> Sebastian
>>>
>>>
>>> Am 04.11.2016 um 23:23 schrieb Ben Greear:
>>>> The bug appears that vlan-tx-stripping is unconditionally enabled in
>>>> at least my firmware. I have re-compiled w/out that flag set, and
>> it
>>>> appears to work for me.
>>>>
>>>> Please download this firmware, rename it firmware-2.bin, make sure
>>>> you remove/rename any firmware-5.bin (etc) so mine will load, and
>> see if that fixes your problem.
>>>>
>>>> Please note that it is very likely you will have to use same MAC
>>>> address for the VLAN devices that the underlying station uses in
>> order for this to work.
>>>>
>>>> https://www.candelatech.com/downloads/tmp/firmware-2-full-
>> community.b
>>>> in
>>>>
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>>
>>>> On 11/04/2016 02:50 PM, Ben Greear wrote:
>>>>> I can reproduce this in my CT firmware. I'll see if I can fix it,
>>>>> but for stock firmware, it might be that changing the driver to use
>>>>> Ethernet packet type of native-wifi would make .1q vlans work.
>>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
>>>>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>>>>>> I met the same problem before,
>>>>>> if i modify the 1q header to other value (0xaa00) before go into
>> firmware.
>>>>>> I can capture the packet in the air I think the vlan packet is
>>>>>> dropped in firmware.
>>>>>>
>>>>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>>>>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
>> <openwrt@ezplanet.net> wrote:
>>>>>>>> Since the capability is implemented in software you might be
>>>>>>>> testing the limit of your router's CPU i/o speed.
>>>>>>>
>>>>>>> By loading the module in rawmode?
>>>>>>>
>>>>>>> The AP is an APU and Sta is an APU2.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Old thread but I think the issue is still present.
>>>>>>>>>
>>>>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>>>>>>
>>>>>>>>> To make it work both cards must be loaded in rawmode, AP and
>>>>>>>>> Sta, and with no security.
>>>>>>>>>
>>>>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>>>>>>
>>>>>>>>> Although it works the throughput is very bad.
>>>>>>>>> Are there any alternatives to improve the throughput.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Bruno
>>>>>>>>>
>>>>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoyé :
>>>>>>>>>>> mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
>>>>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
>>>>>>>>>>> VLAN firmware issue
>>>>>>>>>>>
>>>>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
>>>>>>>>>>> for you in other cases as well?
>>>>>>>>>>
>>>>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Cedric.
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Ben
>>>>>>>>>>>
>>>>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>>>>>>
>>>>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
>> with eth0.
>>>>>>>>>>>> I have a computer with vlan configuration set connected
>>>>>>>>>>>> to the STA eth0.
>>>>>>>>>>>>
>>>>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
>>>>>>>>>>>> are not
>>>>>>>>>>
>>>>>>>>>> sent.
>>>>>>>>>>>>
>>>>>>>>>>>> I checked with wireless sniffer, and I don't see the
>>>>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
>>>>>>>>>>>>
>>>>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
>>>>>>>>>>>> from openwrt, and in all cases I have the same issue.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your help.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
>>>>>>>>>>> http://www.candelatech.com
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> openwrt-devel mailing list
>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
>> devel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> openwrt-devel mailing list
>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ath10k mailing list
>>>>>>> ath10k@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [v8, 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Kalle Valo @ 2016-11-15 14:56 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, devicetree, linux-wireless, ath9k-devel, robh+dt,
mcgrof, mark.rutland, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20161016205907.19927-2-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Acked-by: Rob Herring <robh@kernel.org>
3 patches applied to ath-next branch of ath.git, thanks.
fc383ffdb91a Documentation: dt: net: add ath9k wireless device binding
b40ded2ad75c ath9k: add a helper to get the string representation of ath_bus_type
138b41253d9c ath9k: parse the device configuration from an OF node
--
https://patchwork.kernel.org/patch/9378317/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k_htc: fix minor mistakes in dev_err messages
From: Kalle Valo @ 2016-11-15 14:58 UTC (permalink / raw)
To: Colin Ian King
Cc: QCA ath9k Development, Kalle Valo, linux-wireless, ath9k-devel,
netdev, linux-kernel
In-Reply-To: <20161031151247.18127-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Add missing space in a dev_err message and join wrapped text so
> it does not span multiple lines. Fix spelling mistake on "unknown".
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to ath-next branch of ath.git, thanks.
14acebc33e6d ath9k_htc: fix minor mistakes in dev_err messages
--
https://patchwork.kernel.org/patch/9405663/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Bruno Antunes @ 2016-11-15 15:00 UTC (permalink / raw)
To: Ben Greear
Cc: voncken, OpenWrt Development List, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <582B21DD.6000306@candelatech.com>
On 15 November 2016 at 14:55, Ben Greear <greearb@candelatech.com> wrote:
> The beta-18 release on my web page has the fix and should work fine.
>
> Probably soon I will promote the beta-18 to final release
> status. Any help in testing and verifying the beta works well
> is welcome.
I will also do testing with that version.
For clarity can I refer you and your firmware releases in the bug report?
Thanks,
Bruno
>
> Thanks,
> Ben
>
> On 11/15/2016 06:37 AM, voncken wrote:
>>
>> Hi Ben,
>>
>> Do you plan to release a candelatech firmware with this fix?
>>
>> Regards.
>>
>> Cedric Voncken.
>>>
>>> -----Message d'origine-----
>>> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>>> owner@vger.kernel.org] De la part de Ben Greear
>>> Envoy=C3=A9 : samedi 5 novembre 2016 15:35
>>> =C3=80 : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
>>> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
>>> Development List; ath10k@lists.infradead.org
>>> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>>>
>>>
>>> Looks to me like 10.4 defaults to the right value, but possibly there
>>> are other issues with it. I tested my CT 10.4 and it worked OK with
>>> vlans for me.
>>>
>>> Thanks,
>>> Ben
>>>
>>> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
>>>>
>>>> would be good if qca can fix this bug finally in all available
>>>> firmwares. its a very annoying issue since a long time
>>>>
>>>> Sebastian
>>>>
>>>>
>>>> Am 04.11.2016 um 23:23 schrieb Ben Greear:
>>>>>
>>>>> The bug appears that vlan-tx-stripping is unconditionally enabled in
>>>>> at least my firmware. I have re-compiled w/out that flag set, and
>>>
>>> it
>>>>>
>>>>> appears to work for me.
>>>>>
>>>>> Please download this firmware, rename it firmware-2.bin, make sure
>>>>> you remove/rename any firmware-5.bin (etc) so mine will load, and
>>>
>>> see if that fixes your problem.
>>>>>
>>>>>
>>>>> Please note that it is very likely you will have to use same MAC
>>>>> address for the VLAN devices that the underlying station uses in
>>>
>>> order for this to work.
>>>>>
>>>>>
>>>>> https://www.candelatech.com/downloads/tmp/firmware-2-full-
>>>
>>> community.b
>>>>>
>>>>> in
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
>>>>>
>>>>> On 11/04/2016 02:50 PM, Ben Greear wrote:
>>>>>>
>>>>>> I can reproduce this in my CT firmware. I'll see if I can fix it,
>>>>>> but for stock firmware, it might be that changing the driver to use
>>>>>> Ethernet packet type of native-wifi would make .1q vlans work.
>>>>>>
>>>>>> Thanks,
>>>>>> Ben
>>>>>>
>>>>>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>>>>>>>
>>>>>>> I met the same problem before,
>>>>>>> if i modify the 1q header to other value (0xaa00) before go into
>>>
>>> firmware.
>>>>>>>
>>>>>>> I can capture the packet in the air I think the vlan packet is
>>>>>>> dropped in firmware.
>>>>>>>
>>>>>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>>>>>>>>
>>>>>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
>>>
>>> <openwrt@ezplanet.net> wrote:
>>>>>>>>>
>>>>>>>>> Since the capability is implemented in software you might be
>>>>>>>>> testing the limit of your router's CPU i/o speed.
>>>>>>>>
>>>>>>>>
>>>>>>>> By loading the module in rawmode?
>>>>>>>>
>>>>>>>> The AP is an APU and Sta is an APU2.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Old thread but I think the issue is still present.
>>>>>>>>>>
>>>>>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>>>>>>>
>>>>>>>>>> To make it work both cards must be loaded in rawmode, AP and
>>>>>>>>>> Sta, and with no security.
>>>>>>>>>>
>>>>>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>>>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>>>>>>>
>>>>>>>>>> Although it works the throughput is very bad.
>>>>>>>>>> Are there any alternatives to improve the throughput.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Bruno
>>>>>>>>>>
>>>>>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
>>>
>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoy=C3=A9 :
>>>>>>>>>>>> mercredi 9 d=C3=A9cembre 2015 16:34 =C3=80 : Cedric VONCKEN;
>>>>>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
>>>>>>>>>>>> VLAN firmware issue
>>>>>>>>>>>>
>>>>>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
>>>>>>>>>>>> for you in other cases as well?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Cedric.
>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ben
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>>>>>>>
>>>>>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
>>>
>>> with eth0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a computer with vlan configuration set connected
>>>>>>>>>>>>> to the STA eth0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
>>>>>>>>>>>>> are not
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> sent.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I checked with wireless sniffer, and I don't see the
>>>>>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
>>>>>>>>>>>>> from openwrt, and in all cases I have the same issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for your help.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
>>>>>>>>>>>> http://www.candelatech.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> openwrt-devel mailing list
>>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
>>>
>>> devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> openwrt-devel mailing list
>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> ath10k mailing list
>>>>>>>> ath10k@lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Ben Greear <greearb@candelatech.com>
>>> Candela Technologies Inc http://www.candelatech.com
>>
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply
* Re: [v6] ath9k: Switch to using mac80211 intermediate software queues.
From: Kalle Valo @ 2016-11-15 15:00 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: make-wifi-fast, linux-wireless, Toke Høiland-Jørgensen,
Tim Shepard, Felix Fietkau
In-Reply-To: <20161109113149.5724-1-toke@toke.dk>
Toke Høiland-Jørgensen wrote:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
>
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
>
> The mac80211 intermediate software queues offer significant latency
> reductions, and this patch allows ath9k to realise them. The exact gains
> from this varies with the test scenario, but in an access point scenario
> we have seen latency reductions ranging from 1/3 to as much as an order
> of magnitude. We also achieve slightly better aggregation.
>
> Median latency (ping) figures with this patch applied at the access point,
> with two high-rate stations and one low-rate station (HT20 5Ghz), running
> a Flent rtt_fair_var_up test with one TCP flow and one ping flow going to
> each station:
>
> Fast station Slow station
> Default pfifo_fast qdisc: 430.4 ms 638.7 ms
> fq_codel qdisc on iface: 35.5 ms 211.8 ms
> This patch set: 22.4 ms 38.2 ms
>
> Median aggregation sizes over the same test:
>
> Default pfifo_fast qdisc: 9.5 pkts 1.9 pkts
> fq_codel qdisc on iface: 11.2 pkts 1.9 pkts
> This patch set: 13.9 pkts 1.9 pkts
>
> This patch is based on Tim's original patch set, but reworked quite
> thoroughly.
>
> Cc: Tim Shepard <shep@alum.mit.edu>
> Cc: Felix Fietkau <nbd@nbd.name>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Patch applied to ath-next branch of ath.git, thanks.
50f08edf9809 ath9k: Switch to using mac80211 intermediate software queues.
--
https://patchwork.kernel.org/patch/9419029/
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 failure to send NULL func frame for 10.4
From: Kalle Valo @ 2016-11-15 15:04 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1476257342-3241-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> This partially reverts 'commit 2cdce425aa33
> ("ath10k: Fix broken NULL func data frame status for 10.4")'
> Unfortunately this breaks sending NULL func and the existing
> issue of obtaining proper tx status for NULL function will be
> fixed. Also update the comments for feature flag added to be
> useless and not working
>
> Fixes: 2cdce425aa33 "ath10k: Fix broken NULL func data frame status for
> 10.4"
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
fcf7cf1551ca ath10k: fix failure to send NULL func frame for 10.4
--
https://patchwork.kernel.org/patch/9372171/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3,1/2] ath10k: clean up HTT tx buffer allocation and free
From: Kalle Valo @ 2016-11-15 15:06 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1476278778-4253-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> cleanup 'ath10k_htt_tx_alloc' by introducing the API's
> 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
> re-use them whereever needed
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
2 patches applied to ath-next branch of ath.git, thanks.
19f338c6eb0c ath10k: clean up HTT tx buffer allocation and free
f004e532a80a ath10k: remove extraneous error message in tx alloc
--
https://patchwork.kernel.org/patch/9373055/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Ben Greear @ 2016-11-15 15:06 UTC (permalink / raw)
To: Bruno Antunes
Cc: voncken, OpenWrt Development List, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <CABUTiXWRkzyV_ic02pUTHG8TbzQUOOYj0L35wMYFcBRgssG0eA@mail.gmail.com>
On 11/15/2016 07:00 AM, Bruno Antunes wrote:
> On 15 November 2016 at 14:55, Ben Greear <greearb@candelatech.com> wrote:
>> The beta-18 release on my web page has the fix and should work fine.
>>
>> Probably soon I will promote the beta-18 to final release
>> status. Any help in testing and verifying the beta works well
>> is welcome.
>
> I will also do testing with that version.
>
> For clarity can I refer you and your firmware releases in the bug report?
It is fine by me. It is a one-line patch to fix the firmware...QCA
can ask me as well if they don't figure it out on their own.
Thanks,
Ben
>
> Thanks,
> Bruno
>>
>> Thanks,
>> Ben
>>
>> On 11/15/2016 06:37 AM, voncken wrote:
>>>
>>> Hi Ben,
>>>
>>> Do you plan to release a candelatech firmware with this fix?
>>>
>>> Regards.
>>>
>>> Cedric Voncken.
>>>>
>>>> -----Message d'origine-----
>>>> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>>>> owner@vger.kernel.org] De la part de Ben Greear
>>>> Envoyé : samedi 5 novembre 2016 15:35
>>>> À : Sebastian Gottschall; yu-chieh kung; Bruno Antunes
>>>> Cc : Mauro Mozzarelli; linux-wireless@vger.kernel.org; OpenWrt
>>>> Development List; ath10k@lists.infradead.org
>>>> Objet : Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
>>>>
>>>>
>>>> Looks to me like 10.4 defaults to the right value, but possibly there
>>>> are other issues with it. I tested my CT 10.4 and it worked OK with
>>>> vlans for me.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>> On 11/05/2016 01:05 AM, Sebastian Gottschall wrote:
>>>>>
>>>>> would be good if qca can fix this bug finally in all available
>>>>> firmwares. its a very annoying issue since a long time
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>> Am 04.11.2016 um 23:23 schrieb Ben Greear:
>>>>>>
>>>>>> The bug appears that vlan-tx-stripping is unconditionally enabled in
>>>>>> at least my firmware. I have re-compiled w/out that flag set, and
>>>>
>>>> it
>>>>>>
>>>>>> appears to work for me.
>>>>>>
>>>>>> Please download this firmware, rename it firmware-2.bin, make sure
>>>>>> you remove/rename any firmware-5.bin (etc) so mine will load, and
>>>>
>>>> see if that fixes your problem.
>>>>>>
>>>>>>
>>>>>> Please note that it is very likely you will have to use same MAC
>>>>>> address for the VLAN devices that the underlying station uses in
>>>>
>>>> order for this to work.
>>>>>>
>>>>>>
>>>>>> https://www.candelatech.com/downloads/tmp/firmware-2-full-
>>>>
>>>> community.b
>>>>>>
>>>>>> in
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Ben
>>>>>>
>>>>>>
>>>>>> On 11/04/2016 02:50 PM, Ben Greear wrote:
>>>>>>>
>>>>>>> I can reproduce this in my CT firmware. I'll see if I can fix it,
>>>>>>> but for stock firmware, it might be that changing the driver to use
>>>>>>> Ethernet packet type of native-wifi would make .1q vlans work.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ben
>>>>>>>
>>>>>>> On 11/04/2016 10:28 AM, yu-chieh kung wrote:
>>>>>>>>
>>>>>>>> I met the same problem before,
>>>>>>>> if i modify the 1q header to other value (0xaa00) before go into
>>>>
>>>> firmware.
>>>>>>>>
>>>>>>>> I can capture the packet in the air I think the vlan packet is
>>>>>>>> dropped in firmware.
>>>>>>>>
>>>>>>>> 2016-11-04 22:41 GMT+08:00 Bruno Antunes <baantunes@gmail.com>:
>>>>>>>>>
>>>>>>>>> On 4 November 2016 at 14:18, Mauro Mozzarelli
>>>>
>>>> <openwrt@ezplanet.net> wrote:
>>>>>>>>>>
>>>>>>>>>> Since the capability is implemented in software you might be
>>>>>>>>>> testing the limit of your router's CPU i/o speed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By loading the module in rawmode?
>>>>>>>>>
>>>>>>>>> The AP is an APU and Sta is an APU2.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 04/11/16 14:13, Bruno Antunes wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Old thread but I think the issue is still present.
>>>>>>>>>>>
>>>>>>>>>>> I'm running a setup with VLANs with WDS and ath10k cards.
>>>>>>>>>>>
>>>>>>>>>>> To make it work both cards must be loaded in rawmode, AP and
>>>>>>>>>>> Sta, and with no security.
>>>>>>>>>>>
>>>>>>>>>>> I'm using a OpenWrt trunk r49941 and the most recent firmware,
>>>>>>>>>>> 10.2.4.70.58, from Kalle ath10k firmware tree.
>>>>>>>>>>>
>>>>>>>>>>> Although it works the throughput is very bad.
>>>>>>>>>>> Are there any alternatives to improve the throughput.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Bruno
>>>>>>>>>>>
>>>>>>>>>>> On 9 December 2015 at 17:24, voncken <cedric.voncken@acksys.fr>
>>>>
>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>>>> De : Ben Greear [mailto:greearb@candelatech.com] Envoyé :
>>>>>>>>>>>>> mercredi 9 décembre 2015 16:34 À : Cedric VONCKEN;
>>>>>>>>>>>>> ath10k@lists.infradead.org; linux-wireless Objet : Re: ATH10K
>>>>>>>>>>>>> VLAN firmware issue
>>>>>>>>>>>>>
>>>>>>>>>>>>> This only happens when you use STA + WDS, or is .1q broken
>>>>>>>>>>>>> for you in other cases as well?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, this issue occurs in all modes (STA, STA + WDS, AP).
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Cedric.
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Ben
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/08/2015 06:29 AM, Cedric VONCKEN wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm testing to transmit frame with 802.1q tag (VLAN).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My client is set in STA + WDS and the netdev is bridged
>>>>
>>>> with eth0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have a computer with vlan configuration set connected
>>>>>>>>>>>>>> to the STA eth0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I try to transmit frames with 802.1q tag, the frames
>>>>>>>>>>>>>> are not
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> sent.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I checked with wireless sniffer, and I don't see the
>>>>>>>>>>>>>> frame with VLAN tag (the frames without VLAN tag are sent).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tested with firmware 10.2.4.70.14-2 from kale github,
>>>>>>>>>>>>>> 10.1.467-ct-com-full-015 from candelatech and 10.2.4.70-2
>>>>>>>>>>>>>> from openwrt, and in all cases I have the same issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your help.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ben Greear <greearb@candelatech.com> Candela Technologies Inc
>>>>>>>>>>>>> http://www.candelatech.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> openwrt-devel mailing list
>>>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
>>>>
>>>> devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> openwrt-devel mailing list
>>>>>>>>>> openwrt-devel@lists.openwrt.org
>>>>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ath10k mailing list
>>>>>>>>> ath10k@lists.infradead.org
>>>>>>>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Ben Greear <greearb@candelatech.com>
>>>> Candela Technologies Inc http://www.candelatech.com
>>>
>>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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