* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Bjorn Andersson @ 2016-09-08 15:31 UTC (permalink / raw)
To: Kalle Valo
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, lkml,
Andy Gross, linux-arm-msm
In-Reply-To: <87k2emsi22.fsf@kamboji.qca.qualcomm.com>
On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>
>> 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(-)
>
> This doesn't compile for me:
>
I thought I mentioned this in the mail, sorry for missing that.
There is a patch for this issue in linux-next already [1] which is
part of [2], which was part of the pull request to arm-soc for
inclusion in v4.9.
[1] https://patchwork.kernel.org/patch/9272457/
[2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
Regards,
Bjorn
^ permalink raw reply
* Re: rtl8xxxu: fix spelling mistake "firmare" -> "firmware"
From: Jes Sorensen @ 2016-09-08 15:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: Colin Ian King, linux-wireless, netdev, linux-kernel
In-Reply-To: <20160908122813.E50B561BB7@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Colin Ian King <colin.king@canonical.com> wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> Trivial fix to spelling mistakes in dev_dbg message.
>>
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
>
> I assume Jes will take this.
It's on my list, sorry been swamped in LPC stuff and other work the last
couple of days.
Cheers,
Jes
^ permalink raw reply
* RE: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()
From: Amitkumar Karwar @ 2016-09-08 15:55 UTC (permalink / raw)
To: Javier Martinez Canillas, Kalle Valo
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, Nishant Sarmukadam,
Arend van Spriel
In-Reply-To: <66735eb5-c831-8e06-337b-80ccfc392061@osg.samsung.com>
SGkgSmF2aWVyLA0KDQo+IEZyb206IEphdmllciBNYXJ0aW5leiBDYW5pbGxhcyBbbWFpbHRvOmph
dmllckBvc2cuc2Ftc3VuZy5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNiwgMjAx
NiA1OjQzIFBNDQo+IFRvOiBLYWxsZSBWYWxvDQo+IENjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJu
ZWwub3JnOyBBbWl0a3VtYXIgS2Fyd2FyOw0KPiBuZXRkZXZAdmdlci5rZXJuZWwub3JnOyBsaW51
eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE5pc2hhbnQNCj4gU2FybXVrYWRhbTsgQXJlbmQg
dmFuIFNwcmllbA0KPiBTdWJqZWN0OiBSZTogbXdpZmlleDogcHJvcGFnYXRlIGVycm9yIGlmIElS
USByZXF1ZXN0IGZhaWxzIGluDQo+IG13aWZpZXhfc2Rpb19vZigpDQo+IA0KPiBIZWxsbyBLYWxs
ZSwNCj4gDQo+IE9uIDA5LzAzLzIwMTYgMTI6MzUgUE0sIEthbGxlIFZhbG8gd3JvdGU6DQo+ID4g
SmF2aWVyIE1hcnRpbmV6IENhbmlsbGFzIDxqYXZpZXJAb3NnLnNhbXN1bmcuY29tPiB3cm90ZToN
Cj4gPj4gSWYgcmVxdWVzdF9pcnEoKSBmYWlscyBpbiBtd2lmaWV4X3NkaW9fcHJvYmVfb2YoKSwg
b25seSBhbiBlcnJvcg0KPiA+PiBtZXNzYWdlIGlzIHByaW50ZWQgYnV0IHRoZSBhY3R1YWwgZXJy
b3IgaXMgbm90IHByb3BhZ2F0ZWQgdG8gdGhlDQo+IGNhbGxlciBmdW5jdGlvbi4NCj4gPj4NCj4g
Pj4gU2lnbmVkLW9mZi1ieTogSmF2aWVyIE1hcnRpbmV6IENhbmlsbGFzIDxqYXZpZXJAb3NnLnNh
bXN1bmcuY29tPg0KPiA+DQo+ID4gV2hhdCdzIHRoZSBjb25jbHVzaW9uIHdpdGggdGhpcyBwYXRj
aD8gU2hvdWxkIEkgZHJvcCBpdCBvciB0YWtlIGl0Pw0KPiA+DQo+ID4gKFRoZSBkaXNjdXNzaW9u
IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBwYXRjaHdvcmsgbGluayBpbiB0aGUNCj4gPiBzaWduYXR1
cmUuKQ0KPiA+DQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgQXJlbmQgYWdyZWVzIHdp
dGggdGhlIHBhdGNoIGFuZCB0aGF0IHRoZQ0KPiBxdWVzdGlvbiByYWlzZWQgd2FzIGNhdXNlZCBi
eSBsb29raW5nIGF0IGFuIG9sZGVyIGtlcm5lbCB2ZXJzaW9uLiBJT1csDQo+IHRoZSBwYXRjaCBp
cyBPSyBhbmQgc2hvdWxkIGJlIHBpY2tlZC4NCj4gDQo+IEknbSBhZGRpbmcgQXJlbmQgdG8gY2Ms
IHNvIGNhbiBjb21tZW50IGluIGNhc2UgSSBtaXN1bmRlcnN0b29kIGhpbQ0KPiB0aG91Z2guDQo+
IA0KDQpUaGlzIGVycm9yIGRvZXNuJ3QgYWZmZWN0IGFjdHVhbCB3aWZpIGZ1bmN0aW9uYWxpdHku
IE9ubHkgdGhpbmcgaXMgd2FrZXVwIG9uIGludGVycnVwdCB3aGVuIHN5c3RlbSBpcyBpbiBzdXNw
ZW5kZWQgc3RhdGUgd29uJ3Qgd29yay4NCkkgdGhpbmssIHdlIGNhbiBtYWtlIGJlbG93IGNoYW5n
ZS4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KQEAgLTEyMiw5ICsxMjIsMTEgQEAgc3RhdGljIGlu
dCBtd2lmaWV4X3NkaW9fcHJvYmVfb2Yoc3RydWN0IGRldmljZSAqZGV2LCBzdHJ1Y3Qgc2Rpb19t
bWNfY2FyZCAqY2FyZCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgSVJRRl9UUklHR0VSX0xPVywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIndpZmlfd2FrZSIsIGNmZyk7DQogICAgICAgICAgIGlmIChyZXQpIHsN
Ci0gICAgICAgICAgICAgICAgICAgIGRldl9lcnIoZGV2LA0KKyAgICAgICAgICAgICAgICAgICAg
ZGV2X2RiZyhkZXYsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICJGYWlsZWQgdG8gcmVx
dWVzdCBpcnFfd2lmaSAlZCAoJWQpXG4iLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
ZmctPmlycV93aWZpLCByZXQpOw0KKyAgICAgICAgICAgICAgICAgICAgY2FyZC0+cGx0X3dha2Vf
Y2ZnID0gTlVMTDsNCisgICAgICAgICAgICAgICAgICAgIHJldHVybiAwOw0KICAgICAgICAgICAg
IH0NCiAgICAgICAgICAgICAgICBkaXNhYmxlX2lycShjZmctPmlycV93aWZpKTsNCiAgICAgICAg
ICAgIH0NCi0tLS0tLS0tLS0tLS0tLS0tDQoNClJlZ2FyZHMsDQpBbWl0a3VtYXINCg==
^ permalink raw reply
* Re: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()
From: Javier Martinez Canillas @ 2016-09-08 15:57 UTC (permalink / raw)
To: Amitkumar Karwar, Kalle Valo
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, Nishant Sarmukadam,
Arend van Spriel
In-Reply-To: <0f15fe320fa34ae287f8a6b91ec78a34@SC-EXCH04.marvell.com>
Hello Amitkumar,
On 09/08/2016 11:55 AM, Amitkumar Karwar wrote:
> Hi Javier,
>
>> From: Javier Martinez Canillas [mailto:javier@osg.samsung.com]
>> Sent: Tuesday, September 06, 2016 5:43 PM
>> To: Kalle Valo
>> Cc: linux-kernel@vger.kernel.org; Amitkumar Karwar;
>> netdev@vger.kernel.org; linux-wireless@vger.kernel.org; Nishant
>> Sarmukadam; Arend van Spriel
>> Subject: Re: mwifiex: propagate error if IRQ request fails in
>> mwifiex_sdio_of()
>>
>> Hello Kalle,
>>
>> On 09/03/2016 12:35 PM, Kalle Valo wrote:
>>> Javier Martinez Canillas <javier@osg.samsung.com> wrote:
>>>> If request_irq() fails in mwifiex_sdio_probe_of(), only an error
>>>> message is printed but the actual error is not propagated to the
>> caller function.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>>
>>> What's the conclusion with this patch? Should I drop it or take it?
>>>
>>> (The discussion is available from the patchwork link in the
>>> signature.)
>>>
>>
>> My understanding is that Arend agrees with the patch and that the
>> question raised was caused by looking at an older kernel version. IOW,
>> the patch is OK and should be picked.
>>
>> I'm adding Arend to cc, so can comment in case I misunderstood him
>> though.
>>
>
> This error doesn't affect actual wifi functionality. Only thing is wakeup on interrupt when system is in suspended state won't work.
> I think, we can make below change.
>
> ------------------
> @@ -122,9 +122,11 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
> IRQF_TRIGGER_LOW,
> "wifi_wake", cfg);
> if (ret) {
> - dev_err(dev,
> + dev_dbg(dev,
> "Failed to request irq_wifi %d (%d)\n",
> cfg->irq_wifi, ret);
> + card->plt_wake_cfg = NULL;
> + return 0;
> }
I'm OK with that change. Feel free too add my Reviewed-by if you post it.
> disable_irq(cfg->irq_wifi);
> }
> -----------------
>
> Regards,
> Amitkumar
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* RE: [PATCH 2/2] mwifiex: fix unaligned read in mwifiex_config_scan()
From: Amitkumar Karwar @ 2016-09-08 16:10 UTC (permalink / raw)
To: Petri Gynther, linux-wireless@vger.kernel.org
Cc: kvalo@codeaurora.org, David Miller, Joe Perches
In-Reply-To: <CAGXr9JFSUFr+mhyRnPk0pCeVsde4PUudZW+AZ44mKdT1iEpV6A@mail.gmail.com>
SGkgUGV0cmksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0cmkg
R3ludGhlciBbbWFpbHRvOnBneW50aGVyQGdvb2dsZS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEF1
Z3VzdCAxNiwgMjAxNiAxMToxNyBQTQ0KPiBUbzogbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwu
b3JnDQo+IENjOiBrdmFsb0Bjb2RlYXVyb3JhLm9yZzsgRGF2aWQgTWlsbGVyOyBKb2UgUGVyY2hl
czsgQW1pdGt1bWFyIEthcndhcjsNCj4gUGV0cmkgR3ludGhlcg0KPiBTdWJqZWN0OiBSZTogW1BB
VENIIDIvMl0gbXdpZmlleDogZml4IHVuYWxpZ25lZCByZWFkIGluDQo+IG13aWZpZXhfY29uZmln
X3NjYW4oKQ0KPiANCj4gT24gRnJpLCBBdWcgMTIsIDIwMTYgYXQgODowMCBQTSwgUGV0cmkgR3lu
dGhlciA8cGd5bnRoZXJAZ29vZ2xlLmNvbT4NCj4gd3JvdGU6DQo+ID4gJCBpd2NvbmZpZyBtbGFu
MCBlc3NpZCBNeVNTSUQNCj4gPiBbICAgMzYuOTMwMDAwXSBQYXRoOiAvc2Jpbi9pd2NvbmZpZw0K
PiA+IFsgICAzNi45MzAwMDBdIENQVTogMCBQSUQ6IDIwMyBDb21tOiBpd2NvbmZpZyBOb3QgdGFp
bnRlZCA0LjcuMCAjMg0KPiA+IFsgICAzNi45NDAwMDBdIHRhc2s6IDg2NmY4M2EwIHRpOiA4NjZh
NjAwMCB0YXNrLnRpOiA4NjZhNjAwMA0KPiA+IFsgICAzNi45NDAwMDBdDQo+ID4gW0VDUiAgIF06
IDB4MDAyMzA0MDAgPT4gTWlzYWxpZ25lZCByL3cgZnJvbSAweDg2NzdmNDAzDQo+ID4gWyAgIDM2
Ljk2MDAwMF0gW0VGQSAgIF06IDB4ODY3N2Y0MDMNCj4gPiBbICAgMzYuOTYwMDAwXSBbQkxJTksg
XTogbXdpZmlleF9zY2FuX25ldHdvcmtzKzB4MTdhLzB4MTk4YyBbbXdpZmlleF0NCj4gPiBbICAg
MzYuOTYwMDAwXSBbRVJFVCAgXTogbXdpZmlleF9zY2FuX25ldHdvcmtzKzB4MThhLzB4MTk4YyBb
bXdpZmlleF0NCj4gPiBbICAgMzYuOTgwMDAwXSBbU1RBVDMyXTogMHgwMDAwMDIwNiA6IEsgICAg
ICAgICBFMiBFMQ0KPiA+IFsgICAzNi45ODAwMDBdIEJUQTogMHg3MDA3MzZlMiAgIFNQOiAweDg2
NmE3ZDBjICBGUDogMHg1ZmFkZGM4NA0KPiA+IFsgICAzNy4wMDAwMDBdIExQUzogMHg4MDZhMzdl
YyAgTFBFOiAweDgwNmEzN2ZhIExQQzogMHgwMDAwMDAwMA0KPiA+IFsgICAzNy4wMDAwMDBdIHIw
MDogMHg4Njc3ZjQwMSAgcjAxOiAweDg2NjhhYTA4IHIwMjogMHgwMDAwMDAwMQ0KPiA+IHIwMzog
MHgwMDAwMDAwMCByMDQ6IDB4ODY2OGI2MDAgcjA1OiAweDg2NzdmNDA2DQo+ID4gcjA2OiAweDg3
MDJiNjAwIHIwNzogMHgwMDAwMDAwMCByMDg6IDB4ODcwMmI2MDANCj4gPiByMDk6IDB4MDAwMDAw
MDAgcjEwOiAweDg3MGIzYjAwIHIxMTogMHgwMDAwMDAwMA0KPiA+IHIxMjogMHgwMDAwMDAwMA0K
PiA+IFsgICAzNy4wNDAwMDBdDQo+ID4gWyAgIDM3LjA0MDAwMF0gU3RhY2sgVHJhY2U6DQo+ID4g
WyAgIDM3LjA0MDAwMF0gICBtd2lmaWV4X3NjYW5fbmV0d29ya3MrMHgxOGEvMHgxOThjIFttd2lm
aWV4XQ0KPiA+DQo+ID4gUm9vdCBjYXVzZToNCj4gPiBtd2lmaWV4IGRyaXZlciBjYWxscyBpc196
ZXJvX2V0aGVyX2FkZHIoKSBhZ2FpbnN0IGJ5dGUtYWxpZ25lZA0KPiBhZGRyZXNzOg0KPiA+DQo+
ID4gZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L2Z3Lmg6DQo+ID4gc3RydWN0
IG13aWZpZXhfc2Nhbl9jbWRfY29uZmlnIHsNCj4gPiAgICAgICAgIC8qDQo+ID4gICAgICAgICAg
KiAgQlNTIG1vZGUgdG8gYmUgc2VudCBpbiB0aGUgZmlybXdhcmUgY29tbWFuZA0KPiA+ICAgICAg
ICAgICovDQo+ID4gICAgICAgICB1OCBic3NfbW9kZTsNCj4gPg0KPiA+ICAgICAgICAgLyogU3Bl
Y2lmaWMgQlNTSUQgdXNlZCB0byBmaWx0ZXIgc2NhbiByZXN1bHRzIGluIHRoZSBmaXJtd2FyZQ0K
PiAqLw0KPiA+ICAgICAgICAgdTggc3BlY2lmaWNfYnNzaWRbRVRIX0FMRU5dOw0KPiA+DQo+ID4g
ICAgICAgICAuLi4NCj4gPiB9IF9fcGFja2VkOw0KPiA+DQo+ID4gZHJpdmVycy9uZXQvd2lyZWxl
c3MvbWFydmVsbC9td2lmaWV4L3NjYW4uYzoNCj4gPiBtd2lmaWV4X2NvbmZpZ19zY2FuKC4uLiwg
c3RydWN0IG13aWZpZXhfc2Nhbl9jbWRfY29uZmlnICpzY2FuX2NmZ19vdXQsDQo+IC4uLikNCj4g
PiAgICAgICAgIC4uLg0KPiA+ICAgICAgICAgaWYgKGFkYXB0ZXItPmV4dF9zY2FuICYmDQo+ID4g
ICAgICAgICAgICAgIWlzX3plcm9fZXRoZXJfYWRkcihzY2FuX2NmZ19vdXQtPnNwZWNpZmljX2Jz
c2lkKSkgew0KPiA+ICAgICAgICAgICAgIC4uLg0KPiA+ICAgICAgICAgfQ0KPiA+DQo+ID4gU2lu
Y2UgZmlybXdhcmUtcmVsYXRlZCBzdHJ1Y3QgbXdpZmlleF9zY2FuX2NtZF9jb25maWcgY2Fubm90
IGJlDQo+ID4gY2hhbmdlZCwgd2UgbmVlZCB0byB1c2UgdGhlIG5ldyBmdW5jdGlvbg0KPiBpc196
ZXJvX2V0aGVyX2FkZHJfdW5hbGlnbmVkKCkgaGVyZS4NCj4gPg0KPiA+IFRoaXMgaXMgdjIgb2Yg
dGhlIG9yaWdpbmFsIHBhdGNoOg0KPiA+IFtQQVRDSF0gTW9kaWZ5IGlzX3plcm9fZXRoZXJfYWRk
cigpIHRvIGhhbmRsZSBieXRlLWFsaWduZWQgYWRkcmVzc2VzDQo+ID4NCj4gPiBQZXIgSm9lJ3Mg
c3VnZ2VzdGlvbiAtLSBpbnN0ZWFkIG9mIG1vZGlmeWluZyBpc196ZXJvX2V0aGVyX2FkZHIoKSAt
LQ0KPiA+IGFkZCBpc196ZXJvX2V0aGVyX2FkZHJfdW5hbGlnbmVkKCkgYW5kIHVzZSBpdCB3aGVy
ZSBuZWVkZWQuDQo+ID4NCj4gPiBDYzogS2FsbGUgVmFsbyA8a3ZhbG9AY29kZWF1cm9yYS5vcmc+
DQo+ID4gQ2M6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4NCj4gPiBDYzog
Sm9lIFBlcmNoZXMgPGpvZUBwZXJjaGVzLmNvbT4NCj4gPiBDYzogQW1pdGt1bWFyIEthcndhciA8
YWthcndhckBtYXJ2ZWxsLmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBQZXRyaSBHeW50aGVyIDxw
Z3ludGhlckBnb29nbGUuY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL25ldC93aXJlbGVzcy9t
YXJ2ZWxsL213aWZpZXgvc2Nhbi5jIHwgMyArKy0NCj4gPiAgMSBmaWxlIGNoYW5nZWQsIDIgaW5z
ZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv
bmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9zY2FuLmMNCj4gPiBiL2RyaXZlcnMvbmV0L3dp
cmVsZXNzL21hcnZlbGwvbXdpZmlleC9zY2FuLmMNCj4gPiBpbmRleCBiYzVlNTJjLi5kNjQ4Yzg4
IDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9z
Y2FuLmMNCj4gPiArKysgYi9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvc2Nh
bi5jDQo+ID4gQEAgLTg4Myw3ICs4ODMsOCBAQCBtd2lmaWV4X2NvbmZpZ19zY2FuKHN0cnVjdCBt
d2lmaWV4X3ByaXZhdGUgKnByaXYsDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICBzaXplb2Yo
c2Nhbl9jZmdfb3V0LT5zcGVjaWZpY19ic3NpZCkpOw0KPiA+DQo+ID4gICAgICAgICAgICAgICAg
IGlmIChhZGFwdGVyLT5leHRfc2NhbiAmJg0KPiA+IC0gICAgICAgICAgICAgICAgICAgIWlzX3pl
cm9fZXRoZXJfYWRkcihzY2FuX2NmZ19vdXQtPnNwZWNpZmljX2Jzc2lkKSkNCj4gew0KPiA+ICsg
ICAgICAgICAgICAgICAgICAgIWlzX3plcm9fZXRoZXJfYWRkcl91bmFsaWduZWQoDQo+ID4gKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY2FuX2NmZ19vdXQtPnNwZWNpZmljX2Jzc2lk
KSkgew0KPiANCj4gQW55IGNvbW1lbnRzPyBJcyB0aGlzIGFwcHJvYWNoIG9mIGFkZGluZw0KPiBp
c196ZXJvX2V0aGVyX2FkZHJfdW5hbGlnbmVkKCkgZmluZT8gV2UgYWxyZWFkeSBoYXZlIHNpbWls
YXIgcm91dGluZQ0KPiBldGhlcl9hZGRyX2VxdWFsX3VuYWxpZ25lZCgpLg0KPiANCj4gSSBkb24n
dCBzZWUgbXVjaCBiZW5lZml0IG1ha2luZyBhIGxvY2FsLCBhbGlnbmVkIGNvcHkgaGVyZS4gSXQg
d291bGQNCj4gaGF2ZSB0byB1c2UgbWVtY3B5IHcvIGJ5dGUgb3BlcmF0aW9ucyBhbnl3YXlzIGFu
ZCB0aGVuIHN0aWxsIHJ1bg0KPiBpc196ZXJvX2V0aGVyX2FkZHIoKS4NCj4gDQo+IEFtaXRrdW1h
ciAtLSBJcyBpdCBwb3NzaWJsZSB0byBtb2RpZnkgc3RydWN0IG13aWZpZXhfc2Nhbl9jbWRfY29u
ZmlnIHt9DQo+IGFuZCBhbGlnbiBzcGVjaWZpY19ic3NpZCBmaWVsZCB0byB1MTYgYm91bmRhcnk/
DQo+IA0KDQpXZSBjYW7igJl0IGNoYW5nZSB0aGUgc3RydWN0dXJlLiBUaGUgcmVhc29uIGlzIGZp
cm13YXJlIGF0IHJlY2VpdmluZyBlbmQgZXhwZWN0cyB0aGUgdmFyaWFibGVzIGluIHRoZSBzYW1l
IG9yZGVyLg0KaXNfemVyb19ldGhlcl9hZGRyX3VuYWxpZ25lZCgpIHNob3VsZCBiZSBmaW5lLg0K
DQpSZWdhcmRzLA0KQW1pdGt1bWFyDQo=
^ permalink raw reply
* Re: Stability connection problems in ath9k kernel 4.7
From: Kalle Valo @ 2016-09-08 17:25 UTC (permalink / raw)
To: Valerio Passini
Cc: linux-wireless, Omer Peleg, Adam Morrison, David Woodhouse,
linux-kernel, Joerg Roedel, iommu
In-Reply-To: <2596121.7secQ7hYiJ@automatix>
Valerio Passini <valerio.passini@unicam.it> writes:
> On mercoledì 7 settembre 2016 11:32:24 CEST Kalle Valo wrote:
>> 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.
>
> Hi Kalle,
>
> I tried to understand the whole procedure related to git and git bisect, and
> this is the first time I try it, so I can have done some mistake. In the git
> log you'll find the commit that could be guilty for the behaviour I reported
> yesterday. Anyhow, the resulting commit doesn't make any sense to me.
So your bisect found this as the bad commit:
commit 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270
Author: Omer Peleg <omer@cs.technion.ac.il>
Date: Wed Apr 20 11:34:11 2016 +0300
iommu/iova: introduce per-cpu caching to iova allocation
The ath9k log you provided has a DMA warning and iommu problems can
cause DMA problems but I cannot make any conclusions yet. To confirm
that this commit really is the problem you could try to revert it with
'git revert -n 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270'. For some
reason I got conflicts but if you are good enough with C you could try
to fix those yourself. Another option is that you disable iommu and see
if that helps.
I'm adding more people and mailing lists related to this commit,
hopefully they have better ideas.
This is Valerio's bisect log:
git bisect start
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
# bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e
# good: [0694f0c9e20c47063e4237e5f6649ae5ce5a369a] radix tree test suite:
remove dependencies on height
git bisect good 0694f0c9e20c47063e4237e5f6649ae5ce5a369a
# good: [e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697] Merge branch 'for-4.7-zac'
of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
git bisect good e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697
# bad: [049ec1b5a76d34a6980cccdb7c0baeb4eed7a993] Merge tag 'drm-fixes-for-
v4.7-rc2' of git://people.freedesktop.org/~airlied/linux
git bisect bad 049ec1b5a76d34a6980cccdb7c0baeb4eed7a993
# good: [a10c38a4f385f5d7c173a263ff6bb2d36021b3bb] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
git bisect good a10c38a4f385f5d7c173a263ff6bb2d36021b3bb
# bad: [9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d] Merge branch 'for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect bad 9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d
# bad: [c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd] Merge tag 'drm-fixes-v4.7-
rc1' of git://people.freedesktop.org/~airlied/linux
git bisect bad c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd
# good: [dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6] Merge branch 'misc' of
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
git bisect good dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6
# good: [e28e909c36bb5d6319953822d84df00fce7cbd18] Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good e28e909c36bb5d6319953822d84df00fce7cbd18
# good: [79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968] Merge branch 'drm-next-4.7'
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect good 79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968
# bad: [1e8143db755f745a9842984de5e8b423f583aea2] Merge tag 'platform-drivers-
x86-v4.7-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
git bisect bad 1e8143db755f745a9842984de5e8b423f583aea2
# good: [afcedebc6a094224973534f43b396bbbf33fe44e] thinkpad_acpi: save
kbdlight state on suspend and restore it on resume
git bisect good afcedebc6a094224973534f43b396bbbf33fe44e
# good: [2aac630429d986a43ac59525a4cff47a624dc58e] iommu/vt-d: change intel-
iommu to use IOVA frame numbers
git bisect good 2aac630429d986a43ac59525a4cff47a624dc58e
# bad: [2566278551d3db875bc3bbfc41b42f2e80392108] Merge git://
git.infradead.org/intel-iommu
git bisect bad 2566278551d3db875bc3bbfc41b42f2e80392108
# bad: [22e2f9fa63b092923873fc8a52955151f4d83274] iommu/vt-d: Use per-cpu IOVA
caching
git bisect bad 22e2f9fa63b092923873fc8a52955151f4d83274
# bad: [9257b4a206fc0229dd5f84b78e4d1ebf3f91d270] iommu/iova: introduce per-
cpu caching to iova allocation
git bisect bad 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270
# first bad commit: [9257b4a206fc0229dd5f84b78e4d1ebf3f91d270] iommu/iova:
introduce per-cpu caching to iova allocation
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Kalle Valo @ 2016-09-08 17:35 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, lkml,
Andy Gross, linux-arm-msm
In-Reply-To: <CAOCOHw5Wvy5g0HuDaYUZ2WTCws5uXtw6DO7S3Dvp+0mgW-Mg=Q@mail.gmail.com>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>>
>>> 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(-)
>>
>> This doesn't compile for me:
>>
>
> I thought I mentioned this in the mail, sorry for missing that.
Maybe you did and I just forgot, I have a tendency to do that :)
> There is a patch for this issue in linux-next already [1] which is
> part of [2], which was part of the pull request to arm-soc for
> inclusion in v4.9.
>
> [1] https://patchwork.kernel.org/patch/9272457/
> [2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
So the commit in question is:
soc: qcom: smd: Correct compile stub prototypes
https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9&id=3a1281848830fcb3202cfd7ffe62d19641471d05
But that's not obviously in my tree yet, but I should have it after
4.9-rc1 is released. I think it's easiest that I wait for that before
applying these. Do you agree?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] mwifiex: fix unaligned read in mwifiex_config_scan()
From: Kalle Valo @ 2016-09-08 18:01 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Petri Gynther, linux-wireless@vger.kernel.org, David Miller,
Joe Perches
In-Reply-To: <63fa0bf1951945bebc1d620c39a7c6e8@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
>> > --- a/drivers/net/wireless/marvell/mwifiex/scan.c
>> > +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
>> > @@ -883,7 +883,8 @@ mwifiex_config_scan(struct mwifiex_private *priv,
>> > sizeof(scan_cfg_out->specific_bssid));
>> >
>> > if (adapter->ext_scan &&
>> > - !is_zero_ether_addr(scan_cfg_out->specific_bssid))
>> {
>> > + !is_zero_ether_addr_unaligned(
>> > + scan_cfg_out->specific_bssid)) {
>>
>> Any comments? Is this approach of adding
>> is_zero_ether_addr_unaligned() fine? We already have similar routine
>> ether_addr_equal_unaligned().
>>
>> I don't see much benefit making a local, aligned copy here. It would
>> have to use memcpy w/ byte operations anyways and then still run
>> is_zero_ether_addr().
>>
>> Amitkumar -- Is it possible to modify struct mwifiex_scan_cmd_config {}
>> and align specific_bssid field to u16 boundary?
>>
>
> We can’t change the structure. The reason is firmware at receiving end
> expects the variables in the same order.
> is_zero_ether_addr_unaligned() should be fine.
If I understood correctly Dave doesn't like
is_zero_ether_addr_unaligned() so we can't use that either.
--
Kalle Valo
^ permalink raw reply
* support for QCA9377 SDIO (ath10k or ath6kl)
From: Martin Blumenstingl @ 2016-09-08 19:31 UTC (permalink / raw)
To: ath10k, ath6kl; +Cc: linux-wireless
Hello,
is there any support for the SDIO chips QCA9377 (and QCA9378) planned?
Would these be supported by ath10k or ath6kl or is a completely new
driver needed?
Some background:
There are some device (Android TV boxes) which are using a QCA9377
wifi chip connected via SDIO. Example: Beelink GT1 (using an Amlogic
S912 SoC) - [0]
The part in question is labeled with AW-CM273SM (could be an AzureWave
module based on the name - but that is pure speculation).
According to some google hits it uses a QCA9377 chip (which would
match with the wifi-fw tarball from Amlogic which recently gained a
"qcom9377" folder).
Regards,
Martin
[0] http://forum.xda-developers.com/android-stick--console-computers/amlogic/beelink-gt1-amlogic-912-2-16gb-t3451068
^ permalink raw reply
* [RFC] mac80211: Dynamically set CoDel parameters per station.
From: Toke Høiland-Jørgensen @ 2016-09-08 19:59 UTC (permalink / raw)
To: make-wifi-fast, linux-wireless
Cc: Toke Høiland-Jørgensen, Michal Kazior, Felix Fietkau,
Dave Taht
CoDel can be too aggressive if a station sends at a very low rate. This
gets worse the more stations are present, as each station gets more
bursty the longer the round-robin scheduling between stations takes.
This is an attempt to dynamically adjust CoDel parameters per station.
It takes a rather simple approach and uses a simple binary designation
of a station as 'slow' if it has expected throughput less than eight
Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
more lenient by adjusting its target to 50 ms and interval to 300 ms.
There's a built-in hysteresis so a station cannot flip between slow and
fast more than once every two seconds.
In this version the check is performed every time a packet is enqueued
to the intermediate queues; and the overhead of doing this is alleviated
a bit by caching the result and by the above-mentioned hysteresis. It
can probably be smarter about both when and how to do the scaling, but
this seems to alleviate some of the starvation I've seen with very slow
stations.
I'm not sure how this interacts with drivers that do rate-control in
firmware (such as ath10k). I assume they will just not be able to return
an expected rate (and so will be considered 'fast').
Cc: Michal Kazior <michal.kazior@tieto.com>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Dave Taht <dave@taht.net>
Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
---
net/mac80211/sta_info.c | 37 +++++++++++++++++++++++++++++++++++++
net/mac80211/sta_info.h | 13 +++++++++++++
net/mac80211/tx.c | 14 +++++++++++++-
3 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 19f14c9..8bc9eba 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -20,6 +20,8 @@
#include <linux/timer.h>
#include <linux/rtnetlink.h>
=20
+#include <net/codel.h>
+#include <net/codel_impl.h>
#include <net/mac80211.h>
#include "ieee80211_i.h"
#include "driver-ops.h"
@@ -325,6 +327,10 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub=
_if_data *sdata,
INIT_WORK(&sta->drv_deliver_wk, sta_deliver_ps_frames);
INIT_WORK(&sta->ampdu_mlme.work, ieee80211_ba_session_work);
mutex_init(&sta->ampdu_mlme.mtx);
+
+ codel_params_init(&sta->cparams.cparams);
+ sta->cparams.cparams.ecn =3D true;
+
#ifdef CONFIG_MAC80211_MESH
if (ieee80211_vif_is_mesh(&sdata->vif)) {
sta->mesh =3D kzalloc(sizeof(*sta->mesh), gfp);
@@ -2314,3 +2320,34 @@ unsigned long ieee80211_sta_last_active(struct sta=
_info *sta)
return stats->last_rx;
return sta->status_stats.last_ack;
}
+
+void sta_update_codel_params(struct sta_info *sta)
+{
+ u64 now =3D ktime_get_ns();
+ u32 thr;
+ bool slow;
+
+ if (likely(now - sta->cparams.update_time < STA_CPARAMS_HYSTERESIS))
+ return;
+
+ thr =3D sta_get_expected_throughput(sta);
+ slow =3D !!(thr && thr < STA_SLOW_THRESHOLD);
+
+ if (likely(slow =3D=3D sta->cparams.slow))
+ return;
+
+ net_info_ratelimited("%pM: updating CoDel params - throughput %d slow %=
s\n",
+ sta->addr, thr, slow ? "true" : "false");
+
+ if (slow) {
+ sta->cparams.cparams.target =3D MS2TIME(50);
+ sta->cparams.cparams.interval =3D MS2TIME(300);
+ sta->cparams.cparams.ecn =3D false;
+ } else {
+ sta->cparams.cparams.target =3D MS2TIME(5);
+ sta->cparams.cparams.interval =3D MS2TIME(100);
+ sta->cparams.cparams.ecn =3D true;
+ }
+ sta->cparams.update_time =3D now;
+ sta->cparams.slow =3D slow;
+}
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 0556be3..928c52d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -384,6 +384,16 @@ struct ieee80211_sta_rx_stats {
u64 msdu[IEEE80211_NUM_TIDS + 1];
};
=20
+#define STA_CPARAMS_HYSTERESIS 5 * NSEC_PER_SEC
+#define STA_SLOW_THRESHOLD 8000 /* 8 mbps */
+
+struct sta_codel_params {
+ struct codel_params cparams;
+ u64 update_time;
+ bool slow;
+};
+void sta_update_codel_params(struct sta_info *sta);
+
/**
* struct sta_info - STA information
*
@@ -437,6 +447,7 @@ struct ieee80211_sta_rx_stats {
* @known_smps_mode: the smps_mode the client thinks we are in. Relevant=
for
* AP only.
* @cipher_scheme: optional cipher scheme for this station
+ * @cparams: CoDel parameters for this station.
* @reserved_tid: reserved TID (if any, otherwise IEEE80211_TID_UNRESERV=
ED)
* @fast_tx: TX fastpath information
* @fast_rx: RX fastpath information
@@ -540,6 +551,8 @@ struct sta_info {
enum ieee80211_smps_mode known_smps_mode;
const struct ieee80211_cipher_scheme *cipher_scheme;
=20
+ struct sta_codel_params cparams;
+
u8 reserved_tid;
=20
struct cfg80211_chan_def tdls_chandef;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index efc38e7..3973ab0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1339,12 +1339,19 @@ static struct sk_buff *fq_tin_dequeue_func(struct=
fq *fq,
struct codel_vars *cvars;
struct codel_params *cparams;
struct codel_stats *cstats;
+ struct sta_info *sta;
=20
local =3D container_of(fq, struct ieee80211_local, fq);
txqi =3D container_of(tin, struct txq_info, tin);
- cparams =3D &local->cparams;
cstats =3D &local->cstats;
=20
+ if (txqi->txq.sta) {
+ sta =3D container_of(txqi->txq.sta, struct sta_info, sta);
+ cparams =3D &sta->cparams.cparams;
+ } else
+ cparams =3D &local->cparams;
+
+
if (flow =3D=3D &txqi->def_flow)
cvars =3D &txqi->def_cvars;
else
@@ -1547,6 +1554,11 @@ static bool ieee80211_tx_frags(struct ieee80211_lo=
cal *local,
=20
txqi =3D ieee80211_get_txq(local, vif, sta, skb);
if (txqi) {
+ if (sta) {
+ struct sta_info *sti =3D container_of(sta, struct sta_info, sta);
+ sta_update_codel_params(sti);
+ }
+
info->control.vif =3D vif;
=20
__skb_unlink(skb, skbs);
--=20
2.9.3
^ permalink raw reply related
* Re: [RFC] mac80211: Dynamically set CoDel parameters per station.
From: Felix Fietkau @ 2016-09-08 20:18 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
Cc: Michal Kazior, Dave Taht
In-Reply-To: <20160908195915.31478-1-toke@toke.dk>
On 2016-09-08 21:59, Toke Høiland-Jørgensen wrote:
> CoDel can be too aggressive if a station sends at a very low rate. This
> gets worse the more stations are present, as each station gets more
> bursty the longer the round-robin scheduling between stations takes.
>
> This is an attempt to dynamically adjust CoDel parameters per station.
> It takes a rather simple approach and uses a simple binary designation
> of a station as 'slow' if it has expected throughput less than eight
> Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
> more lenient by adjusting its target to 50 ms and interval to 300 ms.
> There's a built-in hysteresis so a station cannot flip between slow and
> fast more than once every two seconds.
>
> In this version the check is performed every time a packet is enqueued
> to the intermediate queues; and the overhead of doing this is alleviated
> a bit by caching the result and by the above-mentioned hysteresis. It
> can probably be smarter about both when and how to do the scaling, but
> this seems to alleviate some of the starvation I've seen with very slow
> stations.
Since this is not dealing properly with firmware rate control anyway,
I'd suggest calling the update from rate_control_set_rates in order to
avoid putting more stuff into the tx hot path.
You could add a separate code path to allow firmware rate control
devices to provide a hint at a convenient point in time.
- Felix
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Bjorn Andersson @ 2016-09-09 4:21 UTC (permalink / raw)
To: Kalle Valo
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev, lkml,
Andy Gross, linux-arm-msm
In-Reply-To: <878tv2s3ao.fsf@kamboji.qca.qualcomm.com>
On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:
> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>
> > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> >> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> >>
> >>> 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(-)
> >>
> >> This doesn't compile for me:
> >>
> >
> > I thought I mentioned this in the mail, sorry for missing that.
>
> Maybe you did and I just forgot, I have a tendency to do that :)
>
> > There is a patch for this issue in linux-next already [1] which is
> > part of [2], which was part of the pull request to arm-soc for
> > inclusion in v4.9.
> >
> > [1] https://patchwork.kernel.org/patch/9272457/
> > [2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
>
> So the commit in question is:
>
> soc: qcom: smd: Correct compile stub prototypes
> https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9&id=3a1281848830fcb3202cfd7ffe62d19641471d05
>
Correct
> But that's not obviously in my tree yet, but I should have it after
> 4.9-rc1 is released. I think it's easiest that I wait for that before
> applying these. Do you agree?
>
Would be nice to have it land sooner rather than later, but I'm okay
with this.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Andy Gross @ 2016-09-09 4:27 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Kalle Valo, Eugene Krasnikov, wcn36xx, linux-wireless, netdev,
lkml, linux-arm-msm
In-Reply-To: <20160909042159.GD405@tuxbot>
On Thu, Sep 08, 2016 at 09:21:59PM -0700, Bjorn Andersson wrote:
> On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:
>
> > Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> >
> > > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> > >> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> > >>
> > >>> 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(-)
> > >>
> > >> This doesn't compile for me:
> > >>
> > >
> > > I thought I mentioned this in the mail, sorry for missing that.
> >
> > Maybe you did and I just forgot, I have a tendency to do that :)
> >
> > > There is a patch for this issue in linux-next already [1] which is
> > > part of [2], which was part of the pull request to arm-soc for
> > > inclusion in v4.9.
> > >
> > > [1] https://patchwork.kernel.org/patch/9272457/
> > > [2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> >
> > So the commit in question is:
> >
> > soc: qcom: smd: Correct compile stub prototypes
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9&id=3a1281848830fcb3202cfd7ffe62d19641471d05
> >
>
> Correct
>
> > But that's not obviously in my tree yet, but I should have it after
> > 4.9-rc1 is released. I think it's easiest that I wait for that before
> > applying these. Do you agree?
> >
>
> Would be nice to have it land sooner rather than later, but I'm okay
> with this.
We could just treat the tag as immutable. You can merge the tag in and arm-soc
can as well. it'll just get nop'd the second time it is taken. The only
downside is if arm-soc doesn't take my merge request.
Or we can wait till -rc1
Regards,
Andy
^ permalink raw reply
* Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client
From: Kalle Valo @ 2016-09-09 5:17 UTC (permalink / raw)
To: Andy Gross
Cc: Bjorn Andersson, Eugene Krasnikov, wcn36xx, linux-wireless,
netdev, lkml, linux-arm-msm
In-Reply-To: <20160909042754.GA32071@hector.attlocal.net>
Andy Gross <andy.gross@linaro.org> writes:
>> > >> This doesn't compile for me:
>> > >>
>> > >
>> > > I thought I mentioned this in the mail, sorry for missing that.
>> >
>> > Maybe you did and I just forgot, I have a tendency to do that :)
>> >
>> > > There is a patch for this issue in linux-next already [1] which is
>> > > part of [2], which was part of the pull request to arm-soc for
>> > > inclusion in v4.9.
>> > >
>> > > [1] https://patchwork.kernel.org/patch/9272457/
>> > > [2] https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
>> >
>> > So the commit in question is:
>> >
>> > soc: qcom: smd: Correct compile stub prototypes
>> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9&id=3a1281848830fcb3202cfd7ffe62d19641471d05
>> >
>>
>> Correct
>>
>> > But that's not obviously in my tree yet, but I should have it after
>> > 4.9-rc1 is released. I think it's easiest that I wait for that before
>> > applying these. Do you agree?
>> >
>>
>> Would be nice to have it land sooner rather than later, but I'm okay
>> with this.
>
> We could just treat the tag as immutable. You can merge the tag in and arm-soc
> can as well. it'll just get nop'd the second time it is taken. The only
> downside is if arm-soc doesn't take my merge request.
I take it that you are talking about this tag:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git qcom-drivers-for-4.9
I did a test pull and there are only 8 commits so in theory that could
work. But my trees go via Dave Miller's net-next so I can't control when
they hit Linus' tree. It might be that Linus pulls the net-next tree
before arm-soc and arm-soc commits coming from net-next might confuse
people. I'm just afraid that the hassle would outweight the benefit.
> Or we can wait till -rc1
To keep things simple I prefer this option. Of course it means waiting
few more extra weeks, but when working with new subsystems that can
happen. The crystall ball[1] says that 4.9-rc1 would be released on
2016-10-16 so it's not that far away.
[1] http://phb-crystal-ball.org/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Oleksij Rempel @ 2016-09-09 7:48 UTC (permalink / raw)
To: Martin Blumenstingl, ath9k-devel, devicetree, linux-wireless,
ath9k-devel
Cc: mcgrof, mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, nbd
In-Reply-To: <20160906214623.20424-2-martin.blumenstingl@googlemail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3989 bytes --]
Hallo all,
if it is not too late i would add my two cents :)
Am 06.09.2016 um 23:46 schrieb Martin Blumenstingl:
> 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
Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
case we need to use clock framework any way, so why not in this case too?
Provide dummy static clock in DT and connect it with this node?
osc25m: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
clock-accuracy = <30000>;
};
acc: clock-controller@80040000 {
compatible = "some-clock-controller";
#clock-cells = <1>;
clocks = <&osc25m>;
reg = <0x80040000 0x204>;
};
&pci0 {
ath9k@168c,002d {
compatible = "pci168c,002d";
reg = <0x7000 0 0 0 0x1000>;
clocks = <&osc25m>;
qca,disable-5ghz;
};
};
driver will need to use clk_get and compare frequency instead of
of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
to define source clock only one time and reuse it by all affected DT
nodes. If we have 40MHz clock you will only need to change it in
fixed-clock.
> +- 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.
This option can be reused for every WiFi controller. Not only for qca.
So may be instead of adding vendor specific name, make it reusable for
all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
disable-5ghz and disable-2ghz?
> +- 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;
> + };
> +};
>
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply
* Re: Stability connection problems in ath9k kernel 4.7
From: Joerg Roedel @ 2016-09-09 8:38 UTC (permalink / raw)
To: Valerio Passini
Cc: Kalle Valo, Adam Morrison, linux-wireless, Omer Peleg,
linux-kernel, iommu, David Woodhouse
In-Reply-To: <CAC6K2=_Hdkgc_6igoC59J_Cn9=bdye827zbEK7PWtZY6ebh-6Q@mail.gmail.com>
Hi Valerio,
On Thu, Sep 08, 2016 at 09:07:56PM +0200, Valerio Passini wrote:
> I'm hoping having done it right and I can try your first suggestion, but I
> really cannot solve this problem by myself: sorry, I have no capabilities in
> programming in any known and unknown computer language. Surely, I can test all
> the patches you want and report the results but this is the best I can do. Best
> regards
Can you please send me the full dmesg after boot? The Intel-IOMMU is not
enabled by default, so I want to check if it is either enabled by
kernel-config or kernel command-line.
Thanks,
Joerg
^ permalink raw reply
* Re: [v2] bcma: use of_dma_configure() to set initial dma mask
From: Kalle Valo @ 2016-09-09 9:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rafał Miłecki, Arnd Bergmann, Hauke Mehrtens,
linux-wireless, linux-kernel
In-Reply-To: <1458207563-3453369-1-git-send-email-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> While fixing another bug, I noticed that bcma manually sets up
> a dma_mask pointer for its child devices. We have a generic
> helper for that now, which should be able to cope better with
> any variations that might be needed to deal with cache coherency,
> unusual DMA address offsets, iommus, or limited DMA masks, none
> of which are currently handled here.
>
> This changes the core to use the of_dma_configure(), like
> we do for platform devices that are probed directly from
> DT.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks, 1 patch applied to wireless-drivers-next.git:
defb893fffef bcma: use of_dma_configure() to set initial dma mask
--
Sent by pwcli
https://patchwork.kernel.org/patch/8608751/
^ permalink raw reply
* Re: [v5,1/2] mwifiex: add manufacturing mode support
From: Kalle Valo @ 2016-09-09 9:06 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Xinming Hu,
Amitkumar Karwar
In-Reply-To: <1472801707-6939-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> By default normal mode is chosen when driver is loaded. This
> patch adds a provision to choose manufacturing mode via module
> parameters.
>
> Below command loads driver in manufacturing mode
> insmod mwifiex.ko mfg_mode=1.
>
> Tested-by: chunfan chen <jeffc@marvell.com>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 2 patches applied to wireless-drivers-next.git:
cf5383b088d0 mwifiex: add manufacturing mode support
3935ccc14d2c mwifiex: add cfg80211 testmode support
--
Sent by pwcli
https://patchwork.kernel.org/patch/9310499/
^ permalink raw reply
* Re: [PATCHv8,1/4] add basic register-field manipulation macros
From: Kalle Valo @ 2016-09-09 9:11 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Linux Wireless List, Jakub Kicinski
In-Reply-To: <1472644007-20959-2-git-send-email-jakub.kicinski@netronome.com>
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> Common approach to accessing register fields is to define
> structures or sets of macros containing mask and shift pair.
> Operations on the register are then performed as follows:
>
> field = (reg >> shift) & mask;
>
> reg &= ~(mask << shift);
> reg |= (field & mask) << shift;
>
> Defining shift and mask separately is tedious. Ivo van Doorn
> came up with an idea of computing them at compilation time
> based on a single shifted mask (later refined by Felix) which
> can be used like this:
>
> #define REG_FIELD 0x000ff000
>
> field = FIELD_GET(REG_FIELD, reg);
>
> reg &= ~REG_FIELD;
> reg |= FIELD_PREP(REG_FIELD, field);
>
> FIELD_{GET,PREP} macros take care of finding out what the
> appropriate shift is based on compilation time ffs operation.
>
> GENMASK can be used to define registers (which is usually
> less error-prone and easier to match with datasheets).
>
> This approach is the most convenient I've seen so to limit code
> multiplication let's move the macros to a global header file.
> Attempts to use static inlines instead of macros failed due
> to false positive triggering of BUILD_BUG_ON()s, especially with
> GCC < 6.0.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dinan Gunawardena <dinan.gunawardena@netronome.com>
Thanks, 4 patches applied to wireless-drivers-next.git:
3e9b3112ec74 add basic register-field manipulation macros
faad5433b722 mt7601u: remove redefinition of GENMASK
adcc710d0a9e mt7601u: remove unnecessary include
d43af50566b4 mt7601u: use linux/bitfield.h
--
Sent by pwcli
https://patchwork.kernel.org/patch/9306999/
^ permalink raw reply
* Re: [1/2] brcmfmac: add support for bcm4339 chip with modalias sdio:c00v02D0d4339
From: Kalle Valo @ 2016-09-09 9:12 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1473072133-4266-2-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> The driver already supports the bcm4339 chipset but only for the variant
> that shares the same modalias as the bcm4335, ie. sdio:c00v02D0d4335.
> It turns out that there are also bcm4339 devices out there that have a
> more distiguishable modalias sdio:c00v02D0d4339.
>
> Reported-by: Steve deRosier <derosier@gmail.com>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Thanks, 2 patches applied to wireless-drivers-next.git:
634faf368690 brcmfmac: add support for bcm4339 chip with modalias sdio:c00v02D0d4339
5251b6be8bb5 brcmfmac: sdio: shorten retry loop in brcmf_sdio_kso_control()
--
Sent by pwcli
https://patchwork.kernel.org/patch/9313473/
^ permalink raw reply
* Re: mwifiex: PCIe8997 chip specific handling
From: Kalle Valo @ 2016-09-09 9:14 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1469788731-5361-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> The patch corrects the revision id register and uses it along with
> magic value and chip version registers to download appropriate firmware
> image.
>
> PCIe8997 Z chipset variant code has been removed, as it won't be used in
> production.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Does apply, please rebase:
Applying: mwifiex: PCIe8997 chip specific handling
fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/pcie.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 mwifiex: PCIe8997 chip specific handling
--
Sent by pwcli
https://patchwork.kernel.org/patch/9252431/
^ permalink raw reply
* Re: mwifiex: add PCIe function level reset support
From: Kalle Valo @ 2016-09-09 9:18 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, Amitkumar Karwar
In-Reply-To: <1469541704-2880-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> This patch implements pre and post FLR handlers to support PCIe FLR
> functionality. Software cleanup is performed in pre-FLR whereas
> firmware is downloaded and software is re-initialised in
> post-FLR handler.
>
> Following command triggers FLR.
> echo "1" > /sys/bus/pci/devices/$NUMBER/reset
>
> This feature can be used as a recovery mechanism when firmware gets
> hang.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
4c5dae59d2e9 mwifiex: add PCIe function level reset support
--
Sent by pwcli
https://patchwork.kernel.org/patch/9248233/
^ permalink raw reply
* Re: mwifiex: add PCIe function level reset support
From: Kalle Valo @ 2016-09-09 9:19 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <86c718ca301b4da2ba814c049b78e6b3@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
>> Doesn't apply anymore, please rebase.
>>
>> Applying: mwifiex: add PCIe function level reset support
>> fatal: sha1 information is lacking or useless
>> (drivers/net/wireless/marvell/mwifiex/main.c).
>> Repository lacks necessary blobs to fall back on 3-way merge.
>> Cannot fall back to three-way merge.
>> Patch failed at 0001 mwifiex: add PCIe function level reset support
>
> It gets applied smoothly if below patches are applied first.
> https://patchwork.kernel.org/patch/9310499/ ([v5,1/2] mwifiex: add manufacturing mode support)
> https://patchwork.kernel.org/patch/9310501/ ([v5,2/2] mwifiex: add cfg80211 testmode support)
>
> Please let me know if you want me to rebase "PCIe function level reset
> support". In that case I need to rebase and send above 2 patches as
> well.
Yes, I was able to apply this after those patches. No need to resend.
--
Kalle Valo
^ permalink raw reply
* Re: mwifiex: scan: Simplify code
From: Kalle Valo @ 2016-09-09 9:21 UTC (permalink / raw)
To: Christophe Jaillet
Cc: akarwar, nishants, linux-wireless, netdev, linux-kernel,
kernel-janitors, Christophe JAILLET
In-Reply-To: <1472644259-15605-1-git-send-email-christophe.jaillet@wanadoo.fr>
Christophe Jaillet <christophe.jaillet@wanadoo.fr> wrote:
> This patch:
> - improves code layout
> - removes a useless memset(0) for some memory allocated with kzalloc
> - removes a useless if. We know that 'if (chan_band_tlv)' will succeed
> because it has been tested a few lines above
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Thanks, 1 patch applied to wireless-drivers-next.git:
b71165761694 mwifiex: scan: Simplify code
--
Sent by pwcli
https://patchwork.kernel.org/patch/9307009/
^ permalink raw reply
* Re: [RFC] mac80211: Dynamically set CoDel parameters per station.
From: Toke Høiland-Jørgensen @ 2016-09-09 9:51 UTC (permalink / raw)
To: Felix Fietkau; +Cc: make-wifi-fast, linux-wireless, Michal Kazior, Dave Taht
In-Reply-To: <2663e4fb-bcdf-a872-f5ab-fac3bb5344c1@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> On 2016-09-08 21:59, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>> CoDel can be too aggressive if a station sends at a very low rate. This
>> gets worse the more stations are present, as each station gets more
>> bursty the longer the round-robin scheduling between stations takes.
>>=20
>> This is an attempt to dynamically adjust CoDel parameters per station.
>> It takes a rather simple approach and uses a simple binary designation
>> of a station as 'slow' if it has expected throughput less than eight
>> Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
>> more lenient by adjusting its target to 50 ms and interval to 300 ms.
>> There's a built-in hysteresis so a station cannot flip between slow and
>> fast more than once every two seconds.
>>=20
>> In this version the check is performed every time a packet is enqueued
>> to the intermediate queues; and the overhead of doing this is alleviated
>> a bit by caching the result and by the above-mentioned hysteresis. It
>> can probably be smarter about both when and how to do the scaling, but
>> this seems to alleviate some of the starvation I've seen with very slow
>> stations.
> Since this is not dealing properly with firmware rate control anyway,
> I'd suggest calling the update from rate_control_set_rates in order to
> avoid putting more stuff into the tx hot path.
Yeah, I wasn't expecting that to stay in the TX path, but was not
familiar enough with minstrel to know where a good place would be.
Thanks for the pointer.
> You could add a separate code path to allow firmware rate control
> devices to provide a hint at a convenient point in time.
There's already a get_expected_throughput() driver hook; but no drivers
seem to be using it? But I assume you mean a hook the other way, i.e.
export a function where the driver can tell mac80211 "my expected
throughput changed, please update"?
-Toke
^ 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