* [PATCH 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv
From: Amitkumar Karwar @ 2016-10-24 14:21 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, dmitry.torokhov, briannorris,
Amitkumar Karwar
In-Reply-To: <1477318892-22877-1-git-send-email-akarwar@marvell.com>
This variable is guarded by spinlock at all other places. This patch
takes care of missing spinlock usage in mwifiex_shutdown_drv().
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/init.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index 82839d9..8e5e424 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -670,11 +670,14 @@ mwifiex_shutdown_drv(struct mwifiex_adapter *adapter)
adapter->hw_status = MWIFIEX_HW_STATUS_CLOSING;
/* wait for mwifiex_process to complete */
+ spin_lock_irqsave(&adapter->main_proc_lock, flags);
if (adapter->mwifiex_processing) {
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
mwifiex_dbg(adapter, WARN,
"main process is still running\n");
return ret;
}
+ spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
/* cancel current command */
if (adapter->curr_cmd) {
--
1.9.1
^ permalink raw reply related
* [PATCH 1/5] mwifiex: remove redundant condition in main process
From: Amitkumar Karwar @ 2016-10-24 14:21 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, dmitry.torokhov, briannorris,
Amitkumar Karwar
This condition while calling mwifiex_check_ps_cond() is redundant.
The function internally already takes care of it.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 2478ccd..3b31ea2 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -355,10 +355,8 @@ process_start:
/* Check if we need to confirm Sleep Request
received previously */
- if (adapter->ps_state == PS_STATE_PRE_SLEEP) {
- if (!adapter->cmd_sent && !adapter->curr_cmd)
- mwifiex_check_ps_cond(adapter);
- }
+ if (adapter->ps_state == PS_STATE_PRE_SLEEP)
+ mwifiex_check_ps_cond(adapter);
/* * The ps_state may have been changed during processing of
* Sleep Request event.
--
1.9.1
^ permalink raw reply related
* RE: [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Undekari, Sunil Dutt @ 2016-10-24 14:20 UTC (permalink / raw)
To: Johannes Berg, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <1477316138.4085.19.camel@sipsolutions.net>
T0sgLiBUaGFua3MgLiBXZSBzaGFsbCB3YWl0IGZvciB0aGVtIHRvIGdldCB1cCBzdHJlYW1lZC4N
Cg0KUmVnYXJkcywNClN1bmlsDQogIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogSm9oYW5uZXMgQmVyZyBbbWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdIA0KU2Vu
dDogTW9uZGF5LCBPY3RvYmVyIDI0LCAyMDE2IDc6MDYgUE0NClRvOiBVbmRla2FyaSwgU3VuaWwg
RHV0dCA8dXNkdXR0QHF0aS5xdWFsY29tbS5jb20+OyBLdXNod2FoYSwgUHVydXNob3R0YW0gPHBr
dXNod2FoQHF0aS5xdWFsY29tbS5jb20+DQpDYzogbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwu
b3JnOyBNYWxpbmVuLCBKb3VuaSA8am91bmlAcWNhLnF1YWxjb21tLmNvbT47IEh1bGx1ciBTdWJy
YW1hbnlhbSwgQW1hcm5hdGggPGFtYXJuYXRoQHFjYS5xdWFsY29tbS5jb20+DQpTdWJqZWN0OiBS
ZTogW1BBVENIIHYzXSBjZmc4MDIxMTogQ2hlY2sgcmFkYXJfZGV0ZWN0IGFuZCBudW1fZGlmZmVy
ZW50X2NoYW5uZWxzIHdpdGggYmVhY29uIGludGVyZmFjZSBjb21iaW5hdGlvbnMuDQoNCk9uIE1v
biwgMjAxNi0xMC0yNCBhdCAxMTo1OSArMDAwMCwgVW5kZWthcmksIFN1bmlsIER1dHQgd3JvdGU6
DQo+ID4gDQo+ID4gSSd2ZSBqdXN0IHNlbnQgb3V0IGEgZmV3IHBhdGNoZXMgdGhhdCwgSSB0aGlu
aywgaW1wbGVtZW50IHRoZSANCj4gPiBuZWNlc3NhcnkgdmFsaWRhdGlvbiBmb3IganVzdCB0aGUg
YmVhY29uIGludGVydmFscywgd2l0aG91dCBhbGwgdGhpcyANCj4gPiBleHRyYSBiYWdnYWdlLiBQ
bGVhc2UgdGFrZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93IHdoYXQgeW91IHRoaW5rLg0KPiBJIHVu
ZGVyc3RhbmQgdGhhdCB0aGUgbmV3IHBhdGNoZXMgZnJvbSB5b3UgYXJlIGluIGNvbnNpc3RlbnQg
d2l0aCB0aGUgDQo+IGV4aXN0aW5nIGRlc2lnbiBvZiB2YWxpZGF0aW5nIHRoZSByYWRhciBkZXRl
Y3Rpb24gLyBjaGFubmVscyBieSBoYXZpbmcgDQo+IHRoaXMgdmFsaWRhdGlvbiBkb25lIGluIHRo
ZSBjZmc4MDIxMSBkcml2ZXJzIHRocm91Z2ggDQo+IGNmZzgwMjExX2NoZWNrX2NvbWJpbmF0aW9u
cy4NCg0KT2ssIHNvIHdlIGFncmVlIGhlcmUsIHRoYXQncyBnb29kIDopDQoNCj4gV2l0aCB0aGlz
IGFwcHJvYWNoICwgd291bGRuJ3QgdGhlIGV4aXN0aW5nIGNmZzgwMjExIGRyaXZlcnMgYmVoYXZl
IHRoZSANCj4gb3RoZXIgd2F5ID8gSSBtZWFuICwgd2l0aCB0aGVzZSBjb21taXRzIGFuZCB0aGUg
Y3VycmVudCBjZmc4MDIxMSANCj4gZHJpdmVycyAoIGRvIG5vdCBhZHZlcnRpc2UgYmVhY29uX2lu
dF9taW5fZ2NkIGFuZCBpbnZva2UNCj4gY2ZnODAyMTFfY2hlY2tfY29tYmluYXRpb25zKSAsIHRo
ZSB2YWxpZGF0aW9uIGZvciB0aGUgZGlmZmVyZW50IGJlYWNvbiANCj4gaW50ZXJ2YWwgc2hhbGwg
c3VjY2VlZCAsIGJ1dCB0aGUgY3VycmVudCBrZXJuZWwgKCBjZmc4MDIxMSBpbnRlcmZhY2UgKSAN
Cj4gd2l0aCB0aGUgc2FtZSBkcml2ZXIgZmFpbHMgdGhlIHN0YXJ0IG9mIHRoZSBBUCAvIG1lc2gu
DQo+IElzIGl0IG5vdCBicmVha2luZyB0aGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSA/IElzIHRo
aXMgZXhwZWN0ZWQgPw0KDQpBbnkgZHJpdmVyIHRoYXQgc3VwcG9ydHMgY29tYmluYXRpb25zIHNo
b3VsZCBhbHNvIGludm9rZSBjaGVja19jb21iaW5hdGlvbnMuIFRoaXMgZG9lc24ndCBhcHBlYXIg
dG8gYmUgdHJ1ZSBmb3IgbXdpZmlleCwgYnV0IHRoYXQncyBhbHJlYWR5IGEgYnVnL3Byb2JsZW0g
aW4gdGhhdCBkcml2ZXIsIGl0IGRvZXNuJ3QgcmVhbGx5IGNoYW5nZSBtdWNoPw0KDQpqb2hhbm5l
cw0K
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Johannes Berg @ 2016-10-24 14:16 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: Antonio Quartulli, linux-wireless
In-Reply-To: <3178350.ZYYEYN7rIx@prime>
On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote:
> Otherwise, it would be pretty much impossible to perform CSAs to
> another DFS channel.
I was told that to do that you'd need another NIC that's pre-CAC'ing
another channel.
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Michal Kazior @ 2016-10-24 14:07 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: Johannes Berg, Antonio Quartulli, linux-wireless
In-Reply-To: <3178350.ZYYEYN7rIx@prime>
On 24 October 2016 at 15:42, Simon Wunderlich <sw@simonwunderlich.de> wrote=
:
> On Monday, October 24, 2016 3:33:24 PM CEST Johannes Berg wrote:
>> > > I think it would be reasonable only if the target channel is the
>> > > one we are using and we have done CSA. But when scanning non-
>> > > operative channels I don't think this could work.
>> >
>> > this has been sleeping for a while.. :)
>> > Would it make sense to rebase it and resubmit it for inclusion?
>> >
>> > Given the previous discussion we could change the logic as:
>> > * always passively scan DFS channels that are not usable
>> > * always actively scan DFS channels that are usable (i.e. CAC was
>> > performed).
>>
>> Doesn't that contradict what you said above?
>>
>> If we scan, don't we possibly lose our CAC result anyway, since we went
>> off-channel? In FCC at least? In ETSI I think we're allowed to do that
>> for a bit?
>
> I believe going off-channel was allowed in general - in fact, some router=
s CAC
> all channels on boot up and then keep the "usable" state forever.
I recall a discussion around this behavior [scan all on boot] a long
time ago. I believe earlier ETSI spec revisions allowed it but recent
ones made it more explicit that you can't cache CAC results like that
but don't take my word for it. I don't have have the spec on me now so
can't check.
Micha=C5=82
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Simon Wunderlich @ 2016-10-24 13:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: Antonio Quartulli, linux-wireless
In-Reply-To: <1477316004.4085.17.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
On Monday, October 24, 2016 3:33:24 PM CEST Johannes Berg wrote:
> > > I think it would be reasonable only if the target channel is the
> > > one we are using and we have done CSA. But when scanning non-
> > > operative channels I don't think this could work.
> >
> > this has been sleeping for a while.. :)
> > Would it make sense to rebase it and resubmit it for inclusion?
> >
> > Given the previous discussion we could change the logic as:
> > * always passively scan DFS channels that are not usable
> > * always actively scan DFS channels that are usable (i.e. CAC was
> > performed).
>
> Doesn't that contradict what you said above?
>
> If we scan, don't we possibly lose our CAC result anyway, since we went
> off-channel? In FCC at least? In ETSI I think we're allowed to do that
> for a bit?
I believe going off-channel was allowed in general - in fact, some routers CAC
all channels on boot up and then keep the "usable" state forever.
Otherwise, it would be pretty much impossible to perform CSAs to another DFS
channel.
Cheers,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Antonio Quartulli @ 2016-10-24 13:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <1477316004.4085.17.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
On Mon, Oct 24, 2016 at 03:33:24PM +0200, Johannes Berg wrote:
>
> > > I think it would be reasonable only if the target channel is the
> > > one we are using and we have done CSA. But when scanning non-
> > > operative channels I don't think this could work.
>
> > this has been sleeping for a while.. :)
> > Would it make sense to rebase it and resubmit it for inclusion?
> >
> > Given the previous discussion we could change the logic as:
> > * always passively scan DFS channels that are not usable
> > * always actively scan DFS channels that are usable (i.e. CAC was
> > performed).
>
> Doesn't that contradict what you said above?
>
> If we scan, don't we possibly lose our CAC result anyway, since we went
> off-channel? In FCC at least? In ETSI I think we're allowed to do that
> for a bit?
argh. ok, I think I had forgotten about this detail.
>
> Anyway, why not just always scan passively, to simplify?
>
Probably better..ok let's do it this way.
Thanks !
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Johannes Berg @ 2016-10-24 13:35 UTC (permalink / raw)
To: Undekari, Sunil Dutt, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <9a1df5c048894351bbec2d502772b862@aphydexm01f.ap.qualcomm.com>
On Mon, 2016-10-24 at 11:59 +0000, Undekari, Sunil Dutt wrote:
> >
> > I've just sent out a few patches that, I think, implement the
> > necessary validation for just the beacon intervals, without all
> > this extra baggage. Please take a look and let me know what you
> > think.
> I understand that the new patches from you are in consistent with the
> existing design of validating the radar detection / channels by
> having this validation done in the cfg80211 drivers through
> cfg80211_check_combinations.
Ok, so we agree here, that's good :)
> With this approach , wouldn't the existing cfg80211 drivers behave
> the other way ? I mean , with these commits and the current cfg80211
> drivers ( do not advertise beacon_int_min_gcd and invoke
> cfg80211_check_combinations) , the validation for the different
> beacon interval shall succeed , but the current kernel ( cfg80211
> interface ) with the same driver fails the start of the AP / mesh.
> Is it not breaking the backward compatibility ? Is this expected ?
Any driver that supports combinations should also invoke
check_combinations. This doesn't appear to be true for mwifiex, but
that's already a bug/problem in that driver, it doesn't really change
much?
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Johannes Berg @ 2016-10-24 13:33 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <20161024121129.GA8925@prodigo.lan>
> > I think it would be reasonable only if the target channel is the
> > one we are using and we have done CSA. But when scanning non-
> > operative channels I don't think this could work.
> this has been sleeping for a while.. :)
> Would it make sense to rebase it and resubmit it for inclusion?
>
> Given the previous discussion we could change the logic as:
> * always passively scan DFS channels that are not usable
> * always actively scan DFS channels that are usable (i.e. CAC was
> performed).
Doesn't that contradict what you said above?
If we scan, don't we possibly lose our CAC result anyway, since we went
off-channel? In FCC at least? In ETSI I think we're allowed to do that
for a bit?
Anyway, why not just always scan passively, to simplify?
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested
From: Antonio Quartulli @ 2016-10-24 12:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <564F1790.7030309@open-mesh.com>
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
On Fri, Nov 20, 2015 at 08:52:32PM +0800, Antonio Quartulli wrote:
> On 20/11/15 18:49, Johannes Berg wrote:
> >
> >> @@ -599,7 +599,9 @@ static int __ieee80211_start_scan(struct
> >> ieee80211_sub_if_data *sdata,
> >>
> >> if ((req->channels[0]->flags &
> >> IEEE80211_CHAN_NO_IR) ||
> >> - !req->n_ssids) {
> >> + !req->n_ssids ||
> >> + ((req->channels[0]->flags &
> >> IEEE80211_CHAN_RADAR) &&
> >> + (req->flags &
> >> NL80211_SCAN_FLAG_PASSIVE_RADAR))) {
> >> next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
> >>
> >
> > I don't really see any circumstances under which it's valid to actively
> > scan radar channels ... seems like we should do this unconditionally?
>
> I think it would be reasonable only if the target channel is the one we
> are using and we have done CSA. But when scanning non-operative channels
> I don't think this could work.
>
> As discussed on IRC I'd rather go for passively scanning any DFS channel.
>
> Cheers,
Hey Johannes,
this has been sleeping for a while.. :)
Would it make sense to rebase it and resubmit it for inclusion?
Given the previous discussion we could change the logic as:
* always passively scan DFS channels that are not usable
* always actively scan DFS channels that are usable (i.e. CAC was performed).
How does it sound? this would totally avoid the use of the switch in the scan
command.
Cheers,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re[2]: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Matthias Klein @ 2016-10-24 12:08 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless
In-Reply-To: <CA+BoTQkXtEcL9yk8_rYb3Z=CBkzs5R1LyMZfVCbGrsH_3Lx7eg@mail.gmail.com>
>I (naively) went through pci/pm git log and found the following was
>applied on 4.7-rc2 (i.e. prior to 4.7 release):
>
> commit 006d44e49a259b39947366728d65a873a19aadc0
> Author: Mika Westerberg <mika.westerberg@linux.intel.com>
> Date: Thu Jun 2 11:17:15 2016 +0300
>
> PCI: Add runtime PM support for PCIe ports
>
>From reading the commit log it seems to me like it could be it.
>
>ath10k tries to wake up the device during probing before it starts
>talking to it and it does so through MMIO/PCI config space. If it's
>not mapped properly then driver will not be able to wake it up and
>will timeout waiting for it.
>
>Can you try cherry-picking it into your 4.4.24 and see if it helps?
>
>
Thanks for the help!
Until now I did not compile a kernel for the board.
I will give it a try and come back with the results ...
Best regards,
Matthias
^ permalink raw reply
* RE: [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Undekari, Sunil Dutt @ 2016-10-24 11:59 UTC (permalink / raw)
To: Johannes Berg, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <1477052876.4068.40.camel@sipsolutions.net>
PiBJJ3ZlIGp1c3Qgc2VudCBvdXQgYSBmZXcgcGF0Y2hlcyB0aGF0LCBJIHRoaW5rLCBpbXBsZW1l
bnQgdGhlIG5lY2Vzc2FyeSB2YWxpZGF0aW9uIGZvciBqdXN0IHRoZSBiZWFjb24gaW50ZXJ2YWxz
LCB3aXRob3V0IGFsbCB0aGlzIGV4dHJhIGJhZ2dhZ2UuIFBsZWFzZSB0YWtlIGEgbG9vayBhbmQg
bGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsuDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUgbmV3IHBh
dGNoZXMgZnJvbSB5b3UgYXJlIGluIGNvbnNpc3RlbnQgd2l0aCB0aGUgZXhpc3RpbmcgZGVzaWdu
IG9mIHZhbGlkYXRpbmcgdGhlIHJhZGFyIGRldGVjdGlvbiAvIGNoYW5uZWxzIGJ5IGhhdmluZyB0
aGlzIHZhbGlkYXRpb24gZG9uZSBpbiB0aGUgY2ZnODAyMTEgZHJpdmVycyB0aHJvdWdoIGNmZzgw
MjExX2NoZWNrX2NvbWJpbmF0aW9ucy4NCldpdGggdGhpcyBhcHByb2FjaCAsIHdvdWxkbid0IHRo
ZSBleGlzdGluZyBjZmc4MDIxMSBkcml2ZXJzIGJlaGF2ZSB0aGUgb3RoZXIgd2F5ID8gSSBtZWFu
ICwgd2l0aCB0aGVzZSBjb21taXRzIGFuZCB0aGUgY3VycmVudCBjZmc4MDIxMSBkcml2ZXJzICgg
ZG8gbm90IGFkdmVydGlzZSBiZWFjb25faW50X21pbl9nY2QgYW5kIGludm9rZSBjZmc4MDIxMV9j
aGVja19jb21iaW5hdGlvbnMpICwgdGhlIHZhbGlkYXRpb24gZm9yIHRoZSBkaWZmZXJlbnQgYmVh
Y29uIGludGVydmFsIHNoYWxsIHN1Y2NlZWQgLCBidXQgdGhlIGN1cnJlbnQga2VybmVsICggY2Zn
ODAyMTEgaW50ZXJmYWNlICkgd2l0aCB0aGUgc2FtZSBkcml2ZXIgZmFpbHMgdGhlIHN0YXJ0IG9m
IHRoZSBBUCAvIG1lc2guIA0KSXMgaXQgbm90IGJyZWFraW5nIHRoZSBiYWNrd2FyZCBjb21wYXRp
YmlsaXR5ID8gSXMgdGhpcyBleHBlY3RlZCA/IA0KDQpSZWdhcmRzLA0KU3VuaWwNCg0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWlsdG86am9o
YW5uZXNAc2lwc29sdXRpb25zLm5ldF0gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjEsIDIwMTYg
NTo1OCBQTQ0KVG86IEt1c2h3YWhhLCBQdXJ1c2hvdHRhbSA8cGt1c2h3YWhAcXRpLnF1YWxjb21t
LmNvbT4NCkNjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IE1hbGluZW4sIEpvdW5p
IDxqb3VuaUBxY2EucXVhbGNvbW0uY29tPjsgVW5kZWthcmksIFN1bmlsIER1dHQgPHVzZHV0dEBx
dGkucXVhbGNvbW0uY29tPjsgSHVsbHVyIFN1YnJhbWFueWFtLCBBbWFybmF0aCA8YW1hcm5hdGhA
cWNhLnF1YWxjb21tLmNvbT4NClN1YmplY3Q6IFJlOiBbUEFUQ0ggdjNdIGNmZzgwMjExOiBDaGVj
ayByYWRhcl9kZXRlY3QgYW5kIG51bV9kaWZmZXJlbnRfY2hhbm5lbHMgd2l0aCBiZWFjb24gaW50
ZXJmYWNlIGNvbWJpbmF0aW9ucy4NCg0KT24gVGh1LCAyMDE2LTEwLTEzIGF0IDIwOjQ1ICswNTMw
LCBQdXJ1c2hvdHRhbSBLdXNod2FoYSB3cm90ZToNCj4gVGhpcyBjb21taXQgZW5oYW5jZXMgdGhl
IGN1cnJlbnQgYmVhY29uIGludGVydmFsIHZhbGlkYXRpb24gdG8gYWxzbyANCj4gY29uc2lkZXIg
dGhlICJyYWRhcl9kZXRlY3QiIGFuZCAibnVtX2RpZmZlcmVudF9jaGFubmVscyIuDQo+IA0KPiBN
b3ZlIGNhbGN1bGF0aW9uIG9mIEdDRCBmb3IgYWxsIGJlYWNvbmluZyBpbnRlcmZhY2VzIHRvIA0K
PiAiY2ZnODAyMTFfaXRlcl9jb21iaW5hdGlvbnMiLg0KPiANCj4gUmVuYW1lICJjZmc4MDIxMV92
YWxpZGF0ZV9iZWFjb25faW50IiB0byANCj4gImNmZzgwMjExX3ZhbGlkYXRlX2JlYWNvbl9jb21i
aW5hdGlvbiINCj4gYXMgdGhlIHZhbGlkYXRpb24gY29uc2lkZXJzIG90aGVyIHBhcmFtZXRlcnMu
DQoNClNvIHRoaXMgd2FzIGJldHRlciwgYnV0IEkgdGhpbmsgd2UncmUgbWl4aW5nIHRvbyBtYW55
IHRoaW5ncyBpbiBoZXJlLg0KDQpJJ20gbm90IGNvbnZpbmNlZCwgZm9yIGV4YW1wbGUsIHRoYXQg
Y2hlY2tpbmcgaWYgcmFkYXIgaXMgcmVxdWlyZWQgaXMgcmVhbGx5IHRoZSByaWdodCB0aGluZywg
aXQgbWlnaHQgc3RpbGwgYmUgZW5hYmxlZCBldmVuIGlmIGl0J3Mgbm90IHJlcXVpcmVkIChhbnkg
bW9yZSwgcmVndWxhdG9yeSBtYXkgY2hhbmdlKT8NCg0KTm90IHRoYXQgSSBkb24ndCB0aGluayB0
aGF0J3MgYSB3b3J0aHdoaWxlIGdvYWwgLSBtb3ZpbmcgbW9yZSBvZiB0aGUgZGF0YS9jYWxjdWxh
dGlvbiBiYWNrIGludG8gY2ZnODAyMTEgLSBidXQgSSBkb24ndCB0aGluayBpdCBzaG91bGQgYmUg
bWl4ZWQgaW4gaGVyZS4NCg0KSSd2ZSBqdXN0IHNlbnQgb3V0IGEgZmV3IHBhdGNoZXMgdGhhdCwg
SSB0aGluaywgaW1wbGVtZW50IHRoZSBuZWNlc3NhcnkgdmFsaWRhdGlvbiBmb3IganVzdCB0aGUg
YmVhY29uIGludGVydmFscywgd2l0aG91dCBhbGwgdGhpcyBleHRyYSBiYWdnYWdlLiBQbGVhc2Ug
dGFrZSBhIGxvb2sgYW5kIGxldCBtZSBrbm93IHdoYXQgeW91IHRoaW5rLg0KDQpqb2hhbm5lcw0K
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Michal Kazior @ 2016-10-24 11:40 UTC (permalink / raw)
To: Matthias Klein; +Cc: linux-wireless
In-Reply-To: <emfd19c3e4-1b17-443b-b80a-e6b60a49f9dc@nb-mak>
On 24 October 2016 at 12:18, Matthias Klein <matthias.klein@optimeas.de> wr=
ote:
> I also try to get a pcie wifi card (Compex WLE600VX) running in the clear=
fog
> pro board with kernel 4.4.
>
> As I read in this thread the "irg.mode=3D1" shoud help:
> https://www.spinics.net/lists/linux-wireless/msg155685.html
>
> But it is not working for me:
>
[...]
> [ 97.899370] ath10k_pci 0000:01:00.0: Refused to change power state,
> currently in D3
> [ 97.938045] ath10k_pci 0000:01:00.0: failed to wake up device : -110
> [ 97.944973] ath10k_pci: probe of 0000:01:00.0 failed with error -110
[...]
> 01:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless
> Network Adapter (rev ff) (prog-if ff)
> !!! Unknown header type 7f
The device looks completely unresponsive.
I don't think this is MSI problem. This error happens before
interrupts are even set up.
I suspect platform/PCI/PM specific problem. I would suggest bisecting
the kernel and seeing which patch is making the difference.
I (naively) went through pci/pm git log and found the following was
applied on 4.7-rc2 (i.e. prior to 4.7 release):
commit 006d44e49a259b39947366728d65a873a19aadc0
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Thu Jun 2 11:17:15 2016 +0300
PCI: Add runtime PM support for PCIe ports
>From reading the commit log it seems to me like it could be it.
ath10k tries to wake up the device during probing before it starts
talking to it and it does so through MMIO/PCI config space. If it's
not mapped properly then driver will not be able to wake it up and
will timeout waiting for it.
Can you try cherry-picking it into your 4.4.24 and see if it helps?
Micha=C5=82
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Jonas Gorski @ 2016-10-24 11:14 UTC (permalink / raw)
To: Oliver Zemann; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <faedb36a-d99c-5891-e9c6-40ecc4d54748@gmail.com>
Hi,
(please don't toppost)
On 23 October 2016 at 21:42, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> Thanks, but its still not working. I dont get any error now when i do
> modprobe and installed is the wle900
>
> [root@alarm alarm]# rmmod ath10k_pci
> [root@alarm alarm]# modprobe ath10k_pci irq_mode=1
Strange, this was working for me with a Sparklan WPEA-352ACN.
>
> but:
>
> [root@alarm alarm]# dmesg | grep ath10k
> [ 220.356314] ath10k_pci 0000:02:00.0: Refused to change power state,
> currently in D3
Maybe there is a separate issue related to this. I don't remember
seeing this message in my kernel log. (At least to me) it would be
interesting to know if it works using a LEDE image, or if it fails
there as well. I don't have a Compex card here.
You can find an sd-card image at
https://downloads.lede-project.org/snapshots/targets/mvebu/generic/ -
it won't contain any wifi drivers though, you will need to install
them separately - easiest by providing internet access over the wan
port (the single ethernet port for the pro, it defaults to dhcp
client), then running "opkg install kmod-ath10k" on shell.
Note that this kernel has MSI disabled, so you don't need to do
anything there extra.
> [ 220.394265] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> [ 220.400770] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>
> [root@alarm alarm]# cat /proc/cmdline
> console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait ath10k_pci.irq_mode=1
>
> Thanks for your patience
Regards
Jonas
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Matthias Klein @ 2016-10-24 10:18 UTC (permalink / raw)
To: linux-wireless; +Cc: Klein, Matthias
I also try to get a pcie wifi card (Compex WLE600VX) running in the
clearfog pro board with kernel 4.4.
As I read in this thread the "irg.mode=1" shoud help:
https://www.spinics.net/lists/linux-wireless/msg155685.html
But it is not working for me:
debian@clearfog:~$ lsmod
Module Size Used by
8021q 36864 0
garp 16384 1 8021q
mrp 20480 1 8021q
stp 16384 1 garp
llc 16384 2 stp,garp
bnep 20480 2
ath10k_pci 45056 0
ath10k_core 249856 1 ath10k_pci
ath 32768 1 ath10k_core
mac80211 786432 1 ath10k_core
bluetooth 385024 7 bnep
qcserial 16384 0
cfg80211 561152 3 ath,mac80211,ath10k_core
usb_wwan 16384 1 qcserial
qmi_wwan 24576 0
cdc_wdm 20480 1 qmi_wwan
usbserial 40960 2 qcserial,usb_wwan
usbnet 36864 1 qmi_wwan
mii 16384 1 usbnet
rfkill 32768 4 cfg80211,bluetooth
firmware_class 24576 1 ath10k_core
marvell_cesa 45056 0
ehci_orion 16384 0
des_generic 28672 1 marvell_cesa
mcp3021 16384 0
hwmon 16384 1 mcp3021
evbug 16384 0
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
fuse 102400 1
ipv6 532480 0
autofs4 36864 2
debian@clearfog:~$ uname -a
Linux clearfog 4.4.15-clearfog #1 SMP Wed Oct 5 00:03:36 UTC 2016 armv7l
GNU/Linux
debian@clearfog:~$ sudo rmmod ath10k_pci ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_pci
[ 69.529351] ath10k_pci 0000:01:00.0: Refused to change power state,
currently in D3
[ 69.567989] ath10k_pci 0000:01:00.0: failed to wake up device : -110
[ 69.575267] ath10k_pci: probe of 0000:01:00.0 failed with error -110
debian@clearfog:~$ sudo rmmod ath10k_pci ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_core
debian@clearfog:~$ sudo modprobe ath10k_pci irq_mode=1
[ 97.899370] ath10k_pci 0000:01:00.0: Refused to change power state,
currently in D3
[ 97.938045] ath10k_pci 0000:01:00.0: failed to wake up device : -110
[ 97.944973] ath10k_pci: probe of 0000:01:00.0 failed with error -110
debian@clearfog:~$ lspci -vvv
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
(prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f8000000-f82fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
(prog-if 00 [Normal decode])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
01:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless
Network Adapter (rev ff) (prog-if ff)
!!! Unknown header type 7f
Something else what I can try?
Best regards,
Matthias
^ permalink raw reply
* [mac80211-next:genl 9/9] net/wireless/nl80211.c:8469:63: error: expected ',' or ';' before ')' token
From: kbuild test robot @ 2016-10-24 9:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: kbuild-all, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl
head: 09566d222ce4d6aab069c8b7dc625675c6cca3fc
commit: 09566d222ce4d6aab069c8b7dc625675c6cca3fc [9/9] genetlink: introduce and use genl_family_attrbuf()
config: i386-randconfig-c0-10241534 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 09566d222ce4d6aab069c8b7dc625675c6cca3fc
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/wireless/nl80211.c: In function 'nl80211_testmode_dump':
>> net/wireless/nl80211.c:8469:63: error: expected ',' or ';' before ')' token
struct nlattr ** attrbuf = genl_family_attrbuf(&nl80211_fam));
^
vim +8469 net/wireless/nl80211.c
8463 /*
8464 * 0 is a valid index, but not valid for args[0],
8465 * so we need to offset by 1.
8466 */
8467 phy_idx = cb->args[0] - 1;
8468 } else {
> 8469 struct nlattr ** attrbuf = genl_family_attrbuf(&nl80211_fam));
8470
8471 err = nlmsg_parse(cb->nlh, GENL_HDRLEN + nl80211_fam.hdrsize,
8472 attrbuf, nl80211_fam.maxattr, nl80211_policy);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29352 bytes --]
^ permalink raw reply
* [mac80211-next:genl 5/9] net/netlink/genetlink.c:430:1: warning: label 'errout' defined but not used
From: kbuild test robot @ 2016-10-24 17:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: kbuild-all, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl
head: fc4c3f9724b5c4b730490ce2637369fee6e8b87b
commit: dcc56960c6e6fa10b50d5433b10fc216a3f7c996 [5/9] genetlink: no longer support using static family IDs
config: i386-randconfig-x004-201643 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout dcc56960c6e6fa10b50d5433b10fc216a3f7c996
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
net/netlink/genetlink.c: In function '__genl_register_family':
>> net/netlink/genetlink.c:430:1: warning: label 'errout' defined but not used [-Wunused-label]
errout:
^~~~~~
vim +/errout +430 net/netlink/genetlink.c
2a94fe48 Johannes Berg 2013-11-19 414 if (err)
2a94fe48 Johannes Berg 2013-11-19 415 goto errout_locked;
2a94fe48 Johannes Berg 2013-11-19 416
482a8524 Thomas Graf 2005-11-10 417 list_add_tail(&family->family_list, genl_family_chain(family->id));
def31174 Pravin B Shelar 2013-04-23 418 genl_unlock_all();
482a8524 Thomas Graf 2005-11-10 419
2a94fe48 Johannes Berg 2013-11-19 420 /* send all events */
2a94fe48 Johannes Berg 2013-11-19 421 genl_ctrl_event(CTRL_CMD_NEWFAMILY, family, NULL, 0);
2a94fe48 Johannes Berg 2013-11-19 422 for (i = 0; i < family->n_mcgrps; i++)
2a94fe48 Johannes Berg 2013-11-19 423 genl_ctrl_event(CTRL_CMD_NEWMCAST_GRP, family,
2a94fe48 Johannes Berg 2013-11-19 424 &family->mcgrps[i], family->mcgrp_offset + i);
482a8524 Thomas Graf 2005-11-10 425
482a8524 Thomas Graf 2005-11-10 426 return 0;
482a8524 Thomas Graf 2005-11-10 427
482a8524 Thomas Graf 2005-11-10 428 errout_locked:
def31174 Pravin B Shelar 2013-04-23 429 genl_unlock_all();
482a8524 Thomas Graf 2005-11-10 @430 errout:
482a8524 Thomas Graf 2005-11-10 431 return err;
482a8524 Thomas Graf 2005-11-10 432 }
33c6b1f6 Pravin B Shelar 2013-08-23 433 EXPORT_SYMBOL(__genl_register_family);
482a8524 Thomas Graf 2005-11-10 434
482a8524 Thomas Graf 2005-11-10 435 /**
482a8524 Thomas Graf 2005-11-10 436 * genl_unregister_family - unregister generic netlink family
482a8524 Thomas Graf 2005-11-10 437 * @family: generic netlink family
482a8524 Thomas Graf 2005-11-10 438 *
:::::: The code at line 430 was first introduced by commit
:::::: 482a8524f85a7d8c40c6fb5d072e85bc2fef327f [NETLINK]: Generic netlink family
:::::: TO: Thomas Graf <tgraf@suug.ch>
:::::: CC: Thomas Graf <tgr@axs.localdomain>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35732 bytes --]
^ permalink raw reply
* [mac80211-next:genl 2/2] net/netlink/genetlink.c:693:9: error: 'genl_ctrl_ops' undeclared here (not in a function)
From: kbuild test robot @ 2016-10-24 7:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: kbuild-all, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 4121 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl
head: e406d0fb91172c4dc5364b4a2228679cb07e512c
commit: e406d0fb91172c4dc5364b4a2228679cb07e512c [2/2] genetlink: statically initialize families
config: i386-randconfig-x004-201643 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout e406d0fb91172c4dc5364b4a2228679cb07e512c
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
>> net/netlink/genetlink.c:693:9: error: 'genl_ctrl_ops' undeclared here (not in a function)
.ops = genl_ctrl_ops,
^~~~~~~~~~~~~
In file included from include/linux/thread_info.h:11:0,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from net/netlink/genetlink.c:9:
include/linux/bug.h:37:45: error: bit-field '<anonymous>' width not an integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^~~~~~~~~~~~~~~~~
include/linux/kernel.h:53:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~~~~~~~~~~~~~
>> net/netlink/genetlink.c:694:11: note: in expansion of macro 'ARRAY_SIZE'
.n_ops = ARRAY_SIZE(genl_ctrl_ops),
^~~~~~~~~~
>> net/netlink/genetlink.c:695:12: error: 'genl_ctrl_groups' undeclared here (not in a function)
.mcgrps = genl_ctrl_groups,
^~~~~~~~~~~~~~~~
In file included from include/linux/thread_info.h:11:0,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from net/netlink/genetlink.c:9:
include/linux/bug.h:37:45: error: bit-field '<anonymous>' width not an integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^~~~~~~~~~~~~~~~~
include/linux/kernel.h:53:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^~~~~~~~~~~~~~~
net/netlink/genetlink.c:696:14: note: in expansion of macro 'ARRAY_SIZE'
.n_mcgrps = ARRAY_SIZE(genl_ctrl_groups),
^~~~~~~~~~
vim +/genl_ctrl_ops +693 net/netlink/genetlink.c
687 /**************************************************************************
688 * Controller
689 **************************************************************************/
690
691 static struct genl_family genl_ctrl = {
692 .module = THIS_MODULE,
> 693 .ops = genl_ctrl_ops,
> 694 .n_ops = ARRAY_SIZE(genl_ctrl_ops),
> 695 .mcgrps = genl_ctrl_groups,
696 .n_mcgrps = ARRAY_SIZE(genl_ctrl_groups),
697 .id = GENL_ID_CTRL,
698 .name = "nlctrl",
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35732 bytes --]
^ permalink raw reply
* Re: Bayesian rate control
From: Johannes Berg @ 2016-10-24 5:28 UTC (permalink / raw)
To: Björn Smedman, linux-wireless, ath9k-devel
In-Reply-To: <CAGp19xcg1qCP3+JNbuiB7Hx=UjLN7KP55wVJT0sKV-iE12501A@mail.gmail.com>
> 1. Is there anybody else out there thinking along similar lines?
I'm not aware, but that may not mean much :)
> 2. What would be the best hardware/software stack to base this work
> on?
>
> I'm thinking the best driver for rate control experimentation would
> be ath9k, right? If so then a TP-Link TL-WA901ND router (apparently
> based on Qualcomm QCA956x SOC) with OpenWrt, and a TP-Link TL-WDN4800
> PCIe card (apparently based on Atheros AR9380 with PCI ID 168c:0030)
> for my desktop sounds like a good combo, no?
Seems reasonable, yes. You wouldn't have VHT, but HT has enough search
space to keep you busy ;-)
> But would I have to run a custom kernel on my desktop then (or can I
> somehow get by with an Ubuntu standard kernel)?
You could use a backported driver. https://backports.wiki.kernel.org/
johannes
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-23 19:42 UTC (permalink / raw)
To: Jonas Gorski; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAOiHx=kWh3P=Ye1Bnd35pRvwWyOdqEyYFVXvTTz60_Hj4TDFFg@mail.gmail.com>
Thanks, but its still not working. I dont get any error now when i do
modprobe and installed is the wle900
[root@alarm alarm]# rmmod ath10k_pci
[root@alarm alarm]# modprobe ath10k_pci irq_mode=1
but:
[root@alarm alarm]# dmesg | grep ath10k
[ 220.356314] ath10k_pci 0000:02:00.0: Refused to change power state,
currently in D3
[ 220.394265] ath10k_pci 0000:02:00.0: failed to wake up device : -110
[ 220.400770] ath10k_pci: probe of 0000:02:00.0 failed with error -110
[root@alarm alarm]# cat /proc/cmdline
console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait ath10k_pci.irq_mode=1
Thanks for your patience
Regards
Oli
Am 23.10.2016 um 21:33 schrieb Jonas Gorski:
> On 23 October 2016 at 17:53, Oliver Zemann <oliver.zemann@gmail.com> wrote:
>> Thanks for that info Jonas. I passed optargs=irq_mode=1 in /boot/uEnv.txt on
>> archlinux arm (kernel 4.4.23) and verified with
>>
>> [root@alarm ~]# cat /proc/cmdline
>> console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait irq_mode=1
>>
>> But it still does not work:
>>
>> [root@alarm ~]# rmmod ath10k_pci
>> [root@alarm ~]# modprobe ath10k_pci
>> [ 28.791404] ath10k_pci 0000:02:00.0: Refused to change power state,
>> currently in D3
>> [ 28.829352] ath10k_pci 0000:02:00.0: failed to wake up device : -110
>> [ 28.835861] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>>
>> Did i do something wrong? If somehow possible, i would prefer to not rebuild
>> the kernel and somehow configure the existing one without changes.
> For the kernel command line you need to prefix with the module name,
> i.e. "ath10k_pci.irq_mode=1". Alternative is while modprobing with
> "modprobe ath10_pci irq_mode=1". See
> <https://www.kernel.org/doc/Documentation/kernel-parameters.txt> for
> details.
>
> Regards
> Jonas
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Jonas Gorski @ 2016-10-23 19:33 UTC (permalink / raw)
To: Oliver Zemann; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <43544382-075a-6437-8f72-133a907d9def@gmail.com>
On 23 October 2016 at 17:53, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> Thanks for that info Jonas. I passed optargs=irq_mode=1 in /boot/uEnv.txt on
> archlinux arm (kernel 4.4.23) and verified with
>
> [root@alarm ~]# cat /proc/cmdline
> console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait irq_mode=1
>
> But it still does not work:
>
> [root@alarm ~]# rmmod ath10k_pci
> [root@alarm ~]# modprobe ath10k_pci
> [ 28.791404] ath10k_pci 0000:02:00.0: Refused to change power state,
> currently in D3
> [ 28.829352] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> [ 28.835861] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>
> Did i do something wrong? If somehow possible, i would prefer to not rebuild
> the kernel and somehow configure the existing one without changes.
For the kernel command line you need to prefix with the module name,
i.e. "ath10k_pci.irq_mode=1". Alternative is while modprobing with
"modprobe ath10_pci irq_mode=1". See
<https://www.kernel.org/doc/Documentation/kernel-parameters.txt> for
details.
Regards
Jonas
^ permalink raw reply
* Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-23 15:53 UTC (permalink / raw)
To: Jonas Gorski; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAOiHx==nbvwiiMZaqg5okdM6ab9ZLc+JOPdHdJJMUh9uhEt3PQ@mail.gmail.com>
Thanks for that info Jonas. I passed optargs=irq_mode=1 in
/boot/uEnv.txt on archlinux arm (kernel 4.4.23) and verified with
[root@alarm ~]# cat /proc/cmdline
console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait irq_mode=1
But it still does not work:
[root@alarm ~]# rmmod ath10k_pci
[root@alarm ~]# modprobe ath10k_pci
[ 28.791404] ath10k_pci 0000:02:00.0: Refused to change power state,
currently in D3
[ 28.829352] ath10k_pci 0000:02:00.0: failed to wake up device : -110
[ 28.835861] ath10k_pci: probe of 0000:02:00.0 failed with error -110
Did i do something wrong? If somehow possible, i would prefer to not
rebuild the kernel and somehow configure the existing one without changes.
Kind regards
Oli
Am 22.10.2016 um 13:55 schrieb Jonas Gorski:
> Hi,
>
> On 21 October 2016 at 18:25, Oliver Zemann <oliver.zemann@gmail.com> wrote:
>> The problem is gone with kernel 4.7.3 on armbian - both compex cards work
>> (wle600, wle900),
> Interesting to know this issue isn't present in 4.7 - I also
> encountered it in 4.4 with LEDE.
>
>> unfortunately that kernel does not support sfp (seems like
>> its kind of proprietary drivers from clearfog).
> They aren't really proprietary, they are proper patches that were
> submitted as RFC once, so it shouldn't be much effort to port them to
> e.g. 4.7. Anyways ...
>
>> So its a driver issue but i
>> have no clue who to contact or where to file a bug report. The only
>> available kernel which supports sfp (from solidrun, vendor of the clearfog
>> board) is 4.4.23
>>
>> I am wondering if i could simply checkout the 4.4.x sources, merge the
>> atheros drivers in it and try to rebuild the kernel?
> the issue seems to be that MSI interrupts do not work on 4.4 (at least
> with ath10k, didn't have any other drivers that support it to test).
> Your options are either to disable support for them in the kernel
> config, or pass irq_mode=1 to ath10k_pci on probe to force legacy
> interrupts; it should work then properly.
>
>
> Regards
> Jonas
^ permalink raw reply
* Bayesian rate control
From: Björn Smedman @ 2016-10-23 13:57 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
Hi all,
I've been thinking about rate control a bit lately. I've written up
some of my thoughts in a blog post
(http://www.openias.org/bayesian-wifi-rate-control), but very briefly
put I'd like to build a rate control algorithm based on Bayesian
statistical inference, possibly by modeling the rate control problem
as a "multi-armed bandit" problem and/or using Thompson sampling.
A couple of questions for the list:
1. Is there anybody else out there thinking along similar lines?
I'd very much like to find collaborators interested in working on
this. It could serve as a pretty nice masters thesis problem, for
example.
2. What would be the best hardware/software stack to base this work on?
I'm thinking the best driver for rate control experimentation would be
ath9k, right? If so then a TP-Link TL-WA901ND router (apparently based
on Qualcomm QCA956x SOC) with OpenWrt, and a TP-Link TL-WDN4800 PCIe
card (apparently based on Atheros AR9380 with PCI ID 168c:0030) for my
desktop sounds like a good combo, no? But would I have to run a custom
kernel on my desktop then (or can I somehow get by with an Ubuntu
standard kernel)?
Any other thoughts or pointers are also more than welcome.
Many thanks,
Bj=C3=B6rn Smedman
^ permalink raw reply
* Re: crypto: aesni - add ccm(aes) algorithm implementation
From: Ben Greear @ 2016-10-23 2:33 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Yauhen Kharuzhy
In-Reply-To: <4298972.T1UOBYP9Tx@debian64>
On 10/22/2016 12:15 PM, Christian Lamparter wrote:
> On Wednesday, October 19, 2016 9:39:49 AM CEST Ben Greear wrote:
>> On 10/19/2016 09:37 AM, greearb@candelatech.com wrote:
>>> From: Yauhen Kharuzhy <jekhor@gmail.com>
>>>
>>> Add ccm(aes) implementation from linux-wireless mailing list (see
>>> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
>>>
>>> This eliminates FPU context store/restore overhead existing in more
>>> general ccm_base(ctr(aes-aesni),aes-aesni) case in MAC calculation.
>>>
>>> Convert this patch to new AEAD API.
>>>
>>> Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> I've been using this patch or something similar for a while and it
>> significantly helps me with sw-crypt performance. One version or another
>> has been around the internet for some time, and I am not the originator
>> of this code, but would still be happy to see it upstream if someone
>> can review and bless it.
>
> No. I don't think this will ever fly by the crypto folks in this
> form due to the CRYPTO_ALGO_ASYNC fallback parts which are necessary
> to get it to work with mac80211.
>
> It would be a great if mac80211 would do to the encryption and
> decryption asynchronously. As this would work for other ciphers
> and also allows crypto offload to dedicated crypto hardware.
Does it actually hurt some existing code or functionality?
It definitely helps with wifi software crypt.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [NOT FOR MERGE] ath9k: work around key cache corruption
From: Johannes Berg @ 2016-10-22 20:34 UTC (permalink / raw)
To: Antonio Quartulli, ath9k-devel; +Cc: linux-wireless, sw, Antonio Quartulli
In-Reply-To: <20161022134222.GQ12558@prodigo.lan>
> "The patch itself has (at least) one big problem. It is using some
> mac80211
> internals in ath_key_config_iter to make sure that the uploaded keys
> were
> actually programmed in the hardware. Without this check the keys
> could end up
> in the lower slots and thus break all connections."
The KEY_FLAG_UPLOADED_TO_HARDWARE use? Might not be so nice, but it's
probably not really a problem. If you wanted to avoid it, you could
just use the hw_key_idx in some way, e.g. the highest-order bit
indicates that you've set this value, or you just make sure that 0 is
an invalid value and set it to real index + 1 or something, then you
can check that?
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox