* [PATCH 2/2] mwifiex: ignore calibration data failure
From: Amitkumar Karwar @ 2016-10-21 15:15 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1477062948-8558-1-git-send-email-akarwar@marvell.com>
Firmware may reject calibration data from host for certain OTP
settings. In that case, we should continue initialisation ignoring
the failure.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 2a162c3..638d30a 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2228,19 +2228,13 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
adapter->hs_cfg.gpio = data;
}
- ret = mwifiex_dnld_dt_cfgdata(priv, adapter->dt_node,
- "marvell,caldata");
- if (ret)
- return -1;
+ mwifiex_dnld_dt_cfgdata(priv, adapter->dt_node,
+ "marvell,caldata");
}
- if (adapter->cal_data) {
- ret = mwifiex_send_cmd(priv, HostCmd_CMD_CFG_DATA,
- HostCmd_ACT_GEN_SET, 0, NULL,
- true);
- if (ret)
- return -1;
- }
+ if (adapter->cal_data)
+ mwifiex_send_cmd(priv, HostCmd_CMD_CFG_DATA,
+ HostCmd_ACT_GEN_SET, 0, NULL, true);
/* Read MAC address from HW */
ret = mwifiex_send_cmd(priv, HostCmd_CMD_GET_HW_SPEC,
--
1.9.1
^ permalink raw reply related
* RE: cfg80211: race problem between suspend and disconnect event
From: Amitkumar Karwar @ 2016-10-21 15:48 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, Brian Norris, Nishant Sarmukadam, Cathy Luo,
linux-wireless@vger.kernel.org, Ganapathi Bhat
In-Reply-To: <1476989132.14078.12.camel@sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4gRnJvbTogSm9oYW5uZXMgQmVyZyBbbWFpbHRvOmpvaGFubmVzQHNp
cHNvbHV0aW9ucy5uZXRdDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAyMSwgMjAxNiAxMjoxNiBB
TQ0KPiBUbzogQW1pdGt1bWFyIEthcndhcg0KPiBDYzogS2FsbGUgVmFsbzsgQnJpYW4gTm9ycmlz
OyBOaXNoYW50IFNhcm11a2FkYW07IENhdGh5IEx1bzsgbGludXgtDQo+IHdpcmVsZXNzQHZnZXIu
a2VybmVsLm9yZzsgR2FuYXBhdGhpIEJoYXQNCj4gU3ViamVjdDogUmU6IGNmZzgwMjExOiByYWNl
IHByb2JsZW0gYmV0d2VlbiBzdXNwZW5kIGFuZCBkaXNjb25uZWN0IGV2ZW50DQo+IA0KPiBIaSwN
Cj4gDQo+ID4gTXdpZmlleCBkcml2ZXIgcmVqZWN0cyBkZWxfa2V5KCkgcmVxdWVzdHMgZnJvbSBj
Zmc4MDIxMSBkdXJpbmcNCj4gPiBzdXNwZW5kLiBUaGV5IGNhbWUgdmVyeSBsYXRlIHdoZW4gZHJp
dmVyJ3MgY2ZnODAyMTFfc3VzcGVuZCBoYW5kbGVyIGlzDQo+ID4gYWxyZWFkeSBleGVjdXRlZCBh
bmQgZHJpdmVyIGlzIGluIHRoZSBtaWRkbGUgb2YgU0RJTydzIHN1c3BlbmQNCj4gPiBoYW5kbGVy
Lg0KPiANCj4gSW50ZXJlc3RpbmcuIFJlamVjdGluZyB0aG9zZSBjYWxscyBpcyBwcm9iYWJseSBw
ZXJmZWN0bHkgcmVhc29uYWJsZSwgYW5kDQo+IGluIGZhY3QgaXQncyBub3QgY2xlYXIgdG8gbWUg
d2h5IHdlIGV2ZW4gdHJ5IHRvIGRlbGV0ZSB0aGUga2V5cyBhZnRlcg0KPiB3ZSd2ZSBkaXNjb25u
ZWN0ZWQgLSBhbnkgZHJpdmVyIGltcGxlbWVudGF0aW9uIHNob3VsZCBoYXZlIHJlbW92ZWQgdGhl
bQ0KPiBhbHJlYWR5IGFueXdheT8gWW91IHByb2JhYmx5IGRvbid0IGFjdHVhbGx5IGNhcmUgYWJv
dXQgdGhlIGtleSByZW1vdmFsDQo+IGVpdGhlcj8NCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5Lg0K
DQpZZXMuIEluIG91ciBjYXNlLCAqODAyXzExX0RFQVVUSEVOVElDQVRFIGNvbW1hbmQgZG93bmxv
YWRlZCB0byBmaXJtd2FyZSB0YWtlcyBjYXJlIG9mIGZsdXNoaW5nIHRoZSBrZXlzLg0KDQpJIGNh
biBzZWUgYmVsb3cgY29kZSBpbiBjZmc4MDIxMSdzIGRpc2Nvbm5lY3QgaGFuZGxpbmcuIEl0IHNl
ZW1zIHRvIGJlIHRoZXJlIGZvciBsb25nIHRpbWUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
LyoNCiAqIERlbGV0ZSBhbGwgdGhlIGtleXMgLi4uIHBhaXJ3aXNlIGtleXMgY2FuJ3QgcmVhbGx5
DQogKiBleGlzdCBhbnkgbW9yZSBhbnl3YXksIGJ1dCBkZWZhdWx0IGtleXMgbWlnaHQuDQogKi8N
CiBpZiAocmRldi0+b3BzLT5kZWxfa2V5KQ0KICAgIGZvciAoaSA9IDA7IGkgPCA2OyBpKyspDQog
ICAgICAgcmRldl9kZWxfa2V5KHJkZXYsIGRldiwgaSwgZmFsc2UsIE5VTEwpOw0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KPiANCj4gVGhhdCBzYWlkIHRob3VnaCwgdGhlcmUncyBhbHNvIHRo
ZSBjcml0aWNhbCBwcm90b2NvbCBzdG9wIGFuZCB0aGUNCj4gc2V0X3Fvc19tYXAoTlVMTCkgY2Fs
bCwgd2hpY2ggcmVtb3ZlcyB0aGUgUW9TIG1hcHBpbmcuIEl0IGRvZXNuJ3QgbG9vaw0KPiBsaWtl
IHlvdSBzdXBwb3J0IHRoaXMgcmlnaHQgbm93IGluIHlvdXIgZHJpdmVyLCBidXQgaW4gYW55IGNh
c2UgaXQnZCBiZQ0KPiBwcmV0dHkgc3RyYW5nZSB0byBoYXZlIHRoYXQgaGFwcGVuIGFmdGVyIG9y
IGR1cmluZyBzdXNwZW5kLg0KPiANCj4gPiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUg
YW55IHN1Z2dlc3Rpb25zIHRvIHJlc29sdmVzIHRoaXMgd2l0aA0KPiA+IGNmZzgwMjExL2RyaXZl
ciBjaGFuZ2UuDQo+IA0KPiBGb3IgY2ZnODAyMTEgd2UgY291bGQgZG8gc29tZXRoaW5nIGxpa2Ug
dGhpczoNCj4gDQo+IC0tLSBhL25ldC93aXJlbGVzcy9zeXNmcy5jDQo+ICsrKyBiL25ldC93aXJl
bGVzcy9zeXNmcy5jDQo+IEBAIC0xMDQsMTMgKzEwNCwxNiBAQCBzdGF0aWMgaW50IHdpcGh5X3N1
c3BlbmQoc3RydWN0IGRldmljZSAqZGV2KQ0KPiANCj4gIAlydG5sX2xvY2soKTsNCj4gIAlpZiAo
cmRldi0+d2lwaHkucmVnaXN0ZXJlZCkgew0KPiAtCQlpZiAoIXJkZXYtPndpcGh5Lndvd2xhbl9j
b25maWcpDQo+ICsJCWlmICghcmRldi0+d2lwaHkud293bGFuX2NvbmZpZykgew0KPiAgCQkJY2Zn
ODAyMTFfbGVhdmVfYWxsKHJkZXYpOw0KPiArCQkJY2ZnODAyMTFfcHJvY2Vzc19yZGV2X2V2ZW50
cyhyZGV2KTsNCj4gKwkJfQ0KPiAgCQlpZiAocmRldi0+b3BzLT5zdXNwZW5kKQ0KPiAgCQkJcmV0
ID0gcmRldl9zdXNwZW5kKHJkZXYsIHJkZXYtPndpcGh5Lndvd2xhbl9jb25maWcpOw0KPiAgCQlp
ZiAocmV0ID09IDEpIHsNCj4gIAkJCS8qIERyaXZlciByZWZ1c2UgdG8gY29uZmlndXJlIHdvd2xh
biAqLw0KPiAgCQkJY2ZnODAyMTFfbGVhdmVfYWxsKHJkZXYpOw0KPiArCQkJY2ZnODAyMTFfcHJv
Y2Vzc19yZGV2X2V2ZW50cyhyZGV2KTsNCj4gIAkJCXJldCA9IHJkZXZfc3VzcGVuZChyZGV2LCBO
VUxMKTsNCj4gIAkJfQ0KPiAgCX0NCj4gDQo+IA0KPiBIb3dldmVyLCB0aGF0IGFzc3VtZXMgdGhh
dCB5b3UgYWN0dWFsbHnCoGNmZzgwMjExX2Rpc2Nvbm5lY3RlZCgpDQo+IHN5bmNocm9ub3VzbHkg
d2hpbGUgYmVpbmcgYXNrZWQgdG8gZGlzY29ubmVjdCwgd2hpY2ggZG9lc24ndCBzZWVtIHRvIGJl
DQo+IHRydWUgZnJvbSBsb29raW5nIGF0IG13aWZpZXgsIGlmIEhvc3RDbWRfQ01EXzgwMl8xMV9E
RUFVVEhFTlRJQ0FURQ0KPiBjb21tYW5kIGNhbiBiZSBzZW50IHRvIHRoZSBmaXJtd2FyZSB0aGVu
IHlvdSB3YWl0IGZvciBFVkVOVF9MSU5LX0xPU1QsDQo+IEVWRU5UX0RFQVVUSEVOVElDQVRFRCBv
csKgRVZFTlRfRElTQVNTT0NJQVRFRCB0byBjb21lIGJhY2sgZnJvbSB0aGUNCj4gZmlybXdhcmUs
IHNvIHRoaXMgY2ZnODAyMTEgY2hhbmdlIHdvbid0IGhlbHAuDQo+IA0KDQpJIHRoaW5rLCB5b3Vy
IGNmZzgwMjExIGNoYW5nZSB3aWxsIGhlbHAuIFdlIGRvIGVuc3VyZSB0aGF0IGNmZzgwMjExX2Rp
c2Nvbm5lY3RlZCgpIGlzIGNhbGxlZCBiZWZvcmUgZXhpdGluZyBtd2lmaWV4X2NmZzgwMjExX2Rp
c2Nvbm5lY3QoKS4NClNlbmRpbmcgSG9zdENtZF9DTURfODAyXzExX0RFQVVUSEVOVElDQVRFIGNv
bW1hbmQgdG8gZmlybXdhcmUgaXMgYSBibG9ja2luZyBjYWxsLiBjZmc4MDIxMV9kaXNjb25uZWN0
ZWQoKSBpcyBjYWxsZWQgd2hpbGUgaGFuZGxpbmcgdGhhdCBjb21tYW5kJ3MgcmVzcG9uc2UuIA0K
DQptd2lmaWV4X3JldF84MDJfMTFfZGVhdXRoZW50aWNhdGUoKS0+bXdpZmlleF9yZXNldF9jb25u
ZWN0X3N0YXRlKCktPmNmZzgwMjExX2Rpc2Nvbm5lY3RlZCgpDQoNCj4gDQo+IFNvIHNvbWVob3cg
eW91J2QgaGF2ZSB0byBzeW5jaHJvbml6ZSB3aXRoIHRoZSBmaXJtd2FyZSBhcyB3ZWxsLCB0bw0K
PiBwcm9jZXNzIGFsbCB0aG9zZSB0aGluZ3MgYmVmb3JlIHN1c3BlbmQsIEkgZ3Vlc3M/DQo+IA0K
PiBXZSBjb3VsZCB0aGVuIGV4cG9ydCBjZmc4MDIxMV9wcm9jZXNzX3JkZXZfZXZlbnRzKCkgYXMN
Cj4gY2ZnODAyMTFfcHJvY2Vzc193aXBoeV9ldmVudHMoKSBvciBzbywgc28gdGhhdCB5b3UgY2Fu
IGNhbGwgdGhhdCBhdCBhbg0KPiBhcHByb3ByaWF0ZSBwbGFjZSBmcm9tIHlvdXIgc3VzcGVuZCBo
YW5kbGVyLCBhZnRlciBoYXZpbmcgc3luY2hyb25pemVkDQo+IHdpdGggdGhlIGZpcm13YXJlPw0K
DQpUaGlzIHdvdWxkIG5vdCBiZSBuZWVkZWQuIA0KDQpSZWdhcmRzLA0KQW1pdGt1bWFyDQo=
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Markus Heiser @ 2016-10-21 16:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jani Nikula, Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <1477055055.4068.46.camel@sipsolutions.net>
Am 21.10.2016 um 15:04 schrieb Johannes Berg <johannes@sipsolutions.net>:
>> I had the same conclusion for math:: directives pulling in latex
>> dependency [1]. Hopefully Markus can help here.
>
> Yeah, good one.
>
> Maybe it's actually simple? Depending on where sphinx will look for
> plugins first, we could just ship the plugins with a no-op
> implementation (pass through the text as pre-formatted text), and if it
> finds the plugin first in a system-wide path that version would win for
> the better rendering?
Yes and No. It depends on the tools (toolchains) we want to use.
As far as I can see from a abstract POV it should by simple for
math:: / since we already use/need LaTeX for PDF, for other tools
I have to look.
I general I think, we should not include Java into our toolchains
even if it is optional. Thats, why I won't vote for http://plantuml.com/
aafigure: has dependencies [1] to reportlab (which is IMO inapposite) and
PIL, which is outdated / and aafigure itself seems outdated [2].
seqdiag: requires blockdiag and this requires Pillow ... until here
its seems not bad, but there is also some "optional" dependencies to
ImageMagick and reportlab (both smells).
IMO a tool which generates SVG would be the best, I have to check
if I find some or if some of the above could used in this way.
For this I need time ;-) ... ATM I work in a custom project but
I hope I will find next week time to dig more deeper.
-- Markus --
[1] https://pythonhosted.org/sphinxcontrib-aafig/#requirements
[2] http://bazaar.launchpad.net/~aafigure-team/aafigure/trunk/files
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-21 16:25 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <80788796-5768-1650-dcef-59ccfbe7be6f@gmail.com>
The problem is gone with kernel 4.7.3 on armbian - both compex cards
work (wle600, wle900), unfortunately that kernel does not support sfp
(seems like its kind of proprietary drivers from clearfog). So its a
driver issue but i have no clue who to contact or where to file a bug
report. The only available kernel which supports sfp (from solidrun,
vendor of the clearfog board) is 4.4.23
I am wondering if i could simply checkout the 4.4.x sources, merge the
atheros drivers in it and try to rebuild the kernel?
Am 15.10.2016 um 19:04 schrieb Oliver Zemann:
> I hope thats what you mean. I am not that familiar with linux drivers
>
> [root@alarm ~]# lsmod
> Module Size Used by
> ath10k_pci 30053 0
> ath10k_core 193491 1 ath10k_pci
> ath 18176 1 ath10k_core
> mac80211 405739 1 ath10k_core
> cfg80211 215848 3 ath,mac80211,ath10k_core
> rfkill 14391 2 cfg80211
> marvell_cesa 25839 0
> des_generic 16747 1 marvell_cesa
> sch_fq_codel 7757 9
> ip_tables 11170 0
> x_tables 11520 1 ip_tables
> autofs4 22783 2
> [root@alarm ~]# rmmod ath10k_pci ath10k_core
> [root@alarm ~]# modprobe ath10k_core
> [root@alarm ~]# modprobe ath10k_pci
> [28501.637198] ath10k_pci 0000:02:00.0: Refused to change power state,
> currently in D3
> [28501.675138] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> [28501.681625] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>
>
> Am 15.10.2016 um 16:44 schrieb Sebastian Gottschall:
>> could you please attach a full log? i see no driver loading here.
>> this is just a small part of the kernel boot log, but no driver
>> intialisation
>>
>> Am 15.10.2016 um 16:00 schrieb Oliver Zemann:
>>> I have a clearfog pro (arm7) from marvel and bought a pcie wifi
>>> card. Unfortunately, it does not work.
>>> I am not sure if this is a bug in the module or even in some pci-e
>>> driver. Maybe someone could tell me that.
>>>
>>> dmesg:
>>>
>>> [ 5.348307] mvebu-pcie soc:pcie-controller:
>>> /soc/pcie-controller/pcie@2,0: reset gpio is active low
>>> [ 5.358026] mvebu-pcie soc:pcie-controller:
>>> /soc/pcie-controller/pcie@3,0: reset gpio is active low
>>> [ 5.421496] mvebu-pcie soc:pcie-controller: PCI host bridge to bus
>>> 0000:00
>>> [ 5.428390] pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
>>> [ 5.434680] pci_bus 0000:00: root bus resource [mem
>>> 0xf8000000-0xffdfffff]
>>> [ 5.441575] pci_bus 0000:00: root bus resource [bus 00-ff]
>>> [ 5.447083] pci 0000:00:02.0: [11ab:6828] type 01 class 0x060400
>>> [ 5.447198] pci 0000:00:03.0: [11ab:6828] type 01 class 0x060400
>>> [ 5.447295] PCI: bus0: Fast back to back transfers disabled
>>> [ 5.452887] pci 0000:00:02.0: bridge configuration invalid ([bus
>>> 00-00]), reconfiguring
>>> [ 5.460911] pci 0000:00:03.0: bridge configuration invalid ([bus
>>> 00-00]), reconfiguring
>>> [ 5.468986] PCI: bus1: Fast back to back transfers enabled
>>> [ 5.474491] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
>>> [ 5.474561] pci 0000:02:00.0: [168c:003c] type 00 class 0x028000
>>> [ 5.474593] pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x001fffff
>>> 64bit]
>>> [ 5.474617] pci 0000:02:00.0: reg 0x30: [mem 0x00000000-0x0000ffff
>>> pref]
>>> [ 5.474667] pci 0000:02:00.0: supports D1 D2
>>> [ 5.511395] PCI: bus2: Fast back to back transfers enabled
>>> [ 5.516894] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
>>> [ 5.516905] pci 0000:02:00.0: of_irq_parse_pci() failed with rc=134
>>> [ 5.523207] pci 0000:00:03.0: BAR 14: assigned [mem
>>> 0xf8000000-0xf82fffff]
>>> [ 5.530098] pci 0000:00:02.0: PCI bridge to [bus 01]
>>> [ 5.535082] pci 0000:02:00.0: BAR 0: assigned [mem
>>> 0xf8000000-0xf81fffff 64bit]
>>> [ 5.542413] pci 0000:02:00.0: BAR 0: error updating (0xf8000004 !=
>>> 0xffffffff)
>>> [ 5.549652] pci 0000:02:00.0: BAR 0: error updating (high 0x000000
>>> != 0xffffffff)
>>> [ 5.557155] pci 0000:02:00.0: BAR 6: assigned [mem
>>> 0xf8200000-0xf820ffff pref]
>>> [ 5.564396] pci 0000:00:03.0: PCI bridge to [bus 02]
>>> [ 5.569372] pci 0000:00:03.0: bridge window [mem 0xf8000000-0xf82fffff]
>>> [ 5.576256] pcieport 0000:00:03.0: enabling device (0140 -> 0142)
>>>
>>> lspci:
>>>
>>>
>>> [root@alarm alarm]# lspci
>>> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
>>> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
>>> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
>>> Wireless Network Adapter (rev ff)
>>
>>>
>>> Thanks!
>>>
>>>
>>
>>
>
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Michal Kazior @ 2016-10-21 16:54 UTC (permalink / raw)
To: Oliver Zemann; +Cc: linux-wireless
In-Reply-To: <bffb5d2b-03f3-f451-dd01-ef2c796bfc30@gmail.com>
On 21 October 2016 at 18:25, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> The problem is gone with kernel 4.7.3 on armbian - both compex cards work
> (wle600, wle900), unfortunately that kernel does not support sfp (seems l=
ike
> its kind of proprietary drivers from clearfog). So its a driver issue but=
i
> have no clue who to contact or where to file a bug report. The only
> available kernel which supports sfp (from solidrun, vendor of the clearfo=
g
> board) is 4.4.23
>
> I am wondering if i could simply checkout the 4.4.x sources, merge the
> atheros drivers in it and try to rebuild the kernel?
That's what backports[1] are for.
The problem could be in the pci subsystem though so backporting the
driver itself might not solve your problem.
[1]: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/backports
Micha=C5=82
^ permalink raw reply
* [PATCH v5] mwifiex: parse device tree node for PCIe
From: Rajat Jain @ 2016-10-21 17:15 UTC (permalink / raw)
To: linux-wireless, devicetree, rajatja, Xinming Hu, Amitkumar Karwar,
Brian Norris, Kalle Valo, Rob Herring
Cc: rajatxjain
In-Reply-To: <20161021020609.GA18359@localhost>
From: Xinming Hu <huxm@marvell.com>
This patch derives device tree node from pcie bus layer framework, and
fixes a minor memory leak in mwifiex_pcie_probe() (in failure path).
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accomodate PCIe changes.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
v3: Patch is created using -M option so that it will only include diff of
original and renamed files(Rob Herring)
Resend v3: Resending the patch because I missed to include device tree mailing
while sending v3.
v4: Fix error handling, also move-on even if no device tree node is present.
v5: Update commit log to include memory leak, return -EINVAL instead of -1.
.../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++--
drivers/net/wireless/marvell/mwifiex/pcie.c | 39 +++++++++++++++++++---
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
3 files changed, 42 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
similarity index 91%
rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index c421aba..dfe5f8e 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,8 +1,8 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller that
+This node provides properties for controlling the marvell sdio/pcie wireless device.
+The node is expected to be specified as a child node to the SDIO/PCIE controller that
connects the device to the system.
Required properties:
@@ -10,6 +10,8 @@ Required properties:
- compatible : should be one of the following:
* "marvell,sd8897"
* "marvell,sd8997"
+ * "pci11ab,2b42"
+ * "pci1b4b,2b42"
Optional properties:
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 3c3c4f1..7c44f88 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,22 @@ static struct mwifiex_if_ops pcie_ops;
static struct semaphore add_remove_card_sem;
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+ { .compatible = "pci11ab,2b42" },
+ { .compatible = "pci1b4b,2b42" },
+ { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+ if (!of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+ pr_err("pcie device node not available");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -178,6 +194,7 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct pcie_service_card *card;
+ int ret;
pr_debug("info: vendor=0x%4.04X device=0x%4.04X rev=%d\n",
pdev->vendor, pdev->device, pdev->revision);
@@ -199,13 +216,27 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
- if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
- MWIFIEX_PCIE)) {
- pr_err("%s failed\n", __func__);
- return -1;
+ /* device tree node parsing and platform specific configuration*/
+ if (pdev->dev.of_node) {
+ ret = mwifiex_pcie_probe_of(&pdev->dev);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "required compatible string missing\n");
+ goto err_free;
+ }
}
+ ret = mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
+ MWIFIEX_PCIE);
+ if (ret) {
+ pr_err("%s failed\n", __func__);
+ goto err_free;
+ }
return 0;
+
+err_free:
+ kfree(card);
+ return ret;
}
/*
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 2a162c3..c8dccf5 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2218,7 +2218,8 @@ 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 &&
+ 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 (of_property_read_u32(adapter->dt_node,
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [PATCH 2/2] mac80211: use inline kernel-doc for struct ieee80211_hw
From: Arend van Spriel @ 2016-10-21 18:59 UTC (permalink / raw)
To: Johannes Berg, Jani Nikula, linux-wireless; +Cc: linux-doc
In-Reply-To: <1477054892.4068.44.camel@sipsolutions.net>
On 21-10-16 15:01, Johannes Berg wrote:
> On Fri, 2016-10-21 at 15:57 +0300, Jani Nikula wrote:
>> It's easier to manage the kernel-doc for the fields when they
>> documentation is next to the field.
>
> Hah, I wasn't even aware this was possible. Thanks!
Me neither. I actually found it annoying to have all kernel-doc above
the type definition and indeed easy to miss fields. Now struct
ieee80211_hw is not alone and we have it all over the place in the
wireless subsystem. Is this something we want to embrace and maybe find
janitors/newbies/coccinelle-gurus to address it. Not sure if coccinelle
could deal with this.
Regards,
Arend
^ permalink raw reply
* RE: [PATCH][RFC] nl80211/mac80211: Rounded RSSI reporting
From: Zaborowski, Andrew @ 2016-10-21 19:03 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <1477038639.4068.28.camel@sipsolutions.net>
Hi,
> The problem is that you really want this to be offloaded to the device,
> *especially* if you care about low power usage, because you absolutely
> don't want to be processing each beacon (which is typically what we
> derive the data from today) in the host CPU - you want those to be
> filtered by the device so you don't wake up the host CPU every ~102ms.
Right, that would be a separate optimisation but it probably won't arrive
until there's an API that the drivers can implement, so I think this is a
prerequisite.
> Without offloading to the device, your patch is actually fairly much
> pointless, because you've already woken up the host CPU, at which point
> punting to userspace probably isn't all that much more expensive over
> the cost of waking up the CPU in the first place.
The userspace switches count too and are the main motivation for this
patch. Eventually, as you say, things will depend on specific drivers
and you will want to optimise whatever you can assuming the hardware
you're constrained to.
> Looking at the code, it seems like only a single driver could support
> this in a pseudo-offloaded fashion (iwlmvm), where all the others that
> offload it today would not be able to support this API at all, unless
> they fall back to complete software processing which, as I wrote above,
> will have far worse power consumption consequences.
>
> Therefore, adding this API just for mac80211 seems pretty pointless,
> especially since you're targeting this for IoT, where I expect people
> will be using full-MAC chips rather than soft-MAC, with the consequence
> of not even using mac80211-based drivers. Oops.
Hence this mail, I want to find out what would be a good API and it
should work with both mac80211 and full MAC chips. I included a mac80211
implementation because, well, it's in software and thus you can see it
and use it for reference, and it covers a range of hardware.
It seems like any mechanism you choose can be implemented on top of
hardware that supports a low and a high threshold by setting the next
values while handling the event related to the previous threshold crossing
event. If the thresholds are specified by a middle value and a hysteresis
or distance, that would work equally well.
The API I added in the patch also allows offloading to such hardware.
The remaining drivers might not be able to support any useful mechanism.
>> The assumption is that you can't simulate the same behavior with just
>> the current NL80211_ATTR_CQM_RSSI_THOLD attribute.
>
> Is that true? Technically, it seems that perhaps if you wanted to have
> a few ranges, you could always pick one that's currently active, and
> program that into the driver/device, with a hysteresis big enough to
> extend to the edges of the next range, or something?
Yes, but not with the current netlink API since the cqm_last_rssi_event
(whatever the driver calls it) value is reset when you set new thresholds,
so you won't know what "last" value will be used, and you'll also get a
spurious event on the next beacon.
And then at least two drivers use the hysteresis value differently
(wl1251, cw1200).
In short a nl80211 change would be needed regardless of the mechanism
chosen.
Best regards
-----------------------------------------------------------
Intel Corporation Iberia, S.A.
Registered Office: Torre Picasso, 25th Floor,
Plaza Pablo Ruiz Picasso, no. 1, 28020 Madrid
Este mensaje se dirige exclusivamente a su destinatario y puede
contener informacion privilegiada o confidencial. Si no es vd.
el destinatario indicado, queda notificado de que la lectura,
utilizacion, divulgacion y,o copia sin autorizacion esta prohibida
en virtud de la legislacion vigente. Si ha recibido este mensaje por
error, le rogamos que nos lo communique inmediatamente por
esta misma via y proceda a su destruccion.
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: use inline kernel-doc for struct ieee80211_hw
From: Johannes Berg @ 2016-10-21 19:56 UTC (permalink / raw)
To: Arend van Spriel, Jani Nikula, linux-wireless; +Cc: linux-doc
In-Reply-To: <a6fb17b3-0ec6-e23b-4ae3-f84385cf84ae@broadcom.com>
On Fri, 2016-10-21 at 20:59 +0200, Arend van Spriel wrote:
> Me neither. I actually found it annoying to have all kernel-doc above
> the type definition and indeed easy to miss fields. Now struct
> ieee80211_hw is not alone and we have it all over the place in the
> wireless subsystem. Is this something we want to embrace and maybe
> find janitors/newbies/coccinelle-gurus to address it. Not sure if
> coccinelle could deal with this.
I don't think coccinelle can look into comments, though perhaps it
could be used to *place* them - use kernel-doc script to extract them
first, and then make that output a coccinelle script to place the
comment back at the right spot?
Overall though, not sure that's worth it over just doing it by hand
once? Then again, that could be used to mass-convert more ... :)
johannes
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-21 21:17 UTC (permalink / raw)
To: Markus Heiser; +Cc: Jani Nikula, Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <EFAA684D-941C-45F9-8D37-F28EF3B11F4F@darmarit.de>
> I general I think, we should not include Java into our toolchains
> even if it is optional. Thats, why I won't vote for
> http://plantuml.com/
Keep in mind though that such a vote may well end up being a vote not
just against plantuml, but also against having sequence diagrams to
start with - at least as far as I'm concerned - since we (rightfully!)
also don't want to start writing our own infrastructure (again). There
aren't many alternatives. Even seqdiag/blockdiag isn't nearly as fully
featured as plantuml.
> IMO a tool which generates SVG would be the best, I have to check
> if I find some or if some of the above could used in this way.
plantuml does create svg :->
Ultimately, I actually think it doesn't matter much whether we add java
or python or whatever to our toolchain.
As soon as we add external dependencies that have to be fulfilled
outside of the kernel git tree, and such fulfilment is easy (as it is
in "sudo apt-get install plantuml python3-sphinxcontrib.plantuml"), it
hardly matters what exactly is behind it.
So ultimately, the way I see it, we essentially have two choices:
1) we reject external dependencies entirely, shipping everything in
the tree that we need to build documentation
2) we accept external dependencies, hopefully finding ways to make
them optional
In case of 1), which we obviously don't have today since we don't ship
sphinx and everything, we're basically reduced to having very simple
python-only plugins. As far as I'm concerned this will mean that I'm
not adding such diagrams to the kernel documentation, life's too short
to rewrite something like plantuml, and I can't find anything that's
pure python (and fulfilling your - IMHO a bit exaggerated - standards).
In case of 2), as long as it's easy to install on a typical Linux
distro, I think it doesn't actually matter that it's java or whatever
else.
johannes
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-21 21:19 UTC (permalink / raw)
To: Markus Heiser; +Cc: Jani Nikula, Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <EFAA684D-941C-45F9-8D37-F28EF3B11F4F@darmarit.de>
On Fri, 2016-10-21 at 18:11 +0200, Markus Heiser wrote:
> Yes and No. It depends on the tools (toolchains) we want to use.
> As far as I can see from a abstract POV it should by simple for
> math:: / since we already use/need LaTeX for PDF, for other tools
> I have to look.
Not sure if we were talking past each other - but the pass-through is
actually really simple - example patch below.
This makes it output an SVG (with fallback to PNG even) into the HTML,
a PDF into the PDF, and plain pre-formatted text for both when the
plantuml sphinx plugin isn't installed.
johannes
diff --git a/Documentation/conf.py b/Documentation/conf.py
index bf6f310e5170..2c00ab6f0baf 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,8 @@ from load_config import loadConfig
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
-extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain']
+extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain',
+ 'plantuml']
# The name of the math extension changed on Sphinx 1.4
if minor > 3:
@@ -494,6 +495,9 @@ pdf_documents = [
kerneldoc_bin = '../scripts/kernel-doc'
kerneldoc_srctree = '..'
+plantuml_output_format = "svg"
+plantuml_latex_output_format = "pdf"
+
# ------------------------------------------------------------------------------
# Since loadConfig overwrites settings from the global namespace, it has to be
# the last statement in the conf.py file
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 8e259c5d0322..e0d4f24b6039 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -7,6 +7,12 @@ of device drivers. This document is an only somewhat organized collection
of some of those interfaces — it will hopefully get better over time! The
available subsections can be seen below.
+.. uml::
+
+ Alice -> Bob: Hi!
+ Alice <- Bob: How are you?
+
+
.. class:: toc-title
Table of contents
diff --git a/Documentation/sphinx/dummy.py b/Documentation/sphinx/dummy.py
new file mode 100644
index 000000000000..cfac42886ebd
--- /dev/null
+++ b/Documentation/sphinx/dummy.py
@@ -0,0 +1,24 @@
+from sphinx.util.compat import Directive
+from docutils import nodes
+from docutils.parsers.rst import directives
+
+class IgnoreOptions(object):
+ def __getitem__(self, key):
+ return directives.unchanged
+
+def create_setup(directives):
+ def setup(app):
+ for d in directives:
+ class TextDirective(Directive):
+ has_content = True
+ option_spec = IgnoreOptions()
+
+ def run(self):
+ text = '\n'.join(self.content)
+ return [nodes.literal_block('', text,
+ classes=['code',
+ 'missing-plugin',
+ 'missing-plugin-%s' % d])]
+
+ app.add_directive(d, TextDirective)
+ return setup
diff --git a/Documentation/sphinx/plantuml.py b/Documentation/sphinx/plantuml.py
new file mode 100644
index 000000000000..0007bc7f24fd
--- /dev/null
+++ b/Documentation/sphinx/plantuml.py
@@ -0,0 +1,7 @@
+# -*- coding: utf-8 -*-
+from dummy import create_setup
+
+try:
+ from sphinxcontrib.plantuml import *
+except:
+ setup = create_setup(['uml'])
^ permalink raw reply related
* [PATCH v6] mwifiex: parse device tree node for PCIe
From: Rajat Jain @ 2016-10-21 21:21 UTC (permalink / raw)
To: linux-wireless, devicetree, rajatja, Xinming Hu, Amitkumar Karwar,
Brian Norris, Kalle Valo, Rob Herring
Cc: rajatxjain
In-Reply-To: <1477070156-109965-1-git-send-email-rajatja@google.com>
From: Xinming Hu <huxm@marvell.com>
This patch derives device tree node from pcie bus layer framework, and
fixes a minor memory leak in mwifiex_pcie_probe() (in failure path).
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accommodate PCIe changes.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
v3: Patch is created using -M option so that it will only include diff of
original and renamed files(Rob Herring)
Resend v3: Resending the patch because I missed to include device tree mailing
while sending v3.
v4: Fix error handling, also move-on even if no device tree node is present.
v5: Update commit log to include memory leak, return -EINVAL instead of -1.
v6: Remove an unnecessary error print, fix typo in commit log
.../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++--
drivers/net/wireless/marvell/mwifiex/pcie.c | 36 +++++++++++++++++++---
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
3 files changed, 39 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
similarity index 91%
rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index c421aba..dfe5f8e 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,8 +1,8 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller that
+This node provides properties for controlling the marvell sdio/pcie wireless device.
+The node is expected to be specified as a child node to the SDIO/PCIE controller that
connects the device to the system.
Required properties:
@@ -10,6 +10,8 @@ Required properties:
- compatible : should be one of the following:
* "marvell,sd8897"
* "marvell,sd8997"
+ * "pci11ab,2b42"
+ * "pci1b4b,2b42"
Optional properties:
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 3c3c4f1..f7c84d3 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,22 @@ static struct mwifiex_if_ops pcie_ops;
static struct semaphore add_remove_card_sem;
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+ { .compatible = "pci11ab,2b42" },
+ { .compatible = "pci1b4b,2b42" },
+ { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+ if (!of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+ dev_err(dev, "required compatible string missing\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -178,6 +194,7 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct pcie_service_card *card;
+ int ret;
pr_debug("info: vendor=0x%4.04X device=0x%4.04X rev=%d\n",
pdev->vendor, pdev->device, pdev->revision);
@@ -199,13 +216,24 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
- if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
- MWIFIEX_PCIE)) {
- pr_err("%s failed\n", __func__);
- return -1;
+ /* device tree node parsing and platform specific configuration*/
+ if (pdev->dev.of_node) {
+ ret = mwifiex_pcie_probe_of(&pdev->dev);
+ if (ret)
+ goto err_free;
}
+ ret = mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
+ MWIFIEX_PCIE);
+ if (ret) {
+ pr_err("%s failed\n", __func__);
+ goto err_free;
+ }
return 0;
+
+err_free:
+ kfree(card);
+ return ret;
}
/*
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 2a162c3..c8dccf5 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2218,7 +2218,8 @@ 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 &&
+ 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 (of_property_read_u32(adapter->dt_node,
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: cfg80211: race problem between suspend and disconnect event
From: Johannes Berg @ 2016-10-21 21:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Kalle Valo, Brian Norris, Nishant Sarmukadam, Cathy Luo,
linux-wireless@vger.kernel.org, Ganapathi Bhat
In-Reply-To: <7af766c43f2f426b8db177f8d4e67031@SC-EXCH04.marvell.com>
> Yes. In our case, *802_11_DEAUTHENTICATE command downloaded to
> firmware takes care of flushing the keys.
>
> I can see below code in cfg80211's disconnect handling. It seems to
> be there for long time.
Yeah, I saw it, but it's not clear to me that there's much point in it.
In any case, that's an unrelated question in a way, because there
definitely are things happening here that should be "more synchronous",
regardless of whether or not the key deletion makes sense.
> I think, your cfg80211 change will help. We do ensure that
> cfg80211_disconnected() is called before exiting
> mwifiex_cfg80211_disconnect().
> Sending HostCmd_CMD_802_11_DEAUTHENTICATE command to firmware is a
> blocking call. cfg80211_disconnected() is called while handling that
> command's response.
Ah ok, I missed that - I thought it was asynchronous.
> > So somehow you'd have to synchronize with the firmware as well, to
> > process all those things before suspend, I guess?
> >
[...]
> This would not be needed.
Right. Care to test my patch before I properly submit it?
johannes
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Jonas Gorski @ 2016-10-22 11:55 UTC (permalink / raw)
To: Oliver Zemann; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <bffb5d2b-03f3-f451-dd01-ef2c796bfc30@gmail.com>
Hi,
On 21 October 2016 at 18:25, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> The problem is gone with kernel 4.7.3 on armbian - both compex cards work
> (wle600, wle900),
Interesting to know this issue isn't present in 4.7 - I also
encountered it in 4.4 with LEDE.
> unfortunately that kernel does not support sfp (seems like
> its kind of proprietary drivers from clearfog).
They aren't really proprietary, they are proper patches that were
submitted as RFC once, so it shouldn't be much effort to port them to
e.g. 4.7. Anyways ...
> So its a driver issue but i
> have no clue who to contact or where to file a bug report. The only
> available kernel which supports sfp (from solidrun, vendor of the clearfog
> board) is 4.4.23
>
> I am wondering if i could simply checkout the 4.4.x sources, merge the
> atheros drivers in it and try to rebuild the kernel?
the issue seems to be that MSI interrupts do not work on 4.4 (at least
with ath10k, didn't have any other drivers that support it to test).
Your options are either to disable support for them in the kernel
config, or pass irq_mode=1 to ath10k_pci on probe to force legacy
interrupts; it should work then properly.
Regards
Jonas
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Antonio Quartulli @ 2016-10-22 13:42 UTC (permalink / raw)
To: ath9k-devel; +Cc: linux-wireless, sw, Antonio Quartulli
In-Reply-To: <20161018083552.28592-1-a@unstable.cc>
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
Hello,
I am trying to understand what's required by this patch to be merged upstream.
Sven Eckelmann commented in another email by saying:
"The patch itself has (at least) one big problem. It is using some mac80211
internals in ath_key_config_iter to make sure that the uploaded keys were
actually programmed in the hardware. Without this check the keys could end up
in the lower slots and thus break all connections."
Does anybody else have any other additional comment?
(Please keep me in CC as I am not registered to the ath9k ML).
Cheers,
On Tue, Oct 18, 2016 at 04:35:52PM +0800, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> This patch was crafted long time ago to work around a key cache
> corruption problem on ath9k chipsets.
>
> The workaround consists in periodically triggering a worker that
> uploads all the keys to the HW cache. The worker is triggered also
> when the vif detects 21 undecryptable packets.
>
>
> This patch is based on top compat-wireless-2015-10-26.
>
>
> I was asked to release this code to the public and, since it is
> GPL, I am now doing it.
>
>
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Using ath5k/ath9k radio for constant-tx noise source.
From: Sebastian Gottschall @ 2016-10-22 14:49 UTC (permalink / raw)
To: Zefir Kurtisi, Ben Greear, linux-wireless@vger.kernel.org
Cc: Christian Lamparter
In-Reply-To: <27058308-3d36-b415-900f-3e3b65b11dab@neratec.com>
atheros has a continues transmission mode which is used for power
calibration in factory using the ART utility. its available on ath9k
cards as well.
once enabled no wifi connection is possible on the same frequency since
it will break up all CSMA handling also with neighbor networks. its a nice
feature for disconnecting all wifi networks in your area
look for the called atheros / qca TESTMODE. its a simple register
setting (enable, disable)
Am 15.09.2016 um 17:28 schrieb Zefir Kurtisi:
> Hi Ben,
>
> On 09/15/2016 02:22 AM, Ben Greear wrote:
>> On 08/20/2015 08:11 AM, Zefir Kurtisi wrote:
>>> On 08/19/2015 09:07 PM, Ben Greear wrote:
>>>> I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be
>>>> wrong)
>>>> and it has the ability to do a constant transmit of raw noise (RF probe shows
>>>> noise, but a monitor-port sniffer does not see any frames from the CM9).
>>>>
>>>> I don't know the low-level details of how it is doing this, but I suspect
>>>> it is using something like madwifi for a driver.
>>>>
>>>> Does anyone know how this can be done with modern software and
>>>> ath5k or ath9k NICs?
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>> Maybe slightly related: some years ago when DFS became a topic and it was hard to
>>> get hands on radar pattern generators, Christian Lamparter wrote a variant of the
>>> carl9170 fw [1] which can generate radar pulses to test ath9k and other DFS radar
>>> detectors. Pulses are generated by enabling txout at defined sampling intervals.
>>>
>>> It should be doable to mimic what you are looking for by generating a _very_ long
>>> pulse.
>> Sorry to revive such an old thread..but I'm back poking at this.
>>
> Whew, that year went by so incredibly fast ;)
>
>> I've used the modified carl9170 firmware to generate pulses, with
>> the control being 'pulse-width' and 'pulse-interval'.
>>
>> This sort of works, and sometimes our ath10k in an isolation chamber reports
>> a radar event.
>>
>> But, after some reading, I am thinking I need more control to better mimic
>> a radar.
>>
>> If I understand things properly, I need something like this:
>>
>> A pulse event being: pulse width, pulse period: For instance 1us, 200us
>> Then, I need to configure an amount of pulse events, maybe 10-30 consecutive pulse
>> events.
>> Then, I need a quiet period to mimic the radar sweeping full circle (15 seconds
>> perhaps)
>>
>> From what I can tell, the carl9170 modified firmware is missing the features
>> to do this, though it should not be too difficult to add.
>>
> Yes, that's essentially it - the last step is even not needed if your goal is to
> estimate DFS detection probabilities, since in the certification lab they usually
> just repeatedly fire the radar pattern and count detection events.
>
> When I played with the modified carl9170 FW, I estimated that developing an solid
> and reliable radar pattern pulse scheduler would take me 2-4 weeks, so being in a
> hurry I ended up using an SDR (Ettus USRP N200, see [1]). I developed a pulse
> scheduler to feed arbitrary patterns (covering those for DFS testing), which is
> available in [2]. It has not been maintained ever since, but might help you as
> starting point if you decide to go that route.
>
>> If someone has an idea whether the control above is appropriate, I'd
>> appreciate feedback before I start hacking...
>>
>> This document seemed useful, for instance:
>>
>> https://dl.cdn-anritsu.com/en-en/test-measurement/files/Product-Introductions/Product-Introduction/mx370073a-el1200.pdf
>>
> We use the R&S SMBV100A [3], which we know is also used in some certification
> labs. Unfortunately it is not exactly cheap - if you are not going to prepare your
> product for certification, the SDR approach is affordable and good enough.
>
>> Thanks,
>> Ben
>>
> Good luck,
> Zefir
>
> [1] https://www.ettus.com/product/details/UN200-KIT
> [2] https://github.com/zefir-kurtisi/USRP-Radar-Relay
> [3]
> https://www.rohde-schwarz.com/us/product/smbv100a-productstartpage_63493-10220.html
>
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Markus Heiser @ 2016-10-22 16:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jani Nikula, Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <1477084793.4068.63.camel@sipsolutions.net>
Am 21.10.2016 um 23:19 schrieb Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2016-10-21 at 18:11 +0200, Markus Heiser wrote:
>
>> Yes and No. It depends on the tools (toolchains) we want to use.
>> As far as I can see from a abstract POV it should by simple for
>> math:: / since we already use/need LaTeX for PDF, for other tools
>> I have to look.
>
> Not sure if we were talking past each other - but the pass-through is
> actually really simple - example patch below.
Yeah, I thought something similar. But is the import of the extension
a sufficient criteria?
About ".. math::"; I guess we have to check if math extension AND
pdflatex is installed.
What do you suppose?
(ATM my comments on this are superficial, sorry that I haven't not
yet fond the time, to look closer into all these generators).
--Markus--
>
> This makes it output an SVG (with fallback to PNG even) into the HTML,
> a PDF into the PDF, and plain pre-formatted text for both when the
> plantuml sphinx plugin isn't installed.
>
> johannes
>
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index bf6f310e5170..2c00ab6f0baf 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -34,7 +34,8 @@ from load_config import loadConfig
> # Add any Sphinx extension module names here, as strings. They can be
> # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> # ones.
> -extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain']
> +extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain',
> + 'plantuml']
>
> # The name of the math extension changed on Sphinx 1.4
> if minor > 3:
> @@ -494,6 +495,9 @@ pdf_documents = [
> kerneldoc_bin = '../scripts/kernel-doc'
> kerneldoc_srctree = '..'
>
> +plantuml_output_format = "svg"
> +plantuml_latex_output_format = "pdf"
> +
> # ------------------------------------------------------------------------------
> # Since loadConfig overwrites settings from the global namespace, it has to be
> # the last statement in the conf.py file
> diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
> index 8e259c5d0322..e0d4f24b6039 100644
> --- a/Documentation/driver-api/index.rst
> +++ b/Documentation/driver-api/index.rst
> @@ -7,6 +7,12 @@ of device drivers. This document is an only somewhat organized collection
> of some of those interfaces — it will hopefully get better over time! The
> available subsections can be seen below.
>
> +.. uml::
> +
> + Alice -> Bob: Hi!
> + Alice <- Bob: How are you?
> +
> +
> .. class:: toc-title
>
> Table of contents
> diff --git a/Documentation/sphinx/dummy.py b/Documentation/sphinx/dummy.py
> new file mode 100644
> index 000000000000..cfac42886ebd
> --- /dev/null
> +++ b/Documentation/sphinx/dummy.py
> @@ -0,0 +1,24 @@
> +from sphinx.util.compat import Directive
> +from docutils import nodes
> +from docutils.parsers.rst import directives
> +
> +class IgnoreOptions(object):
> + def __getitem__(self, key):
> + return directives.unchanged
> +
> +def create_setup(directives):
> + def setup(app):
> + for d in directives:
> + class TextDirective(Directive):
> + has_content = True
> + option_spec = IgnoreOptions()
> +
> + def run(self):
> + text = '\n'.join(self.content)
> + return [nodes.literal_block('', text,
> + classes=['code',
> + 'missing-plugin',
> + 'missing-plugin-%s' % d])]
> +
> + app.add_directive(d, TextDirective)
> + return setup
> diff --git a/Documentation/sphinx/plantuml.py b/Documentation/sphinx/plantuml.py
> new file mode 100644
> index 000000000000..0007bc7f24fd
> --- /dev/null
> +++ b/Documentation/sphinx/plantuml.py
> @@ -0,0 +1,7 @@
> +# -*- coding: utf-8 -*-
> +from dummy import create_setup
> +
> +try:
> + from sphinxcontrib.plantuml import *
> +except:
> + setup = create_setup(['uml'])
^ permalink raw reply
* cookie_counter in wiphy object
From: Arend van Spriel @ 2016-10-22 19:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
Hi Johannes,
Since commit a442b761b24b ("cfg80211: add add_nan_func / del_nan_func")
there is a cookie_counter in the wiphy object. It is only used by the
add_nan_func now, but do we want to consolidate all cookie returning
functions to use this cookie counter, eg. in .remain_on_channel callback.
Regards,
Arend
^ permalink raw reply
* Re: crypto: aesni - add ccm(aes) algorithm implementation
From: Christian Lamparter @ 2016-10-22 19:15 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, Yauhen Kharuzhy
In-Reply-To: <3e0552f3-b7f5-2ff3-1f63-9001bceb96f0@candelatech.com>
On Wednesday, October 19, 2016 9:39:49 AM CEST Ben Greear wrote:
> On 10/19/2016 09:37 AM, greearb@candelatech.com wrote:
> > From: Yauhen Kharuzhy <jekhor@gmail.com>
> >
> > Add ccm(aes) implementation from linux-wireless mailing list (see
> > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
> >
> > This eliminates FPU context store/restore overhead existing in more
> > general ccm_base(ctr(aes-aesni),aes-aesni) case in MAC calculation.
> >
> > Convert this patch to new AEAD API.
> >
> > Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> > Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> I've been using this patch or something similar for a while and it
> significantly helps me with sw-crypt performance. One version or another
> has been around the internet for some time, and I am not the originator
> of this code, but would still be happy to see it upstream if someone
> can review and bless it.
No. I don't think this will ever fly by the crypto folks in this
form due to the CRYPTO_ALGO_ASYNC fallback parts which are necessary
to get it to work with mac80211.
It would be a great if mac80211 would do to the encryption and
decryption asynchronously. As this would work for other ciphers
and also allows crypto offload to dedicated crypto hardware.
Regards,
Christian
^ permalink raw reply
* Re: [PATCH v3 3/9] cfg80211: add add_nan_func / del_nan_func
From: Arend van Spriel @ 2016-10-22 19:17 UTC (permalink / raw)
To: johannes
Cc: Luca Coelho, linux-wireless, ayala.beker, andrei.otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160920143121.28247-4-luca@coelho.fi>
On 20-09-16 16:31, Luca Coelho wrote:
> + .flags = GENL_ADMIN_PERM,
Hi Johannes,
Recently the nl80211_ops flags were changed to GENL_UNS_ADMIN_PERM so
should the NAN commands use that as well?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v3 3/9] cfg80211: add add_nan_func / del_nan_func
From: Johannes Berg @ 2016-10-22 20:24 UTC (permalink / raw)
To: Arend van Spriel
Cc: Luca Coelho, linux-wireless, ayala.beker, andrei.otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <6fb30815-b8c8-aff4-86af-d7f496da91b5@broadcom.com>
On Sat, 2016-10-22 at 21:17 +0200, Arend van Spriel wrote:
> On 20-09-16 16:31, Luca Coelho wrote:
> >
> > + .flags = GENL_ADMIN_PERM,
> Recently the nl80211_ops flags were changed to GENL_UNS_ADMIN_PERM so
> should the NAN commands use that as well?
The dangers of having such code non-upstream for too long...
It probably doesn't really matter, since most namespace uses are
probably hwsim where this isn't available, but yeah, I guess it should
be allowed to a namespace owner since he already "owns" the device if
it's in the namespace.
johannes
^ permalink raw reply
* Re: cookie_counter in wiphy object
From: Johannes Berg @ 2016-10-22 20:26 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <0e3d457d-b0d1-f2b1-b18b-3f7b3e95365c@broadcom.com>
> Since commit a442b761b24b ("cfg80211: add add_nan_func /
> del_nan_func")
> there is a cookie_counter in the wiphy object. It is only used by the
> add_nan_func now, but do we want to consolidate all cookie returning
> functions to use this cookie counter, eg. in .remain_on_channel
> callback.
We probably could now. We used to use pointers and various other kinds
of crappy things for the cookies, but the counters are much safer,
reliable, and easier to debug. Naturally, it fell out that then the
cookies would be assigned in the drivers (well, mac80211), but here I
asked that be changed - I wouldn't mind changing it for other things as
well.
johannes
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-22 20:30 UTC (permalink / raw)
To: Markus Heiser; +Cc: Jani Nikula, Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <A533ED1D-9F0F-420D-9835-723F33D6CA83@darmarit.de>
On Sat, 2016-10-22 at 18:37 +0200, Markus Heiser wrote:
> Yeah, I thought something similar. But is the import of the extension
> a sufficient criteria?
>
> About ".. math::"; I guess we have to check if math extension AND
> pdflatex is installed.
>
> What do you suppose?
TBH, I only considered this briefly, but decided that somebody who went
to the effort of installing the sphinx extension would likely not mind
to get a subsequent error when it tries to use something that's not
installed.
I was, in fact, quite surprised that I even could install (on Debian)
the plantuml sphinx extension without plantuml, which seems odd.
In fact, I think it would be *preferable* to only check the extension ;
we should print a message from the dummy plugin to let them know what
extensions they need, and if they then go to the effort of installing
it they probably don't just not mind getting errors on dependencies,
but actually would *prefer* that, since otherwise it can be daunting to
try to figure out what *else* you actually have to install.
johannes
^ permalink raw reply
* Re: crypto: aesni - add ccm(aes) algorithm implementation
From: Johannes Berg @ 2016-10-22 20:31 UTC (permalink / raw)
To: Christian Lamparter, Ben Greear; +Cc: linux-wireless, Yauhen Kharuzhy
In-Reply-To: <4298972.T1UOBYP9Tx@debian64>
On Sat, 2016-10-22 at 21:15 +0200, Christian Lamparter wrote:
>
> It would be a great if mac80211 would do to the encryption and
> decryption asynchronously. As this would work for other ciphers
> and also allows crypto offload to dedicated crypto hardware.
The only problem with that is that we'd essentially need a software
queue for *all* frames, and release them from there in RX order after
decrypt. That's surely doable, but so far nobody has thought it
important enough since mostly HW crypto is used ...
johannes
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Johannes Berg @ 2016-10-22 20:34 UTC (permalink / raw)
To: Antonio Quartulli, ath9k-devel; +Cc: linux-wireless, sw, Antonio Quartulli
In-Reply-To: <20161022134222.GQ12558@prodigo.lan>
> "The patch itself has (at least) one big problem. It is using some
> mac80211
> internals in ath_key_config_iter to make sure that the uploaded keys
> were
> actually programmed in the hardware. Without this check the keys
> could end up
> in the lower slots and thus break all connections."
The KEY_FLAG_UPLOADED_TO_HARDWARE use? Might not be so nice, but it's
probably not really a problem. If you wanted to avoid it, you could
just use the hw_key_idx in some way, e.g. the highest-order bit
indicates that you've set this value, or you just make sure that 0 is
an invalid value and set it to real index + 1 or something, then you
can check that?
johannes
^ 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