* Re: [PATCH] mwifiex: handle edmac vendor command
From: Kalle Valo @ 2016-09-07 11:27 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org
In-Reply-To: <2320ad20-164e-12c5-0b01-9612a1d24300@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> writes:
> On 1-9-2016 16:53, Kalle Valo wrote:
>
>> Sorry for the delay. I have been thinking about vendor commands quite a
>> lot and I don't think they belong to upstream drivers. For regular use
>> cases (used by normal users) we have nl80211, for developer and testing
>> purposes we have debugfs and for manufacturing type of tests we have
>> nl80211 testmode interface. The focus of development should be adding
>> new functionality to nl80211 (and other generic interfaces), not to
>> driver specific vendor commands.
>>
>> I know brcm80211 and ti's wlcore have few vendor commands but I'm hoping
>> to remove them sometime soon.
>>
>> Thoughts?
>
> Grabbing the original commit message for vendor commands:
>
> commit ad7e718c9b4f717823fd920a0103f7b0fb06183f
> Author: Johannes Berg <johannes.berg@intel.com>
> Date: Wed Nov 13 13:37:47 2013 +0100
>
> nl80211: vendor command support
>
> Add support for vendor-specific commands to nl80211. This is
> intended to be used for really vendor-specific functionality
> that can't be implemented in a generic fashion for any reason.
> It's *NOT* intended to be used for any normal/generic feature
> or any optimisations that could be implemented across drivers.
>
> I agree that the effort needs to be made to come up with a solution that
> is usable by (most of) all drivers in the upstream wireless subsystem.
>
> The thing with the test mode is that you need to enable it in Kconfig.
And that's on purpose. We did not want testmode to be enabled on distro
kernels, for example.
> We have 1 vendor command in brcmfmac and it used to be under testmode
> api. However, because of the Kconfig thing it would mean we need a
> different kernel to do manufacturing testing. Especially when the
> modules are built-in. The OEMs typically don't like that as they want to
> do the testing using the same kernel as what ends up in the product.
> This was our motivation to use the vendor command when that was added.
Is there a specific reason why you can't keep the testmode always
enabled? Then you would have the same kernel both in manufacturing and
in "normal mode".
> It does have a nasty side-effect that some will see it as a drop-in
> replacement of the driver private ioctl-s. To some extent (as mentioned
> in the commit message above) that should be fine, but we need to make a
> good effort to move things to nl80211.
Sorry, but I'm way too cynical to buy that :) A "good effort" means that
in most of cases it will never happen. Once the vendor command is
accepted into upsteam trees the developer will lose any interest on
trying to make it a generic interface. That's just how humans work,
including me.
I do see your and Amitkumar's point how much easier the vendor commands
make it to implement new driver features and part of me also wants that.
I just think that in the long run that's detrimental for Linux wireless
and we end up into having multiple drivers having same features enabled
via different vendor commands.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rsi: code clean-up
From: Julian Calaby @ 2016-09-07 11:23 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, Kalle Valo,
שרי שרון,
Emmanuel Grumbach, Nicholas Mc Guire, xypron.glpk,
SF Markus Elfring, johannes.berg@intel.com
In-Reply-To: <259efb66-b577-b6c1-a6af-2b27f8bbc1a4@redpinesignals.com>
Hi,
On Wed, Sep 7, 2016 at 8:26 PM, Prameela Rani Garnepudi
<prameela.garnepudi@redpinesignals.com> wrote:
> From 0c3da95dfac07df5dffb5e00bcd8a38f2f8491c9 Mon Sep 17 00:00:00 2001
> From: Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com>
> Date: Wed, 7 Sep 2016 15:28:43 +0530
> Subject: [PATCH] rsi: code clean-up
Describe what the changes are achieving.
You're also still sending this as a HTML email, there are instructions
on how to configure your email client to send plain text emails here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/email-clients.txt
Because you're sending multi-part HTML emails, your emails are being
rejected by the mailing list.
> Signed-off-by: Prameela Rani Garnepudi
> <prameela.garnepudi@redpinesignals.com>
> ---
> drivers/net/wireless/rsi/rsi_91x_core.c | 18 ++--
> drivers/net/wireless/rsi/rsi_91x_debugfs.c | 13 +--
> drivers/net/wireless/rsi/rsi_91x_mac80211.c | 81 +++++++++------
> drivers/net/wireless/rsi/rsi_91x_main.c | 16 ++-
> drivers/net/wireless/rsi/rsi_91x_mgmt.c | 155
> +++++++++++-----------------
> drivers/net/wireless/rsi/rsi_91x_sdio.c | 14 +--
> drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 11 +-
> drivers/net/wireless/rsi/rsi_91x_usb.c | 34 ++++--
> drivers/net/wireless/rsi/rsi_common.h | 2 +-
> drivers/net/wireless/rsi/rsi_debugfs.h | 3 +-
> drivers/net/wireless/rsi/rsi_main.h | 36 ++++---
> drivers/net/wireless/rsi/rsi_mgmt.h | 54 +++++-----
> drivers/net/wireless/rsi/rsi_sdio.h | 18 ++--
> 13 files changed, 228 insertions(+), 227 deletions(-)
You're doing a lot of stuff here, you really need to split this up
into several patches, e.g.
1. Fix the spelling mistakes
2. Add the new debug messages
etc. etc. etc.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH] mwifiex: handle edmac vendor command
From: Kalle Valo @ 2016-09-07 10:59 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <f827ba80b79646fd8711e1a00c2b8394@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
>> > There is something called energy detect mode. Chip can detect non-WiFi
>> > radio signal also and monitor it for specified time before
>> > transmitting frames. As per ETSI specification, enabling this mode is
>> > mandatory for some countries for certain frequencies.
>>
>> To me this looks this is something which can be generic, not a driver
>> specific interface. And why can't regulatory code enable this
>> automatically, without any user involvement? It already knows what
>> country we are in.
>
> Got it. I will check if we can make this as generic as you mentioned
> and explore the option.
Thanks. Please let us know how it goes.
--
Kalle Valo
^ permalink raw reply
* RE: mwifiex: PCIe8997 chip specific handling
From: Amitkumar Karwar @ 2016-09-07 10:13 UTC (permalink / raw)
To: Steve deRosier
Cc: Brian Norris, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, linux-kernel@vger.kernel.org, Wei-Ning Huang
In-Reply-To: <0fb73fc01e7443d9afe550ca51505005@SC-EXCH04.marvell.com>
SGkgS2FsbGUsDQoNCj4gRnJvbTogbGludXgtd2lyZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3Jn
IFttYWlsdG86bGludXgtd2lyZWxlc3MtDQo+IG93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVo
YWxmIE9mIEFtaXRrdW1hciBLYXJ3YXINCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAx
NiA0OjExIFBNDQo+IFRvOiBTdGV2ZSBkZVJvc2llcg0KPiBDYzogQnJpYW4gTm9ycmlzOyBsaW51
eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IENhdGh5IEx1bzsgTmlzaGFudA0KPiBTYXJtdWth
ZGFtOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBXZWktTmluZyBIdWFuZw0KPiBTdWJq
ZWN0OiBSRTogbXdpZmlleDogUENJZTg5OTcgY2hpcCBzcGVjaWZpYyBoYW5kbGluZw0KPiANCj4g
SGkgU3RldmUsDQo+IA0KPiA+IEZyb206IFN0ZXZlIGRlUm9zaWVyIFttYWlsdG86ZGVyb3NpZXJA
Z21haWwuY29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTYgMjozOSBBTQ0K
PiA+IFRvOiBBbWl0a3VtYXIgS2Fyd2FyDQo+ID4gQ2M6IEJyaWFuIE5vcnJpczsgbGludXgtd2ly
ZWxlc3NAdmdlci5rZXJuZWwub3JnOyBDYXRoeSBMdW87IE5pc2hhbnQNCj4gPiBTYXJtdWthZGFt
OyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBXZWktTmluZyBIdWFuZw0KPiA+IFN1Ympl
Y3Q6IFJlOiBtd2lmaWV4OiBQQ0llODk5NyBjaGlwIHNwZWNpZmljIGhhbmRsaW5nDQo+ID4NCj4g
PiBIaSwNCj4gPg0KPiA+IE9uIFdlZCwgQXVnIDEwLCAyMDE2IGF0IDEyOjA3IEFNLCBBbWl0a3Vt
YXIgS2Fyd2FyDQo+ID4gPGFrYXJ3YXJAbWFydmVsbC5jb20+DQo+ID4gd3JvdGU6DQo+ID4gPiBI
aSBCcmlhbiwNCj4gPiA+DQo+ID4gPj4gRnJvbTogQnJpYW4gTm9ycmlzIFttYWlsdG86YnJpYW5u
b3JyaXNAY2hyb21pdW0ub3JnXQ0KPiA+ID4+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDEwLCAy
MDE2IDEyOjE0IEFNDQo+ID4gPj4gVG86IEFtaXRrdW1hciBLYXJ3YXINCj4gPiA+PiBDYzogbGlu
dXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnOyBDYXRoeSBMdW87IE5pc2hhbnQgU2FybXVrYWRh
bTsNCj4gPiA+PiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+ID4gPj4gU3ViamVjdDog
UmU6IG13aWZpZXg6IFBDSWU4OTk3IGNoaXAgc3BlY2lmaWMgaGFuZGxpbmcNCj4gPiA+Pg0KPiA+
ID4+IEhpLA0KPiA+ID4+DQo+ID4gPj4gT24gRnJpLCBKdWwgMjksIDIwMTYgYXQgMDQ6MDg6NTFQ
TSArMDUzMCwgQW1pdGt1bWFyIEthcndhciB3cm90ZToNCj4gPiA+PiA+IFRoZSBwYXRjaCBjb3Jy
ZWN0cyB0aGUgcmV2aXNpb24gaWQgcmVnaXN0ZXIgYW5kIHVzZXMgaXQgYWxvbmcNCj4gPiA+PiA+
IHdpdGggbWFnaWMgdmFsdWUgYW5kIGNoaXAgdmVyc2lvbiByZWdpc3RlcnMgdG8gZG93bmxvYWQN
Cj4gPiA+PiA+IGFwcHJvcHJpYXRlIGZpcm13YXJlIGltYWdlLg0KPiA+ID4+ID4NCj4gPiA+PiA+
IFBDSWU4OTk3IFogY2hpcHNldCB2YXJpYW50IGNvZGUgaGFzIGJlZW4gcmVtb3ZlZCwgYXMgaXQg
d29uJ3QgYmUNCj4gPiA+PiA+IHVzZWQgaW4gcHJvZHVjdGlvbi4NCj4gPiA+PiA+DQo+ID4gPj4g
PiBTaWduZWQtb2ZmLWJ5OiBBbWl0a3VtYXIgS2Fyd2FyIDxha2Fyd2FyQG1hcnZlbGwuY29tPg0K
PiA+ID4+ID4gLS0tDQo+ID4gPj4gPiAgZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lm
aWV4L3BjaWUuYyB8IDM1DQo+ID4gPj4gPiArKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
PiA+ID4+ID4gZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3BjaWUuaCB8IDE0
ICsrKysrLS0tLS0tLQ0KPiA+ID4+ID4gIDIgZmlsZXMgY2hhbmdlZCwgMTggaW5zZXJ0aW9ucygr
KSwgMzEgZGVsZXRpb25zKC0pDQo+ID4gPj4NCj4gPiA+PiBbLi4uXQ0KPiA+ID4+DQo+ID4gPj4g
PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3BjaWUu
aA0KPiA+ID4+ID4gYi9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvcGNpZS5o
DQo+ID4gPj4gPiBpbmRleCBmNjk5MmYwLi40NmY5OWNhIDEwMDY0NA0KPiA+ID4+ID4gLS0tIGEv
ZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3BjaWUuaA0KPiA+ID4+ID4gKysr
IGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3BjaWUuaA0KPiA+ID4+ID4g
QEAgLTMyLDEyICszMiw5IEBADQo+ID4gPj4gPiAgI2RlZmluZSBQQ0lFODg5N19ERUZBVUxUX0ZX
X05BTUUgIm1ydmwvcGNpZTg4OTdfdWFwc3RhLmJpbiINCj4gPiA+PiA+ICAjZGVmaW5lIFBDSUU4
ODk3X0EwX0ZXX05BTUUgIm1ydmwvcGNpZTg4OTdfdWFwc3RhX2EwLmJpbiINCj4gPiA+PiA+ICAj
ZGVmaW5lIFBDSUU4ODk3X0IwX0ZXX05BTUUgIm1ydmwvcGNpZTg4OTdfdWFwc3RhLmJpbiINCj4g
PiA+PiA+IC0jZGVmaW5lIFBDSUU4OTk3X0RFRkFVTFRfRldfTkFNRSAibXJ2bC9wY2lldXNiODk5
N19jb21ib192Mi5iaW4iDQo+ID4gPj4gPiAtI2RlZmluZSBQQ0lFVUFSVDg5OTdfRldfTkFNRV9a
ICJtcnZsL3BjaWV1YXJ0ODk5N19jb21iby5iaW4iDQo+ID4gPj4gPiAtI2RlZmluZSBQQ0lFVUFS
VDg5OTdfRldfTkFNRV9WMiAibXJ2bC9wY2lldWFydDg5OTdfY29tYm9fdjIuYmluIg0KPiA+ID4+
ID4gLSNkZWZpbmUgUENJRVVTQjg5OTdfRldfTkFNRV9aICJtcnZsL3BjaWV1c2I4OTk3X2NvbWJv
LmJpbiINCj4gPiA+PiA+IC0jZGVmaW5lIFBDSUVVU0I4OTk3X0ZXX05BTUVfVjIgIm1ydmwvcGNp
ZXVzYjg5OTdfY29tYm9fdjIuYmluIg0KPiA+ID4+ID4gLSNkZWZpbmUgUENJRTg5OTdfREVGQVVM
VF9XSUZJRldfTkFNRSAibXJ2bC9wY2llODk5N193bGFuLmJpbiINCj4gPiA+PiA+ICsjZGVmaW5l
IFBDSUVVQVJUODk5N19GV19OQU1FX1Y0ICJtcnZsL3BjaWV1YXJ0ODk5N19jb21ib192NC5iaW4i
DQo+ID4gPj4gPiArI2RlZmluZSBQQ0lFVVNCODk5N19GV19OQU1FX1Y0ICJtcnZsL3BjaWV1c2I4
OTk3X2NvbWJvX3Y0LmJpbiINCj4gPiA+PiA+ICsjZGVmaW5lIFBDSUU4OTk3X0RFRkFVTFRfV0lG
SUZXX05BTUUgIm1ydmwvcGNpZTg5OTdfd2xhbl92NC5iaW4iDQo+ID4gPj4NCj4gPiA+PiBXaHkg
ZG8gdmVyc2lvbiBidW1wcyByZXF1aXJlIGZpcm13YXJlIHJlbmFtZXM/IElzIHRoaXMganVzdCB0
byBtYWtlDQo+ID4gPj4gc3VyZSB5b3UgZG9uJ3QgbG9hZCB0aGUgbmV3IGZpcm13YXJlIG9uIG9s
ZCBjaGlwIHJldnMgdGhhdCB5b3UNCj4gPiA+PiBkb24ndCBwbGFuIHRvIHN1cHBvcnQgZm9yIHBy
b2R1Y3Rpb24gKGkuZS4sIG9ubHkgZWFybHkgcmV2cyBsaWtlDQo+ID4gPj4gdGhlIF9aIHlvdSdy
ZSBkcm9wcGluZyk/IFRoaXMgZG9lc24ndCBzZWVtcyBsaWtlIGEgZ29vZCBsb25nLXRlcm0NCj4g
PiA+PiBzb2x1dGlvbiwgYXQgbGVhc3Qgb25jZSB5b3Ugc3RhcnQgZ2V0dGluZyB0aGlzIHNpbGlj
b24gb3V0IGluIHRoZQ0KPiA+ID4+IHdpbGQuIEF0IHNvbWUgcG9pbnQsIEknZCBleHBlY3QgdG8g
c2VlIGEgc3RhYmxlIGZpbGUgbmFtZS4NCj4gPiA+Pg0KPiA+ID4+IEJyaWFuDQo+ID4gPj4NCj4g
PiA+DQo+ID4gPiBXZSBoYXZlbid0IHlldCBzdWJtaXR0ZWQgYW55IGZpcm13YXJlIGltYWdlIHVw
c3RyZWFtIGZvciA4OTk3DQo+IGNoaXBzZXQuDQo+ID4gPiBwY2lldWFydDg5OTdfY29tYm9fdjQu
YmluL3BjaWV1c2I4OTk3X2NvbWJvX3Y0LmJpbiB3b3VsZCBiZSBvdXINCj4gPiBmaXJtd2FyZSBj
YW5kaWRhdGUgZm9yIHVwc3RyZWFtIHN1Ym1pc3Npb24uIFRoZSBmaWxlbmFtZSB3b3VsZCByZW1h
aW4NCj4gPiBzYW1lIGhlcmVhZnRlci4NCj4gPiA+DQo+ID4gPiBwY2llKjg5OTdfY29tYm9fdjIu
YmluIGhhZCBzdXBwb3J0IG9ubHkgZm9yIEEwIGNoaXBzZXQNCj4gPiA+IHBjaWUqODk5N19jb21i
b192My5iaW4gd2FzIG91ciBpbnRlcm5hbCBkZXZlbG9wbWVudCB2ZXJzaW9uIHdoaWNoDQo+ID4g
PiBoYWQgc3VwcG9ydCBmb3IgQTEgY2hpcHNldCBwY2llKjg5OTdfY29tYm9fdjQuYmluIGhhcyBz
dXBwb3J0IGZvcg0KPiA+ID4gYm90aCBBMA0KPiA+IGFuZCBBMSBjaGlwc2V0cyBhbmQgdGhpcyBp
cyB0aGUgdmVyc2lvbiB0aGF0IHNoYWxsIGJlIHJlbGVhc2VkIHRvDQo+ID4gY3VzdG9tZXJzL3Vw
c3RyZWFtIGZyb20gbm93IG9uLg0KPiA+ID4NCj4gPg0KPiA+IFNlZW1zIHRvIG1lIHRoZW4gaXQg
c2hvdWxkIGp1c3QgYmUgbmFtZWQgcGNpZSo4OTk3X3dsYW4uYmluLiAgQQ0KPiA+IHZlcnNpb24g
bnVtYmVyIHNob3VsZG4ndCBiZSBwYXJ0IG9mIHRoZSBmaWxlIG5hbWUgaW4gdGhpcyBjYXNlLiBI
YXZpbmcNCj4gPiB0byB1cGRhdGUgdGhlIGRyaXZlciBmb3IgYSBmaXJtd2FyZSBuYW1lIGNoYW5n
ZSBpcyBzaWxseS4gTW9zdA0KPiA+IHdpcmVsZXNzIGRyaXZlcnMgaGF2ZSBkaWZmZXJlbnQgbmFt
ZXMgZm9yIGRpZmZlcmVudCBoYXJkd2FyZS9jaGlwIHJldnMNCj4gPiBhbmQvb3IgYW4gaW5jb21w
YXRpYmxlIEFQSSBjaGFuZ2UuICBNb3N0IGRpc3RyaWJ1dGlvbnMgd291bGQgdHlwaWNhbGx5DQo+
ID4gb25seSBjYXJyeSBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUgZmlybXdhcmUgZm9yIGEgcGFy
dGljdWxhciBjaGlwLg0KPiA+IFNwZWFraW5nIGZvciB0aGUgb25lcyBJIHdvcmsgd2l0aCwgSSB1
c3VhbGx5IGtlZXAgdGhlIG9yaWdpbmFsDQo+ID4gZmlsZW5hbWUgaW50YWN0ICh3aXRoIGEgdmVy
c2lvbiBudW1iZXIpIGFuZCBtYWtlIGEgc3ltbGluayB0byBpdCB3aXRoDQo+ID4gdGhlIG5hbWUg
dGhlIGRyaXZlciBleHBlY3RzLiAgZWc6DQo+ID4NCj4gPiBmdy00LmJpbiAtPiBmd192My40LjAu
OTQuYmluDQo+ID4gZndfdjMuMi4wLjE0NC5iaW4NCj4gPiBmd192My40LjAuOTQuYmluDQo+ID4N
Cj4gPiBUaGF0IHdheSBJIGNhbiBrZWVwIHRyYWNrIG9mIHRoZSB2ZXJzaW9uIGluIG15IGZpbGVz
eXN0ZW0sIGJ1dCBJJ20gbm90DQo+ID4gaGFja2luZyB0aGUgZHJpdmVyIGV2ZXJ5IGNvdXBsZSBv
ZiB3ZWVrcy4gIEFuZCB3ZSBkbyBpc3N1ZSBuZXcNCj4gPiBmaXJtd2FyZSBldmVyeSBmZXcgd2Vl
a3MuIEkgY2FuJ3QgaW1hZ2luZSBhc2tpbmcgb3VyIGN1c3RvbWVycyB0byBrZWVwDQo+ID4gdXBk
YXRpbmcgdGhlIGRyaXZlciBmb3IgZWFjaCBmaXJtd2FyZSBlbmhhbmNlbWVudC4NCj4gPg0KPiA+
IElNSE8gY2hhbmdpbmcgdGhlIGRyaXZlciB0byByZW5hbWUgdGhlIGZpcm13YXJlcyBvbiBuZXcg
dmVyc2lvbnMgc2VlbXMNCj4gPiBib3RoIGluY29udmVuaWVudCB0byBwZW9wbGUgdXNpbmcgaXQs
IGFuZCBleHRyYSBub24tdXNlZnVsIGNvbW1pdA0KPiBub2lzZS4NCj4gPg0KPiANCj4gVGhhbmtz
LiBJIGFncmVlIHdpdGggeW91LiBXZSBoYXZlIGFsc28gbWFpbnRhaW5lZCBzaW5nbGUgaW5zdGFu
Y2UvbmFtZQ0KPiBmb3IgYWxsIG91ciBjaGlwc2V0cyBmb3IgbGFzdCBmZXcgeWVhcnMuIFdlIGRv
IHJlbGVhc2UgbmV3IGZpcm13YXJlDQo+IHBlcmlvZGljYWxseSBmb3IgdGhlc2UgY2hpcHNldHMs
IGJ1dCBmaXJtd2FyZSBuYW1lIGFsd2F5cyByZW1haW5zIHRoZQ0KPiBzYW1lLg0KPiANCj4gLS0t
LS0tLS0NCj4gcm9vdEBwZS1sdDk0OTovbGludXgtZmlybXdhcmUvbXJ2bCMgbHMNCj4gcGNpZTg4
OTdfdWFwc3RhLmJpbiAgc2Q4Njg4X2hlbHBlci5iaW4gIHNkODc5N191YXBzdGEuYmluDQo+IHNk
ODg5N191YXBzdGEuYmluICAgdXNiODc5N191YXBzdGEuYmluDQo+IHNkODY4OC5iaW4gICAgICAg
ICAgIHNkODc4N191YXBzdGEuYmluICBzZDg4ODdfdWFwc3RhLmJpbg0KPiB1c2I4NzY2X3VhcHN0
YS5iaW4gIHVzYjg4OTdfdWFwc3RhLmJpbg0KPiAtLS0tLS0tLS0NCj4gDQo+IEl04oCZcyBqdXN0
IHRoYXQgZm9yIG91ciBuZXcgY2hpcHNldCA4OTk3IGZvciB3aGljaCB3ZSBoYXZlbid0IHlldA0K
PiBzdWJtaXR0ZWQgdGhlIGZpcm13YXJlIGltYWdlIHVwc3RyZWFtLCB3ZSB3YW50IHRvIGZpbmFs
aXplIHRoZSBuYW1lIGFzDQo+IHBjaWUqODk5N19jb21ib192NC5iaW4NCj4gDQoNCkNvdWxkIHlv
dSBwbGVhc2UgYWNjZXB0IHRoaXMgcGF0Y2g/DQpJIHdhbnRlZCB0byBzdWJtaXQgb3VyIGZpcnN0
IGZpcm13YXJlIGZvciA4OTk3IGNoaXBzZXQuDQoNClJlZ2FyZHMsDQpBbWl0a3VtYXIgDQo=
^ permalink raw reply
* RE: [PATCH] mwifiex: handle edmac vendor command
From: Amitkumar Karwar @ 2016-09-07 10:12 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <87d1km1hb6.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Friday, September 02, 2016 8:26 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org
> Subject: Re: [PATCH] mwifiex: handle edmac vendor command
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> >> Sorry for the delay. I have been thinking about vendor commands quite
> >> a lot and I don't think they belong to upstream drivers. For regular
> >> use cases (used by normal users) we have nl80211, for developer and
> >> testing purposes we have debugfs and for manufacturing type of tests
> >> we have
> >> nl80211 testmode interface. The focus of development should be adding
> >> new functionality to nl80211 (and other generic interfaces), not to
> >> driver specific vendor commands.
> >>
> >> I know brcm80211 and ti's wlcore have few vendor commands but I'm
> >> hoping to remove them sometime soon.
> >>
> >> Thoughts?
> >>
> >
> > Thanks for your reply.
> >
> > There is something called energy detect mode. Chip can detect non-WiFi
> > radio signal also and monitor it for specified time before
> > transmitting frames. As per ETSI specification, enabling this mode is
> > mandatory for some countries for certain frequencies.
>
> To me this looks this is something which can be generic, not a driver
> specific interface. And why can't regulatory code enable this
> automatically, without any user involvement? It already knows what
> country we are in.
>
Got it. I will check if we can make this as generic as you mentioned and explore the option.
Regards,
Amitkumar
^ permalink raw reply
* Re: Stability connection problems in ath9k kernel 4.7
From: Kalle Valo @ 2016-09-07 8:32 UTC (permalink / raw)
To: Valerio Passini; +Cc: linux-wireless
In-Reply-To: <1798564.U2X6r5Zons@automatix>
Valerio Passini <valerio.passini@unicam.it> writes:
> I have found some connection problems since 4.7 release using ath9k that turn
> the wifi pretty useless, I think it might be something in the power management
> because the signal seems really low. Previously, up to kernel 4.6.7 everything
> worked very well.
> This is a sample of dmesg in kernel 4.7.2:
> 239.898935] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
> [ 239.919995] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
> [ 239.931877] wlp4s0: authenticated
> [ 239.932357] wlp4s0: associate with XX:XX:XX:XX:XX:XX (try 1/3)
> [ 239.942171] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x431
> status=0 aid=2)
> [ 239.942301] wlp4s0: associated
> [ 244.802853] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x02000020 DMADBG_7=0x0000
> 6100
> [ 245.931832] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
> [ 245.953028] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
> [ 245.958702] wlp4s0: authenticated
> [ 245.960386] wlp4s0: associate withXX:XX:XX:XX:XX:XX (try 1/3)
> [ 245.980543] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x431
> status=0 aid=2)
>
> lspci on 4.6.7 kernel:
> 04:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter
> (rev 01)
> Subsystem: AzureWave AR9485 Wireless Network Adapter
> Flags: bus master, fast devsel, latency 0, IRQ 18
> Memory at f7900000 (64-bit, non-prefetchable) [size=512K]
> Expansion ROM at f7980000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 2
> Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
> Kernel driver in use: ath9k
> Kernel modules: ath9k
>
> Probably you need some debugging output, but before recompiling the kernel I
> would like to know if you are interested in any kind of help from me and what
> steps I should take (I'm able to help in testing patches but I'm not familiar
> with git). Thank you
Usually it's really helpful if you can find the commit id which broke
it. 'git bisect' is a great tool to do that and this seems to be a nice
tutorial how to use it:
http://webchick.net/node/99
Instead of commit ids you can use release tags like v4.6 and v4.7 to
make it easier to start the bisect. Just make sure that v4.7 is really
broken and v4.6 works before you start the bisection.
--
Kalle Valo
^ permalink raw reply
* Re: Debugging RTL8192CU firmware loading on 3.12 powerpc
From: Simon Wunderlich @ 2016-09-07 8:23 UTC (permalink / raw)
To: Larry Finger; +Cc: Sven Eckelmann, linux-wireless, Pannirselvam Kanagaratnam
In-Reply-To: <1d72a2ac-03e7-37d8-c367-68413595443e@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]
On Tuesday, September 6, 2016 8:29:32 AM CEST Larry Finger wrote:
> On 09/06/2016 08:09 AM, Sven Eckelmann wrote:
> > On Dienstag, 6. September 2016 09:40:41 CEST Sven Eckelmann wrote:
> >> On Freitag, 2. September 2016 12:53:28 CEST Larry Finger wrote:
> >> [...]
> >>
> >>> The patch I included in my previous E-mail, and attached here, does get
> >>> the firmware loaded correctly. There is still a problem that prevents
> >>> authentication. I'm still looking for that issue.
> >>
> >> Thanks for the fast update. I am currently testing your patch. It looks
> >> like the initial error is now gone. The hostapd also starts but
> >> beaconing doesn't seem to work at all (no error from the kernel/hostapd
> >> but the device is not sending anything). I am currently checking how
> >> beaconing is supposed to work in your driver. Maybe I will spot
> >> something useful.>
> > Yes, found something similar in the checksumming algorithm. See the
> > attached patch for details.
>
> Just for the record, this is not "my" driver. It was provided by Realtek. My
> contribution has only been to clean it up.
>
> Thanks for the patch. I too had found that checksum code, but I had not sent
> it as there are still problems on BE machines. These difficulties are
> running the NIC in STA mode. I have not tried AP mode. Scan data seem to be
> read OK, but it never authenticates. I do not know if there are further
> errors in setting up the transmit buffer, or if the problem is in the
> encryption/decryption code. I'm still looking.
just as a connected question here - do you know if those devices support
MultiSSID? The capabilities currently don't allow that, but I'm wondering if
that could be implemented, or if there are any hardware/firmware limitations?
Thanks,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Stability connection problems in ath9k kernel 4.7
From: Valerio Passini @ 2016-09-07 7:49 UTC (permalink / raw)
To: linux-wireless
Hello,
I have found some connection problems since 4.7 release using ath9k that turn
the wifi pretty useless, I think it might be something in the power management
because the signal seems really low. Previously, up to kernel 4.6.7 everything
worked very well.
This is a sample of dmesg in kernel 4.7.2:
239.898935] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
[ 239.919995] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
[ 239.931877] wlp4s0: authenticated
[ 239.932357] wlp4s0: associate with XX:XX:XX:XX:XX:XX (try 1/3)
[ 239.942171] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x431
status=0 aid=2)
[ 239.942301] wlp4s0: associated
[ 244.802853] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x02000020 DMADBG_7=0x0000
6100
[ 245.931832] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
[ 245.953028] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
[ 245.958702] wlp4s0: authenticated
[ 245.960386] wlp4s0: associate withXX:XX:XX:XX:XX:XX (try 1/3)
[ 245.980543] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x431
status=0 aid=2)
lspci on 4.6.7 kernel:
04:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter
(rev 01)
Subsystem: AzureWave AR9485 Wireless Network Adapter
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at f7900000 (64-bit, non-prefetchable) [size=512K]
Expansion ROM at f7980000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: ath9k
Kernel modules: ath9k
Probably you need some debugging output, but before recompiling the kernel I
would like to know if you are interested in any kind of help from me and what
steps I should take (I'm able to help in testing patches but I'm not familiar
with git). Thank you
Valerio
^ permalink raw reply
* Re: [PATCH 0/5] Some cleanup patches for drivers/staging/rtl8723au/core/rtw_mlme.c
From: Matthias Beyer @ 2016-09-07 7:43 UTC (permalink / raw)
To: Jes Sorensen
Cc: gregkh, Larry Finger, Manuel Messner, Geliang Tang,
Cihangir Akturk, linux-wireless, devel, linux-kernel
In-Reply-To: <wrfjshtdyq56.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
On 06-09-2016 12:00:37, Jes Sorensen wrote:
> Matthias Beyer <mail@beyermatthias.de> writes:
> > This patchset fixes some errors and warnings reported by checkpatch.pl.
> >
> > Matthias Beyer (5):
> > drivers: staging: rtl8723au: core: Fix checkpatch.pl errors
> > drivers: staging: rtl8723au: core: simplify if-break-else
> > drivers: staging: rtl8723au: core: Refactor pointless branching
> > drivers: staging: rtl8723au: core: Fix "space prohibited" warning
> > drivers: staging: rtl8723au: core: Fix indentation
> >
> > drivers/staging/rtl8723au/core/rtw_mlme.c | 72 ++++++++++++++-----------------
> > 1 file changed, 33 insertions(+), 39 deletions(-)
>
> Nothing wrong with these patches, however I intend to post a patch to
> remove this driver soon, so it's kind of a waste of your time to spend
> too many cycles on it.
>
Alright, thanks for telling me, I won't waste any more time on it.
Besides that - thanks for telling me that the patchset is okay as-is.
That keeps me motivated!
--
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer
Proudly sent with mutt.
Happily signed with gnupg.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [Patch] Wireless Driver rsi changes: Firmware loading and device initialization changed for RSI-91x devices
From: Julian Calaby @ 2016-09-07 5:46 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: Kalle Valo, שרי שרון,
Emmanuel Grumbach, Nicholas Mc Guire, xypron.glpk,
SF Markus Elfring, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <dcbe3a5b-780f-f508-b37d-8e2ef86787e3@redpinesignals.com>
Hi,
On Wed, Sep 7, 2016 at 3:34 PM, Prameela Rani Garnepudi
<prameela.garnepudi@redpinesignals.com> wrote:
>
> Hi,
>
> Please verify the attached patch which would need to be merged into the
> main-line kernel. This patch contains the changes for Redpine Signals
> wireless driver under main-line kernel directory drivers/net/wireless/rsi.
Please submit your patches as described in
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
You need to:
1. Send the patch in a plain text email
2. Have the patch be in the body of the email, not attached
3. Improve the subject as described in the linked document
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH v4 1/4] soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API
From: Andy Gross @ 2016-09-07 1:39 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, Kalle Valo, wcn36xx, linux-wireless, netdev,
linux-kernel, linux-arm-msm, Marcel Holtmann
In-Reply-To: <1473200312-22438-1-git-send-email-bjorn.andersson@linaro.org>
On Tue, Sep 06, 2016 at 03:18:29PM -0700, Bjorn Andersson wrote:
> Stub the wcnss_ctrl API to allow compile testing wcnss function drivers.
>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> There are no other pending changes colliding with this, so if Andy is okay with
> this it could be merged through Kalle's tree - together with the other patches.
>
> Marcel, with this applied we can drop the depends on QCOM_SMD from the
> btqcomsmd driver as well.
>
> Changes since v3:
> - Added this patch to allow compile testing without SMD support after patch 2
>
> include/linux/soc/qcom/wcnss_ctrl.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
This is fine.
Acked-by: Andy Gross <andy.gross@linaro.org>
^ permalink raw reply
* Re: [PATCH v4 1/4] soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API
From: Marcel Holtmann @ 2016-09-06 23:12 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Eugene Krasnikov, Kalle Valo, wcn36xx, linux-wireless,
Network Development, LKML, linux-arm-msm
In-Reply-To: <1473200312-22438-1-git-send-email-bjorn.andersson@linaro.org>
Hi Bjorn,
> Stub the wcnss_ctrl API to allow compile testing wcnss function drivers.
>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> There are no other pending changes colliding with this, so if Andy is okay with
> this it could be merged through Kalle's tree - together with the other patches.
>
> Marcel, with this applied we can drop the depends on QCOM_SMD from the
> btqcomsmd driver as well.
sounds great. As soon as this lands in net-next, then please send a patch to remove the dependency. I will pull in net-next into bluetooth-next then.
Regards
Marcel
^ permalink raw reply
* [PATCH v4 4/4] wcn36xx: Implement print_reg indication
From: Bjorn Andersson @ 2016-09-06 22:18 UTC (permalink / raw)
To: Eugene Krasnikov, Kalle Valo
Cc: wcn36xx, linux-wireless, netdev, linux-kernel, linux-arm-msm,
Andy Gross, Nicolas Dechesne
In-Reply-To: <1473200312-22438-1-git-send-email-bjorn.andersson@linaro.org>
Some firmware versions sends a "print register indication", handle this
by printing out the content.
Cc: Nicolas Dechesne <ndec@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v3:
- Rebased separate patch onto this series
drivers/net/wireless/ath/wcn36xx/hal.h | 16 ++++++++++++++++
drivers/net/wireless/ath/wcn36xx/smd.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+)
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h b/drivers/net/wireless/ath/wcn36xx/hal.h
index 4f87ef1e1eb8..b765c647319d 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -350,6 +350,8 @@ enum wcn36xx_hal_host_msg_type {
WCN36XX_HAL_AVOID_FREQ_RANGE_IND = 233,
+ WCN36XX_HAL_PRINT_REG_INFO_IND = 259,
+
WCN36XX_HAL_MSG_MAX = WCN36XX_HAL_MSG_TYPE_MAX_ENUM_SIZE
};
@@ -4703,4 +4705,18 @@ struct stats_class_b_ind {
u32 rx_time_total;
};
+/* WCN36XX_HAL_PRINT_REG_INFO_IND */
+struct wcn36xx_hal_print_reg_info_ind {
+ struct wcn36xx_hal_msg_header header;
+
+ u32 count;
+ u32 scenario;
+ u32 reason;
+
+ struct {
+ u32 addr;
+ u32 value;
+ } regs[];
+} __packed;
+
#endif /* _HAL_H_ */
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index be5e5ea1e5c3..1c2966f7db7a 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -2109,6 +2109,30 @@ static int wcn36xx_smd_delete_sta_context_ind(struct wcn36xx *wcn,
return -ENOENT;
}
+static int wcn36xx_smd_print_reg_info_ind(struct wcn36xx *wcn,
+ void *buf,
+ size_t len)
+{
+ struct wcn36xx_hal_print_reg_info_ind *rsp = buf;
+ int i;
+
+ if (len < sizeof(*rsp)) {
+ wcn36xx_warn("Corrupted print reg info indication\n");
+ return -EIO;
+ }
+
+ wcn36xx_dbg(WCN36XX_DBG_HAL,
+ "reginfo indication, scenario: 0x%x reason: 0x%x\n",
+ rsp->scenario, rsp->reason);
+
+ for (i = 0; i < rsp->count; i++) {
+ wcn36xx_dbg(WCN36XX_DBG_HAL, "\t0x%x: 0x%x\n",
+ rsp->regs[i].addr, rsp->regs[i].value);
+ }
+
+ return 0;
+}
+
int wcn36xx_smd_update_cfg(struct wcn36xx *wcn, u32 cfg_id, u32 value)
{
struct wcn36xx_hal_update_cfg_req_msg msg_body, *body;
@@ -2237,6 +2261,7 @@ int wcn36xx_smd_rsp_process(struct qcom_smd_channel *channel,
case WCN36XX_HAL_OTA_TX_COMPL_IND:
case WCN36XX_HAL_MISSED_BEACON_IND:
case WCN36XX_HAL_DELETE_STA_CONTEXT_IND:
+ case WCN36XX_HAL_PRINT_REG_INFO_IND:
msg_ind = kmalloc(sizeof(*msg_ind) + len, GFP_ATOMIC);
if (!msg_ind) {
wcn36xx_err("Run out of memory while handling SMD_EVENT (%d)\n",
@@ -2296,6 +2321,11 @@ static void wcn36xx_ind_smd_work(struct work_struct *work)
hal_ind_msg->msg,
hal_ind_msg->msg_len);
break;
+ case WCN36XX_HAL_PRINT_REG_INFO_IND:
+ wcn36xx_smd_print_reg_info_ind(wcn,
+ hal_ind_msg->msg,
+ hal_ind_msg->msg_len);
+ break;
default:
wcn36xx_err("SMD_EVENT (%d) not supported\n",
msg_header->msg_type);
--
2.5.0
^ permalink raw reply related
* [PATCH v4 3/4] wcn36xx: Implement firmware assisted scan
From: Bjorn Andersson @ 2016-09-06 22:18 UTC (permalink / raw)
To: Eugene Krasnikov, Kalle Valo
Cc: wcn36xx, linux-wireless, netdev, linux-kernel, linux-arm-msm,
Andy Gross
In-Reply-To: <1473200312-22438-1-git-send-email-bjorn.andersson@linaro.org>
Using the software based channel scan mechanism from mac80211 keeps us
offline for 10-15 second, we should instead issue a start_scan/end_scan
on each channel reducing this time.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v3:
- None
Changes since v2:
- Match prototype change of ieee80211_scan_completed()
drivers/net/wireless/ath/wcn36xx/main.c | 64 +++++++++++++++++++++++++-----
drivers/net/wireless/ath/wcn36xx/smd.c | 8 ++--
drivers/net/wireless/ath/wcn36xx/smd.h | 4 +-
drivers/net/wireless/ath/wcn36xx/txrx.c | 19 ++++++---
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 9 +++++
5 files changed, 81 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
index 3c2522b07c90..96a9584edcbb 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -568,23 +568,59 @@ out:
return ret;
}
-static void wcn36xx_sw_scan_start(struct ieee80211_hw *hw,
- struct ieee80211_vif *vif,
- const u8 *mac_addr)
+static void wcn36xx_hw_scan_worker(struct work_struct *work)
{
- struct wcn36xx *wcn = hw->priv;
+ struct wcn36xx *wcn = container_of(work, struct wcn36xx, scan_work);
+ struct cfg80211_scan_request *req = wcn->scan_req;
+ u8 channels[WCN36XX_HAL_PNO_MAX_NETW_CHANNELS_EX];
+ struct cfg80211_scan_info scan_info = {};
+ int i;
+
+ wcn36xx_dbg(WCN36XX_DBG_MAC, "mac80211 scan %d channels worker\n", req->n_channels);
+
+ for (i = 0; i < req->n_channels; i++)
+ channels[i] = req->channels[i]->hw_value;
+
+ wcn36xx_smd_update_scan_params(wcn, channels, req->n_channels);
wcn36xx_smd_init_scan(wcn, HAL_SYS_MODE_SCAN);
- wcn36xx_smd_start_scan(wcn);
+ for (i = 0; i < req->n_channels; i++) {
+ wcn->scan_freq = req->channels[i]->center_freq;
+ wcn->scan_band = req->channels[i]->band;
+
+ wcn36xx_smd_start_scan(wcn, req->channels[i]->hw_value);
+ msleep(30);
+ wcn36xx_smd_end_scan(wcn, req->channels[i]->hw_value);
+
+ wcn->scan_freq = 0;
+ }
+ wcn36xx_smd_finish_scan(wcn, HAL_SYS_MODE_SCAN);
+
+ scan_info.aborted = false;
+ ieee80211_scan_completed(wcn->hw, &scan_info);
+
+ mutex_lock(&wcn->scan_lock);
+ wcn->scan_req = NULL;
+ mutex_unlock(&wcn->scan_lock);
}
-static void wcn36xx_sw_scan_complete(struct ieee80211_hw *hw,
- struct ieee80211_vif *vif)
+static int wcn36xx_hw_scan(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_scan_request *hw_req)
{
struct wcn36xx *wcn = hw->priv;
- wcn36xx_smd_end_scan(wcn);
- wcn36xx_smd_finish_scan(wcn, HAL_SYS_MODE_SCAN);
+ mutex_lock(&wcn->scan_lock);
+ if (wcn->scan_req) {
+ mutex_unlock(&wcn->scan_lock);
+ return -EBUSY;
+ }
+ wcn->scan_req = &hw_req->req;
+ mutex_unlock(&wcn->scan_lock);
+
+ schedule_work(&wcn->scan_work);
+
+ return 0;
}
static void wcn36xx_update_allowed_rates(struct ieee80211_sta *sta,
@@ -997,8 +1033,7 @@ static const struct ieee80211_ops wcn36xx_ops = {
.configure_filter = wcn36xx_configure_filter,
.tx = wcn36xx_tx,
.set_key = wcn36xx_set_key,
- .sw_scan_start = wcn36xx_sw_scan_start,
- .sw_scan_complete = wcn36xx_sw_scan_complete,
+ .hw_scan = wcn36xx_hw_scan,
.bss_info_changed = wcn36xx_bss_info_changed,
.set_rts_threshold = wcn36xx_set_rts_threshold,
.sta_add = wcn36xx_sta_add,
@@ -1023,6 +1058,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
ieee80211_hw_set(wcn->hw, SUPPORTS_PS);
ieee80211_hw_set(wcn->hw, SIGNAL_DBM);
ieee80211_hw_set(wcn->hw, HAS_RATE_CONTROL);
+ ieee80211_hw_set(wcn->hw, SINGLE_SCAN_ON_ALL_BANDS);
wcn->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_AP) |
@@ -1032,6 +1068,9 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = &wcn_band_2ghz;
wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = &wcn_band_5ghz;
+ wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
+ wcn->hw->wiphy->max_scan_ie_len = WCN36XX_MAX_SCAN_IE_LEN;
+
wcn->hw->wiphy->cipher_suites = cipher_suites;
wcn->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
@@ -1152,6 +1191,9 @@ static int wcn36xx_probe(struct platform_device *pdev)
wcn->hw = hw;
wcn->dev = &pdev->dev;
mutex_init(&wcn->hal_mutex);
+ mutex_init(&wcn->scan_lock);
+
+ INIT_WORK(&wcn->scan_work, wcn36xx_hw_scan_worker);
wcn->smd_channel = qcom_wcnss_open_channel(wcnss, "WLAN_CTRL", wcn36xx_smd_rsp_process);
if (IS_ERR(wcn->smd_channel)) {
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index af0260add841..be5e5ea1e5c3 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -522,7 +522,7 @@ out:
return ret;
}
-int wcn36xx_smd_start_scan(struct wcn36xx *wcn)
+int wcn36xx_smd_start_scan(struct wcn36xx *wcn, u8 scan_channel)
{
struct wcn36xx_hal_start_scan_req_msg msg_body;
int ret = 0;
@@ -530,7 +530,7 @@ int wcn36xx_smd_start_scan(struct wcn36xx *wcn)
mutex_lock(&wcn->hal_mutex);
INIT_HAL_MSG(msg_body, WCN36XX_HAL_START_SCAN_REQ);
- msg_body.scan_channel = WCN36XX_HW_CHANNEL(wcn);
+ msg_body.scan_channel = scan_channel;
PREPARE_HAL_BUF(wcn->hal_buf, msg_body);
@@ -552,7 +552,7 @@ out:
return ret;
}
-int wcn36xx_smd_end_scan(struct wcn36xx *wcn)
+int wcn36xx_smd_end_scan(struct wcn36xx *wcn, u8 scan_channel)
{
struct wcn36xx_hal_end_scan_req_msg msg_body;
int ret = 0;
@@ -560,7 +560,7 @@ int wcn36xx_smd_end_scan(struct wcn36xx *wcn)
mutex_lock(&wcn->hal_mutex);
INIT_HAL_MSG(msg_body, WCN36XX_HAL_END_SCAN_REQ);
- msg_body.scan_channel = WCN36XX_HW_CHANNEL(wcn);
+ msg_body.scan_channel = scan_channel;
PREPARE_HAL_BUF(wcn->hal_buf, msg_body);
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h b/drivers/net/wireless/ath/wcn36xx/smd.h
index 40d829563c2b..8892ccd67b14 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -60,8 +60,8 @@ int wcn36xx_smd_load_nv(struct wcn36xx *wcn);
int wcn36xx_smd_start(struct wcn36xx *wcn);
int wcn36xx_smd_stop(struct wcn36xx *wcn);
int wcn36xx_smd_init_scan(struct wcn36xx *wcn, enum wcn36xx_hal_sys_mode mode);
-int wcn36xx_smd_start_scan(struct wcn36xx *wcn);
-int wcn36xx_smd_end_scan(struct wcn36xx *wcn);
+int wcn36xx_smd_start_scan(struct wcn36xx *wcn, u8 scan_channel);
+int wcn36xx_smd_end_scan(struct wcn36xx *wcn, u8 scan_channel);
int wcn36xx_smd_finish_scan(struct wcn36xx *wcn,
enum wcn36xx_hal_sys_mode mode);
int wcn36xx_smd_update_scan_params(struct wcn36xx *wcn, u8 *channels, size_t channel_count);
diff --git a/drivers/net/wireless/ath/wcn36xx/txrx.c b/drivers/net/wireless/ath/wcn36xx/txrx.c
index 1f34c2e912d7..8c387a0a3c09 100644
--- a/drivers/net/wireless/ath/wcn36xx/txrx.c
+++ b/drivers/net/wireless/ath/wcn36xx/txrx.c
@@ -45,9 +45,20 @@ int wcn36xx_rx_skb(struct wcn36xx *wcn, struct sk_buff *skb)
skb_put(skb, bd->pdu.mpdu_header_off + bd->pdu.mpdu_len);
skb_pull(skb, bd->pdu.mpdu_header_off);
+ hdr = (struct ieee80211_hdr *) skb->data;
+ fc = __le16_to_cpu(hdr->frame_control);
+ sn = IEEE80211_SEQ_TO_SN(__le16_to_cpu(hdr->seq_ctrl));
+
+ /* When scanning associate beacons to this */
+ if (ieee80211_is_beacon(hdr->frame_control) && wcn->scan_freq) {
+ status.freq = wcn->scan_freq;
+ status.band = wcn->scan_band;
+ } else {
+ status.freq = WCN36XX_CENTER_FREQ(wcn);
+ status.band = WCN36XX_BAND(wcn);
+ }
+
status.mactime = 10;
- status.freq = WCN36XX_CENTER_FREQ(wcn);
- status.band = WCN36XX_BAND(wcn);
status.signal = -get_rssi0(bd);
status.antenna = 1;
status.rate_idx = 1;
@@ -61,10 +72,6 @@ int wcn36xx_rx_skb(struct wcn36xx *wcn, struct sk_buff *skb)
memcpy(IEEE80211_SKB_RXCB(skb), &status, sizeof(status));
- hdr = (struct ieee80211_hdr *) skb->data;
- fc = __le16_to_cpu(hdr->frame_control);
- sn = IEEE80211_SEQ_TO_SN(__le16_to_cpu(hdr->seq_ctrl));
-
if (ieee80211_is_beacon(hdr->frame_control)) {
wcn36xx_dbg(WCN36XX_DBG_BEACON, "beacon skb %p len %d fc %04x sn %d\n",
skb, skb->len, fc, sn);
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 68cc06cf9bc0..35a6590c3ee5 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -35,6 +35,9 @@
/* How many frames until we start a-mpdu TX session */
#define WCN36XX_AMPDU_START_THRESH 20
+#define WCN36XX_MAX_SCAN_SSIDS 9
+#define WCN36XX_MAX_SCAN_IE_LEN 500
+
extern unsigned int wcn36xx_dbg_mask;
enum wcn36xx_debug_mask {
@@ -212,6 +215,12 @@ struct wcn36xx {
spinlock_t hal_ind_lock;
struct list_head hal_ind_queue;
+ struct work_struct scan_work;
+ struct cfg80211_scan_request *scan_req;
+ int scan_freq;
+ int scan_band;
+ struct mutex scan_lock;
+
/* DXE channels */
struct wcn36xx_dxe_ch dxe_tx_l_ch; /* TX low */
struct wcn36xx_dxe_ch dxe_tx_h_ch; /* TX high */
--
2.5.0
^ permalink raw reply related
* [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Bjorn Andersson @ 2016-09-06 22:18 UTC (permalink / raw)
To: Eugene Krasnikov, Kalle Valo
Cc: wcn36xx, linux-wireless, netdev, linux-kernel, linux-arm-msm,
Andy Gross
In-Reply-To: <1473200312-22438-1-git-send-email-bjorn.andersson@linaro.org>
The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
channel, as such it should be a SMD client. This patch makes this
transition, now that we have the necessary frameworks available.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v3:
- Made msg_header const in wcn36xx_smd_rsp_process()
Changes since v2:
- Correct the call to the new ieee80211_scan_completed()
drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
drivers/net/wireless/ath/wcn36xx/main.c | 79 ++++++++++++++++++++----------
drivers/net/wireless/ath/wcn36xx/smd.c | 31 +++++-------
drivers/net/wireless/ath/wcn36xx/smd.h | 5 ++
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-----
5 files changed, 86 insertions(+), 66 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c b/drivers/net/wireless/ath/wcn36xx/dxe.c
index 231fd022f0f5..87dfdaf9044c 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -23,6 +23,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/interrupt.h>
+#include <linux/soc/qcom/smem_state.h>
#include "wcn36xx.h"
#include "txrx.h"
@@ -151,9 +152,12 @@ int wcn36xx_dxe_alloc_ctl_blks(struct wcn36xx *wcn)
goto out_err;
/* Initialize SMSM state Clear TX Enable RING EMPTY STATE */
- ret = wcn->ctrl_ops->smsm_change_state(
- WCN36XX_SMSM_WLAN_TX_ENABLE,
- WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY);
+ ret = qcom_smem_state_update_bits(wcn->tx_enable_state,
+ WCN36XX_SMSM_WLAN_TX_ENABLE |
+ WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY,
+ WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY);
+ if (ret)
+ goto out_err;
return 0;
@@ -678,9 +682,9 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
* notify chip about new frame through SMSM bus.
*/
if (is_low && vif_priv->pw_state == WCN36XX_BMPS) {
- wcn->ctrl_ops->smsm_change_state(
- 0,
- WCN36XX_SMSM_WLAN_TX_ENABLE);
+ qcom_smem_state_update_bits(wcn->tx_rings_empty_state,
+ WCN36XX_SMSM_WLAN_TX_ENABLE,
+ WCN36XX_SMSM_WLAN_TX_ENABLE);
} else {
/* indicate End Of Packet and generate interrupt on descriptor
* done.
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
index e1d59da2ad20..3c2522b07c90 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -21,6 +21,10 @@
#include <linux/platform_device.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/soc/qcom/smd.h>
+#include <linux/soc/qcom/smem_state.h>
+#include <linux/soc/qcom/wcnss_ctrl.h>
#include "wcn36xx.h"
unsigned int wcn36xx_dbg_mask;
@@ -1058,8 +1062,7 @@ static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
int ret;
/* Set TX IRQ */
- res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
- "wcnss_wlantx_irq");
+ res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "tx");
if (!res) {
wcn36xx_err("failed to get tx_irq\n");
return -ENOENT;
@@ -1067,14 +1070,29 @@ static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
wcn->tx_irq = res->start;
/* Set RX IRQ */
- res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
- "wcnss_wlanrx_irq");
+ res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "rx");
if (!res) {
wcn36xx_err("failed to get rx_irq\n");
return -ENOENT;
}
wcn->rx_irq = res->start;
+ /* Acquire SMSM tx enable handle */
+ wcn->tx_enable_state = qcom_smem_state_get(&pdev->dev,
+ "tx-enable", &wcn->tx_enable_state_bit);
+ if (IS_ERR(wcn->tx_enable_state)) {
+ wcn36xx_err("failed to get tx-enable state\n");
+ return PTR_ERR(wcn->tx_enable_state);
+ }
+
+ /* Acquire SMSM tx rings empty handle */
+ wcn->tx_rings_empty_state = qcom_smem_state_get(&pdev->dev,
+ "tx-rings-empty", &wcn->tx_rings_empty_state_bit);
+ if (IS_ERR(wcn->tx_rings_empty_state)) {
+ wcn36xx_err("failed to get tx-rings-empty state\n");
+ return PTR_ERR(wcn->tx_rings_empty_state);
+ }
+
mmio_node = of_parse_phandle(pdev->dev.parent->of_node, "qcom,mmio", 0);
if (!mmio_node) {
wcn36xx_err("failed to acquire qcom,mmio reference\n");
@@ -1115,11 +1133,14 @@ static int wcn36xx_probe(struct platform_device *pdev)
{
struct ieee80211_hw *hw;
struct wcn36xx *wcn;
+ void *wcnss;
int ret;
- u8 addr[ETH_ALEN];
+ const u8 *addr;
wcn36xx_dbg(WCN36XX_DBG_MAC, "platform probe\n");
+ wcnss = dev_get_drvdata(pdev->dev.parent);
+
hw = ieee80211_alloc_hw(sizeof(struct wcn36xx), &wcn36xx_ops);
if (!hw) {
wcn36xx_err("failed to alloc hw\n");
@@ -1130,11 +1151,23 @@ static int wcn36xx_probe(struct platform_device *pdev)
wcn = hw->priv;
wcn->hw = hw;
wcn->dev = &pdev->dev;
- wcn->ctrl_ops = pdev->dev.platform_data;
-
mutex_init(&wcn->hal_mutex);
- if (!wcn->ctrl_ops->get_hw_mac(addr)) {
+ wcn->smd_channel = qcom_wcnss_open_channel(wcnss, "WLAN_CTRL", wcn36xx_smd_rsp_process);
+ if (IS_ERR(wcn->smd_channel)) {
+ wcn36xx_err("failed to open WLAN_CTRL channel\n");
+ ret = PTR_ERR(wcn->smd_channel);
+ goto out_wq;
+ }
+
+ qcom_smd_set_drvdata(wcn->smd_channel, hw);
+
+ addr = of_get_property(pdev->dev.of_node, "local-mac-address", &ret);
+ if (addr && ret != ETH_ALEN) {
+ wcn36xx_err("invalid local-mac-address\n");
+ ret = -EINVAL;
+ goto out_wq;
+ } else if (addr) {
wcn36xx_info("mac address: %pM\n", addr);
SET_IEEE80211_PERM_ADDR(wcn->hw, addr);
}
@@ -1158,6 +1191,7 @@ out_wq:
out_err:
return ret;
}
+
static int wcn36xx_remove(struct platform_device *pdev)
{
struct ieee80211_hw *hw = platform_get_drvdata(pdev);
@@ -1168,42 +1202,33 @@ static int wcn36xx_remove(struct platform_device *pdev)
mutex_destroy(&wcn->hal_mutex);
ieee80211_unregister_hw(hw);
+
+ qcom_smem_state_put(wcn->tx_enable_state);
+ qcom_smem_state_put(wcn->tx_rings_empty_state);
+
iounmap(wcn->dxe_base);
iounmap(wcn->ccu_base);
ieee80211_free_hw(hw);
return 0;
}
-static const struct platform_device_id wcn36xx_platform_id_table[] = {
- {
- .name = "wcn36xx",
- .driver_data = 0
- },
+
+static const struct of_device_id wcn36xx_of_match[] = {
+ { .compatible = "qcom,wcnss-wlan" },
{}
};
-MODULE_DEVICE_TABLE(platform, wcn36xx_platform_id_table);
+MODULE_DEVICE_TABLE(of, wcn36xx_of_match);
static struct platform_driver wcn36xx_driver = {
.probe = wcn36xx_probe,
.remove = wcn36xx_remove,
.driver = {
.name = "wcn36xx",
+ .of_match_table = wcn36xx_of_match,
},
- .id_table = wcn36xx_platform_id_table,
};
-static int __init wcn36xx_init(void)
-{
- platform_driver_register(&wcn36xx_driver);
- return 0;
-}
-module_init(wcn36xx_init);
-
-static void __exit wcn36xx_exit(void)
-{
- platform_driver_unregister(&wcn36xx_driver);
-}
-module_exit(wcn36xx_exit);
+module_platform_driver(wcn36xx_driver);
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Eugene Krasnikov k.eugene.e@gmail.com");
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index a443992320f2..af0260add841 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -19,6 +19,7 @@
#include <linux/etherdevice.h>
#include <linux/firmware.h>
#include <linux/bitops.h>
+#include <linux/soc/qcom/smd.h>
#include "smd.h"
struct wcn36xx_cfg_val {
@@ -253,7 +254,7 @@ static int wcn36xx_smd_send_and_wait(struct wcn36xx *wcn, size_t len)
init_completion(&wcn->hal_rsp_compl);
start = jiffies;
- ret = wcn->ctrl_ops->tx(wcn->hal_buf, len);
+ ret = qcom_smd_send(wcn->smd_channel, wcn->hal_buf, len);
if (ret) {
wcn36xx_err("HAL TX failed\n");
goto out;
@@ -2180,9 +2181,12 @@ out:
return ret;
}
-static void wcn36xx_smd_rsp_process(struct wcn36xx *wcn, void *buf, size_t len)
+int wcn36xx_smd_rsp_process(struct qcom_smd_channel *channel,
+ const void *buf, size_t len)
{
- struct wcn36xx_hal_msg_header *msg_header = buf;
+ const struct wcn36xx_hal_msg_header *msg_header = buf;
+ struct ieee80211_hw *hw = qcom_smd_get_drvdata(channel);
+ struct wcn36xx *wcn = hw->priv;
struct wcn36xx_hal_ind_msg *msg_ind;
wcn36xx_dbg_dump(WCN36XX_DBG_SMD_DUMP, "SMD <<< ", buf, len);
@@ -2233,15 +2237,11 @@ static void wcn36xx_smd_rsp_process(struct wcn36xx *wcn, void *buf, size_t len)
case WCN36XX_HAL_OTA_TX_COMPL_IND:
case WCN36XX_HAL_MISSED_BEACON_IND:
case WCN36XX_HAL_DELETE_STA_CONTEXT_IND:
- msg_ind = kmalloc(sizeof(*msg_ind) + len, GFP_KERNEL);
+ msg_ind = kmalloc(sizeof(*msg_ind) + len, GFP_ATOMIC);
if (!msg_ind) {
- /*
- * FIXME: Do something smarter then just
- * printing an error.
- */
wcn36xx_err("Run out of memory while handling SMD_EVENT (%d)\n",
msg_header->msg_type);
- break;
+ return -ENOMEM;
}
msg_ind->msg_len = len;
@@ -2257,6 +2257,8 @@ static void wcn36xx_smd_rsp_process(struct wcn36xx *wcn, void *buf, size_t len)
wcn36xx_err("SMD_EVENT (%d) not supported\n",
msg_header->msg_type);
}
+
+ return 0;
}
static void wcn36xx_ind_smd_work(struct work_struct *work)
{
@@ -2315,22 +2317,13 @@ int wcn36xx_smd_open(struct wcn36xx *wcn)
INIT_LIST_HEAD(&wcn->hal_ind_queue);
spin_lock_init(&wcn->hal_ind_lock);
- ret = wcn->ctrl_ops->open(wcn, wcn36xx_smd_rsp_process);
- if (ret) {
- wcn36xx_err("failed to open control channel\n");
- goto free_wq;
- }
-
- return ret;
+ return 0;
-free_wq:
- destroy_workqueue(wcn->hal_ind_wq);
out:
return ret;
}
void wcn36xx_smd_close(struct wcn36xx *wcn)
{
- wcn->ctrl_ops->close();
destroy_workqueue(wcn->hal_ind_wq);
}
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h b/drivers/net/wireless/ath/wcn36xx/smd.h
index df80cbbd9d1b..40d829563c2b 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -51,6 +51,7 @@ struct wcn36xx_hal_ind_msg {
};
struct wcn36xx;
+struct qcom_smd_channel;
int wcn36xx_smd_open(struct wcn36xx *wcn);
void wcn36xx_smd_close(struct wcn36xx *wcn);
@@ -127,6 +128,10 @@ int wcn36xx_smd_del_ba(struct wcn36xx *wcn, u16 tid, u8 sta_index);
int wcn36xx_smd_trigger_ba(struct wcn36xx *wcn, u8 sta_index);
int wcn36xx_smd_update_cfg(struct wcn36xx *wcn, u32 cfg_id, u32 value);
+
+int wcn36xx_smd_rsp_process(struct qcom_smd_channel *channel,
+ const void *buf, size_t len);
+
int wcn36xx_smd_set_mc_list(struct wcn36xx *wcn,
struct ieee80211_vif *vif,
struct wcn36xx_hal_rcv_flt_mc_addr_list_type *fp);
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 22242d18e1fe..68cc06cf9bc0 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -103,19 +103,6 @@ struct nv_data {
u8 table;
};
-/* Interface for platform control path
- *
- * @open: hook must be called when wcn36xx wants to open control channel.
- * @tx: sends a buffer.
- */
-struct wcn36xx_platform_ctrl_ops {
- int (*open)(void *drv_priv, void *rsp_cb);
- void (*close)(void);
- int (*tx)(char *buf, size_t len);
- int (*get_hw_mac)(u8 *addr);
- int (*smsm_change_state)(u32 clear_mask, u32 set_mask);
-};
-
/**
* struct wcn36xx_vif - holds VIF related fields
*
@@ -205,7 +192,13 @@ struct wcn36xx {
void __iomem *ccu_base;
void __iomem *dxe_base;
- struct wcn36xx_platform_ctrl_ops *ctrl_ops;
+ struct qcom_smd_channel *smd_channel;
+
+ struct qcom_smem_state *tx_enable_state;
+ unsigned tx_enable_state_bit;
+ struct qcom_smem_state *tx_rings_empty_state;
+ unsigned tx_rings_empty_state_bit;
+
/*
* smd_buf must be protected with smd_mutex to garantee
* that all messages are sent one after another
--
2.5.0
^ permalink raw reply related
* [PATCH v4 1/4] soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API
From: Bjorn Andersson @ 2016-09-06 22:18 UTC (permalink / raw)
To: Andy Gross, Eugene Krasnikov, Kalle Valo
Cc: wcn36xx, linux-wireless, netdev, linux-kernel, linux-arm-msm,
Marcel Holtmann
Stub the wcnss_ctrl API to allow compile testing wcnss function drivers.
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
There are no other pending changes colliding with this, so if Andy is okay with
this it could be merged through Kalle's tree - together with the other patches.
Marcel, with this applied we can drop the depends on QCOM_SMD from the
btqcomsmd driver as well.
Changes since v3:
- Added this patch to allow compile testing without SMD support after patch 2
include/linux/soc/qcom/wcnss_ctrl.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/linux/soc/qcom/wcnss_ctrl.h b/include/linux/soc/qcom/wcnss_ctrl.h
index a37bc5538f19..eab64976a73b 100644
--- a/include/linux/soc/qcom/wcnss_ctrl.h
+++ b/include/linux/soc/qcom/wcnss_ctrl.h
@@ -3,6 +3,19 @@
#include <linux/soc/qcom/smd.h>
+#if IS_ENABLED(CONFIG_QCOM_WCNSS_CTRL)
+
struct qcom_smd_channel *qcom_wcnss_open_channel(void *wcnss, const char *name, qcom_smd_cb_t cb);
+#else
+
+static inline struct qcom_smd_channel*
+qcom_wcnss_open_channel(void *wcnss, const char *name, qcom_smd_cb_t cb)
+{
+ WARN_ON(1);
+ return ERR_PTR(-ENXIO);
+}
+
+#endif
+
#endif
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v8] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.
From: Felix Fietkau @ 2016-09-06 22:04 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
In-Reply-To: <20160906114426.25520-1-toke@toke.dk>
On 2016-09-06 13:44, Toke Høiland-Jørgensen wrote:
> The TXQ intermediate queues can cause packet reordering when more than
> one flow is active to a single station. Since some of the wifi-specific
> packet handling (notably sequence number and encryption handling) is
> sensitive to re-ordering, things break if they are applied before the
> TXQ.
>
> This splits up the TX handlers and fast_xmit logic into two parts: An
> early part and a late part. The former is applied before TXQ enqueue,
> and the latter after dequeue. The non-TXQ path just applies both parts
> at once.
>
> Because fragments shouldn't be split up or reordered, the fragmentation
> handler is run after dequeue. Any fragments are then kept in the TXQ and
> on subsequent dequeues they take precedence over dequeueing from the FQ
> structure.
>
> This approach avoids having to scatter special cases for when TXQ is
> enabled, at the cost of making the fast_xmit and TX handler code
> slightly more complex.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Acked-by: Felix Fietkau <nbd@nbd.name>
^ permalink raw reply
* [PATCH v6 3/3] ath9k: parse the device configuration from an OF node
From: Martin Blumenstingl @ 2016-09-06 21:46 UTC (permalink / raw)
To: ath9k-devel, devicetree, linux-wireless, ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20160906214623.20424-1-martin.blumenstingl@googlemail.com>
This allows configuring ath9k based PCI devices using devicetree.
There is some out-of-tree code to "convert devicetree to
ath9k_platform_data" (for example in OpenWrt and LEDE) which becomes
obsolete with this patch.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/wireless/ath/ath9k/init.c | 51 +++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index cfa3fe8..c123145 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -20,6 +20,8 @@
#include <linux/slab.h>
#include <linux/ath9k_platform.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
#include <linux/relay.h>
#include <net/ieee80211_radiotap.h>
@@ -555,6 +557,51 @@ static int ath9k_init_platform(struct ath_softc *sc)
return 0;
}
+static int ath9k_of_init(struct ath_softc *sc)
+{
+ struct device_node *np = sc->dev->of_node;
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
+ enum ath_bus_type bus_type = common->bus_ops->ath_bus_type;
+ const char *mac;
+ char eeprom_name[100];
+ int ret;
+
+ if (!of_device_is_available(np))
+ return 0;
+
+ ath_dbg(common, CONFIG, "parsing configuration from OF node\n");
+
+ if (of_property_read_bool(np, "qca,clk-25mhz"))
+ ah->is_clk_25mhz = true;
+
+ if (of_property_read_bool(np, "qca,disable-2ghz"))
+ ah->disable_2ghz = true;
+
+ if (of_property_read_bool(np, "qca,disable-5ghz"))
+ ah->disable_5ghz = true;
+
+ if (of_property_read_bool(np, "qca,no-eeprom")) {
+ /* ath9k-eeprom-<bus>-<id>.bin */
+ scnprintf(eeprom_name, sizeof(eeprom_name),
+ "ath9k-eeprom-%s-%s.bin",
+ ath_bus_type_to_string(bus_type), dev_name(ah->dev));
+
+ ret = ath9k_eeprom_request(sc, eeprom_name);
+ if (ret)
+ return ret;
+ }
+
+ mac = of_get_mac_address(np);
+ if (mac)
+ ether_addr_copy(common->macaddr, mac);
+
+ ah->ah_flags &= ~AH_USE_EEPROM;
+ ah->ah_flags |= AH_NO_EEP_SWAP;
+
+ return 0;
+}
+
static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
const struct ath_bus_ops *bus_ops)
{
@@ -611,6 +658,10 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
if (ret)
return ret;
+ ret = ath9k_of_init(sc);
+ if (ret)
+ return ret;
+
if (ath9k_led_active_high != -1)
ah->config.led_active_high = ath9k_led_active_high == 1;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 2/3] ath9k: add a helper to get the string representation of ath_bus_type
From: Martin Blumenstingl @ 2016-09-06 21:46 UTC (permalink / raw)
To: ath9k-devel, devicetree, linux-wireless, ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20160906214623.20424-1-martin.blumenstingl@googlemail.com>
This can be used when the ath_bus_type has to be presented in a log
message or firmware filename.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/wireless/ath/ath.h | 6 ++++++
drivers/net/wireless/ath/main.c | 7 +++++++
2 files changed, 13 insertions(+)
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index da7a7c8..f3f2784 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -327,4 +327,10 @@ static inline const char *ath_opmode_to_string(enum nl80211_iftype opmode)
}
#endif
+extern const char *ath_bus_type_strings[];
+static inline const char *ath_bus_type_to_string(enum ath_bus_type bustype)
+{
+ return ath_bus_type_strings[bustype];
+}
+
#endif /* ATH_H */
diff --git a/drivers/net/wireless/ath/main.c b/drivers/net/wireless/ath/main.c
index 338d723..89f4b05 100644
--- a/drivers/net/wireless/ath/main.c
+++ b/drivers/net/wireless/ath/main.c
@@ -90,3 +90,10 @@ void ath_printk(const char *level, const struct ath_common* common,
va_end(args);
}
EXPORT_SYMBOL(ath_printk);
+
+const char *ath_bus_type_strings[] = {
+ [ATH_PCI] = "pci",
+ [ATH_AHB] = "ahb",
+ [ATH_USB] = "usb",
+};
+EXPORT_SYMBOL(ath_bus_type_strings);
--
2.9.3
^ permalink raw reply related
* [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Martin Blumenstingl @ 2016-09-06 21:46 UTC (permalink / raw)
To: ath9k-devel, devicetree, linux-wireless, ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20160906214623.20424-1-martin.blumenstingl@googlemail.com>
Add documentation how devicetree can be used to configure ath9k based
devices.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
new file mode 100644
index 0000000..77b9202
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
@@ -0,0 +1,39 @@
+* Qualcomm Atheros ath9k wireless devices
+
+This node provides properties for configuring the ath9k wireless device. The
+node is expected to be specified as a child node of the PCI controller to
+which the wireless chip is connected.
+
+Required properties:
+- compatible: For PCI and PCIe devices this should be an identifier following
+ the format as defined in "PCI Bus Binding to Open Firmware"
+ Revision 2.1. One of the possible formats is "pciVVVV,DDDD"
+ where VVVV is the PCI vendor ID and DDDD is PCI device ID.
+
+Optional properties:
+- reg: Address and length of the register set for the device.
+- qca,clk-25mhz: Defines that a 25MHz clock is used
+- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
+ ath9k wireless chip (in this case the calibration /
+ EEPROM data will be loaded from userspace using the
+ kernel firmware loader).
+- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
+ 2.4GHz band. Setting this property is only needed
+ when the RF circuit does not support the 2.4GHz band
+ while it is enabled nevertheless in the EEPROM.
+- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
+ 5GHz band. Setting this property is only needed when
+ the RF circuit does not support the 5GHz band while
+ it is enabled nevertheless in the EEPROM.
+- mac-address: See ethernet.txt in the parent directory
+- local-mac-address: See ethernet.txt in the parent directory
+
+
+In this example, the node is defined as child node of the PCI controller:
+&pci0 {
+ ath9k@168c,002d {
+ compatible = "pci168c,002d";
+ reg = <0x7000 0 0 0 0x1000>;
+ qca,disable-5ghz;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v6 0/3] add devicetree support to ath9k
From: Martin Blumenstingl @ 2016-09-06 21:46 UTC (permalink / raw)
To: ath9k-devel, devicetree, linux-wireless, ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, linux, nbd, Martin Blumenstingl
In-Reply-To: <20160821143105.27487-1-martin.blumenstingl@googlemail.com>
This series adds support for configuring ath9k based devices via
devicetree. This was tested on PCI(e) based devices. This should work
for AHB based devices as well as soon as the ath79 platform is ready
to populate the ath9k wmac via devicetree.
Changes since v5:
- updated the example in the documentation (keeping it at a bare
minimum: removed the PCI bridge, use a better real-world example with
less-confusing device/fn numbers, added the actual size of the config
space to the reg property)
Martin Blumenstingl (3):
Documentation: dt: net: add ath9k wireless device binding
ath9k: add a helper to get the string representation of ath_bus_type
ath9k: parse the device configuration from an OF node
.../devicetree/bindings/net/wireless/qca,ath9k.txt | 39 +++++++++++++++++
drivers/net/wireless/ath/ath.h | 6 +++
drivers/net/wireless/ath/ath9k/init.c | 51 ++++++++++++++++++++++
drivers/net/wireless/ath/main.c | 7 +++
4 files changed, 103 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
--
2.9.3
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Ben Greear @ 2016-09-06 19:07 UTC (permalink / raw)
To: Thomas Pedersen, linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1473188417-13987-1-git-send-email-twp@qca.qualcomm.com>
On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
> Some drivers (ath10k) report MCS 9 @ 20MHz, which
> technically isn't allowed. To get more meaningful value
> than 0 out of this however, just cap the bitrate for 20MHz
> to MCS 8.
If it is actually reporting MCS9, why lie about it? Report it up
the stack as a proper value instead of hiding the issue?
Thanks,
Ben
>
> Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
> ---
> net/wireless/util.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> index 0675f51..5fb0249 100644
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -1157,7 +1157,9 @@ static u32 cfg80211_calculate_bitrate_vht(struct rate_info *rate)
> 58500000,
> 65000000,
> 78000000,
> - 0,
> + /* some drivers report MCS 9 for 20MHz anyway. Clip to MCS 8
> + * bitrate as it's closer than 0 */
> + 78000000,
> },
> { 13500000,
> 27000000,
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] ath10k: enable peer stats by default
From: Thomas Pedersen @ 2016-09-06 19:05 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
IFTYPE_MESH_POINT need to rely on these for accurate path
selection metrics. Other modes will probably also find
them useful. Enabling peer stats has the side effect of
reducing max number of STAs from 128 to 118. There should
be negligible performance impact.
If users really need 128 STAs and don't mind losing out on
peer stats, they can still disable them:
echo 0 > debugfs/ieee80211/phyn/ath10k/peer_stats
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index c9d163e..c0ab4f4 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2145,6 +2145,9 @@ static void ath10k_core_register_work(struct work_struct *work)
struct ath10k *ar = container_of(work, struct ath10k, register_work);
int status;
+ /* peer stats are enabled by default */
+ set_bit(ATH10K_FLAG_PEER_STATS, &ar->dev_flags);
+
status = ath10k_core_probe_fw(ar);
if (status) {
ath10k_err(ar, "could not probe fw (%d)\n", status);
--
2.1.4
^ permalink raw reply related
* [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Thomas Pedersen @ 2016-09-06 19:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Thomas Pedersen
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't allowed. To get more meaningful value
than 0 out of this however, just cap the bitrate for 20MHz
to MCS 8.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
net/wireless/util.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 0675f51..5fb0249 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1157,7 +1157,9 @@ static u32 cfg80211_calculate_bitrate_vht(struct rate_info *rate)
58500000,
65000000,
78000000,
- 0,
+ /* some drivers report MCS 9 for 20MHz anyway. Clip to MCS 8
+ * bitrate as it's closer than 0 */
+ 78000000,
},
{ 13500000,
27000000,
--
2.1.4
^ permalink raw reply related
* [PATCH] mac80211: make mpath path fixing more robust
From: Thomas Pedersen @ 2016-09-06 18:59 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Thomas Pedersen
A fixed mpath was not quite being treated as such:
1) if a PERR frame was received, a fixed mpath was
deactivated.
2) queued path discovery for fixed mpath was potentially
being considered, changing mpath state.
3) other mpath flags were potentially being inherited when
fixing the mpath. Just assign PATH_FIXED and SN_VALID.
This solves several issues when fixing a mesh path in one
direction. The reverse direction mpath should probably
also be fixed, or root announcements at least be enabled.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
net/mac80211/mesh_hwmp.c | 3 ++-
net/mac80211/mesh_pathtbl.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index fa7d37c..b747c96 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -757,6 +757,7 @@ static void hwmp_perr_frame_process(struct ieee80211_sub_if_data *sdata,
sta = next_hop_deref_protected(mpath);
if (mpath->flags & MESH_PATH_ACTIVE &&
ether_addr_equal(ta, sta->sta.addr) &&
+ !(mpath->flags & MESH_PATH_FIXED) &&
(!(mpath->flags & MESH_PATH_SN_VALID) ||
SN_GT(target_sn, mpath->sn) || target_sn == 0)) {
mpath->flags &= ~MESH_PATH_ACTIVE;
@@ -1023,7 +1024,7 @@ void mesh_path_start_discovery(struct ieee80211_sub_if_data *sdata)
goto enddiscovery;
spin_lock_bh(&mpath->state_lock);
- if (mpath->flags & MESH_PATH_DELETED) {
+ if (mpath->flags & (MESH_PATH_DELETED | MESH_PATH_FIXED)) {
spin_unlock_bh(&mpath->state_lock);
goto enddiscovery;
}
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 6db2ddf..8e3d2d1 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -826,7 +826,7 @@ void mesh_path_fix_nexthop(struct mesh_path *mpath, struct sta_info *next_hop)
mpath->metric = 0;
mpath->hop_count = 0;
mpath->exp_time = 0;
- mpath->flags |= MESH_PATH_FIXED;
+ mpath->flags = (MESH_PATH_FIXED | MESH_PATH_SN_VALID);
mesh_path_activate(mpath);
spin_unlock_bh(&mpath->state_lock);
mesh_path_tx_pending(mpath);
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox