* [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.
From: greearb @ 2016-08-19 1:26 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
In-Reply-To: <1471569995-10028-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
I was seeing some spin-lock hangs in this area of the code,
and it seems more proper to do the rcu-read-lock outside of
the spin lock. I am not sure how much this matters, however.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 916119c..d96c06e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4307,8 +4307,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)
int max;
int loop_max = 2000;
- spin_lock_bh(&ar->txqs_lock);
rcu_read_lock();
+ spin_lock_bh(&ar->txqs_lock);
last = list_last_entry(&ar->txqs, struct ath10k_txq, list);
while (!list_empty(&ar->txqs)) {
@@ -4342,8 +4342,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)
break;
}
- rcu_read_unlock();
spin_unlock_bh(&ar->txqs_lock);
+ rcu_read_unlock();
}
/************/
--
2.4.11
^ permalink raw reply related
* [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
From: greearb @ 2016-08-19 1:26 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
I was seeing kernel crashes due to accessing freed memory
while debugging a 9984 firmware that was crashing often.
This patch fixes the crashes. I am not certain if there
is a better way or not.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 5659ef1..916119c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4172,8 +4172,10 @@ static void ath10k_mac_txq_init(struct ieee80211_txq *txq)
static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
{
struct ath10k_txq *artxq = (void *)txq->drv_priv;
+ struct ath10k_txq *tmp, *walker;
struct ath10k_skb_cb *cb;
struct sk_buff *msdu;
+ struct ieee80211_txq *txq_tmp;
int msdu_id;
if (!txq)
@@ -4182,6 +4184,14 @@ static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
spin_lock_bh(&ar->txqs_lock);
if (!list_empty(&artxq->list))
list_del_init(&artxq->list);
+
+ /* Remove from ar->txqs in case it still exists there. */
+ list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
+ txq_tmp = container_of((void *)walker, struct ieee80211_txq,
+ drv_priv);
+ if (txq_tmp == txq)
+ list_del(&walker->list);
+ }
spin_unlock_bh(&ar->txqs_lock);
spin_lock_bh(&ar->htt.tx_lock);
--
2.4.11
^ permalink raw reply related
* [PATCH 3/3] ath10k: Improve logging message.
From: greearb @ 2016-08-19 1:26 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
In-Reply-To: <1471569995-10028-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Helps to know the sta pointer.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d96c06e..82bc0da 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6491,8 +6491,8 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
* Existing station deletion.
*/
ath10k_dbg(ar, ATH10K_DBG_MAC,
- "mac vdev %d peer delete %pM (sta gone)\n",
- arvif->vdev_id, sta->addr);
+ "mac vdev %d peer delete %pM (sta gone) sta: %p\n",
+ arvif->vdev_id, sta->addr, sta);
ret = ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
if (ret)
--
2.4.11
^ permalink raw reply related
* Re: [PATCH] mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()
From: Javier Martinez Canillas @ 2016-08-18 20:23 UTC (permalink / raw)
To: Arend van Spriel, linux-kernel
Cc: Amitkumar Karwar, Kalle Valo, netdev, linux-wireless,
Nishant Sarmukadam
In-Reply-To: <866da517-4b5c-492e-56d0-260afeb55ded@broadcom.com>
Hello Arend,
On 08/18/2016 03:49 PM, Arend van Spriel wrote:
>
>
> On 18-08-16 21:29, Javier Martinez Canillas wrote:
>> Hello Arend,
>>
>> Thanks a lot for your feedback.
>>
>> On 08/18/2016 03:14 PM, Arend van Spriel wrote:
>>> On 18-08-16 16:17, Javier Martinez Canillas 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.
>>>
>>> Hmm. The caller function, ie. mwifiex_sdio_probe(), does not seem to care.
>>>
>>
>> Hmm, I'm not so sure about that. It's checking the wifiex_sdio_probe_of()
>> return value.
>
> Ok. I looked at 4.7 sources on lxr [1].
>
Oh, right. That was fixed quite recently indeed.
>> If the IRQ request failing is not an error, then at the very least the call
>> to disable_irq() should be avoided if request_irq() fails, and the message
>> should be changed from dev_err() to dev_dgb() or dev_info().
>
> agree.
>
>>> The device may still function without this wake interrupt.
>>>
>>
>> That's correct, the binding says that the "interrupts" property in the child
>> node is optional since is just a wakeup IRQ. Now the question is if should
>> be an error if the IRQ is defined but fails to be requested.
>
> Clearly it indicates an error in the DT specification so behavior is not
> as expected. Personally I would indeed consider it an error, but I was
> just indicating that it might have done like this intentionally.
>
Yes, might had been done intentionally indeed but I don't think that is
the case since the driver lacked error checking and propagation in many
places. But if someone thinks that's better to not honor the DT and at
least have the driver working without the wake up capability, then I'm
happy to respin the patch and change the print log level to info/debug.
> Regards,
> Arend
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH] mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()
From: Arend van Spriel @ 2016-08-18 19:14 UTC (permalink / raw)
To: Javier Martinez Canillas, linux-kernel
Cc: Amitkumar Karwar, Kalle Valo, netdev, linux-wireless,
Nishant Sarmukadam
In-Reply-To: <1471529868-13669-1-git-send-email-javier@osg.samsung.com>
On 18-08-16 16:17, Javier Martinez Canillas 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.
Hmm. The caller function, ie. mwifiex_sdio_probe(), does not seem to care.
The device may still function without this wake interrupt.
Regards,
Arend
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> drivers/net/wireless/marvell/mwifiex/sdio.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index d3e1561ca075..00727936ad6e 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -125,6 +125,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
> dev_err(dev,
> "Failed to request irq_wifi %d (%d)\n",
> cfg->irq_wifi, ret);
> + return ret;
> }
> disable_irq(cfg->irq_wifi);
> }
>
^ permalink raw reply
* Re: [RFC (v7)] add basic register-field manipulation macros
From: Linus Torvalds @ 2016-08-18 17:28 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Morton, Greg Kroah-Hartman, David Miller, Kalle Valo,
Linux Wireless List, Linux Kernel Mailing List, dinan.gunawardena
In-Reply-To: <1471540317-14823-1-git-send-email-jakub.kicinski@netronome.com>
On Thu, Aug 18, 2016 at 10:11 AM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> Hi!
>
> This is what I came up with. Changes:
I can live with this, certainly. I'm not really sure how many drivers
(or perhaps core code, for that matter) will actually start using it,
but it at least _looks_ like a usable interface that seems to be quite
resistant to people doing stupid things with it that would result in
surprising results (either performance or semantics).
So I'm ok with something like this coming through (for example) the
wireless tree if the drivers there are the first ones to start using
this.
Let's see if anybody else objects.
Linus
^ permalink raw reply
* Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.
From: Manoharan, Rajkumar @ 2016-08-19 3:01 UTC (permalink / raw)
To: greearb@candelatech.com, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1471569995-10028-2-git-send-email-greearb@candelatech.com>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless=
/ath/ath10k/mac.c=0A=
> index 916119c..d96c06e 100644=0A=
> --- a/drivers/net/wireless/ath/ath10k/mac.c=0A=
> +++ b/drivers/net/wireless/ath/ath10k/mac.c=0A=
> @@ -4307,8 +4307,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)=
=0A=
> int max;=0A=
> int loop_max =3D 2000;=0A=
> =0A=
> - spin_lock_bh(&ar->txqs_lock);=0A=
> rcu_read_lock();=0A=
> + spin_lock_bh(&ar->txqs_lock);=0A=
>=0A=
Ben,=0A=
=0A=
It is quite possible that push_pending can be preempted after acquiring rcu=
_lock which=0A=
may lead to deadlock. no? I assume to prevent that spin_lock is taken first=
. =0A=
=0A=
Could you please explain how this reordering is fixing dead lock?=0A=
=0A=
-Rajkumar=
^ permalink raw reply
* Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.
From: Ben Greear @ 2016-08-19 3:28 UTC (permalink / raw)
To: Manoharan, Rajkumar, ath10k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1471575674214.65791@qti.qualcomm.com>
On 08/18/2016 08:01 PM, Manoharan, Rajkumar wrote:
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index 916119c..d96c06e 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -4307,8 +4307,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)
>> int max;
>> int loop_max = 2000;
>>
>> - spin_lock_bh(&ar->txqs_lock);
>> rcu_read_lock();
>> + spin_lock_bh(&ar->txqs_lock);
>>
> Ben,
>
> It is quite possible that push_pending can be preempted after acquiring rcu_lock which
> may lead to deadlock. no? I assume to prevent that spin_lock is taken first.
>
> Could you please explain how this reordering is fixing dead lock?
It did not obviously fix the spin lock issue, but the issue went away. Maybe it
was because I fixed the stale memory access issues at around the same time.
But, I don't think you can deadlock by taking rcu lock first and then the spinlock.
I checked all places where the spinlock is held, and I do not see any way for any of
them to block forever (In my kernel, I have a 2000 time limit on spinning in the push pending
method, which can help make sure we don't spin forever).
http://dmz2.candelatech.com/?p=linux-4.7.dev.y/.git;a=commitdiff;h=5d192657269d8e20fce733f894bb1b68df71db00
I was also worried that some calls from mac80211 might be holding rcu_read_lock while calling into
ath10k code that would grab the spinlock. If that is the case (and I didn't verify it was), then
you could have a lock inversion by taking spinlock before rcu read lock in the push-pending method.
Anyway, someone that understands locking subtleties better might have more clue about this code
than I do.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] wlcore: mesh: add zone time sync support
From: Pedersen, Thomas @ 2016-08-18 16:42 UTC (permalink / raw)
To: Guy Mishol; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20160808085706.22668-1-guym@ti.com>
T24gTW9uLCAyMDE2LTA4LTA4IGF0IDExOjU3ICswMzAwLCBHdXkgTWlzaG9sIHdyb3RlOg0KPiBB
ZGQgem9uZSB0aW1lIHN5bmMgc3VwcG9ydCBmb3IgbWVzaCByb2xlLg0KPiBUaGlzIGFsbG93cyB0
byBjb25maWd1cmUgdGhlIG1lc2ggcGVlcg0KPiBtYXN0ZXIgb2YgZWFjaCB6b25lIGZvciB0aW1l
IHN5bmNocm9uaXphdGlvbi4NCg0KV2hhdCBpcyB0aGlzPyBtYWM4MDIxMSBhbHJlYWR5IHRyaWVz
IHRvIG1haW50YWluIFRTRiBzeW5jIHdpdGggbWVzaA0KcGVlcnMgaWYgZ2V0L3NldCBUU0Ygb3Bz
IGFyZSBzdXBwb3J0ZWQgYnkgdGhlIGRyaXZlci4NCg0KPiBTaWduZWQtb2ZmLWJ5OiBHdXkgTWlz
aG9sIDxndXltQHRpLmNvbT4NCj4gLS0tDQo+ICBkcml2ZXJzL25ldC93aXJlbGVzcy90aS93bDE4
eHgvYWN4LmMgICAgIHwgMjkgKysrKysrKysrKysrKysrKw0KPiAgZHJpdmVycy9uZXQvd2lyZWxl
c3MvdGkvd2wxOHh4L2FjeC5oICAgICB8IDEzICsrKysrKysNCj4gIGRyaXZlcnMvbmV0L3dpcmVs
ZXNzL3RpL3dsMTh4eC9kZWJ1Z2ZzLmMgfCA1OSArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKw0KPiAgZHJpdmVycy9uZXQvd2lyZWxlc3MvdGkvd2wxOHh4L2V2ZW50LmMgICB8ICAxICsN
Cj4gIGRyaXZlcnMvbmV0L3dpcmVsZXNzL3RpL3dsY29yZS93bGNvcmUuaCAgfCAgMyArKw0KPiAg
NSBmaWxlcyBjaGFuZ2VkLCAxMDUgaW5zZXJ0aW9ucygrKQ0KPiANCj4gZGlmZiAtLWdpdCBhL2Ry
aXZlcnMvbmV0L3dpcmVsZXNzL3RpL3dsMTh4eC9hY3guYyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNz
L3RpL3dsMTh4eC9hY3guYw0KPiBpbmRleCA0YmUwNDA5Li5iNTUyNWEzIDEwMDY0NA0KPiAtLS0g
YS9kcml2ZXJzL25ldC93aXJlbGVzcy90aS93bDE4eHgvYWN4LmMNCj4gKysrIGIvZHJpdmVycy9u
ZXQvd2lyZWxlc3MvdGkvd2wxOHh4L2FjeC5jDQo+IEBAIC0zMDksMyArMzA5LDMyIEBAIG91dDoN
Cj4gIAlrZnJlZShhY3gpOw0KPiAgCXJldHVybiByZXQ7DQo+ICB9DQo+ICsNCj4gK2ludCB3bDE4
eHhfYWN4X3RpbWVfc3luY19jZmcoc3RydWN0IHdsMTI3MSAqd2wpDQo+ICt7DQo+ICsJc3RydWN0
IGFjeF90aW1lX3N5bmNfY2ZnICphY3g7DQo+ICsJaW50IHJldDsNCj4gKw0KPiArCXdsMTI3MV9k
ZWJ1ZyhERUJVR19BQ1gsICJhY3ggdGltZSBzeW5jIGNmZzogbW9kZSAlZCwgYWRkcjogJXBNIiwN
Cj4gKwkJICAgICB3bC0+Y29uZi5zZy5wYXJhbXNbV0wxOFhYX0NPTkZfU0dfVElNRV9TWU5DXSwN
Cj4gKwkJICAgICB3bC0+em9uZV9tYXN0ZXJfbWFjX2FkZHIpOw0KPiArDQo+ICsJYWN4ID0ga3ph
bGxvYyhzaXplb2YoKmFjeCksIEdGUF9LRVJORUwpOw0KPiArCWlmICghYWN4KSB7DQo+ICsJCXJl
dCA9IC1FTk9NRU07DQo+ICsJCWdvdG8gb3V0Ow0KPiArCX0NCj4gKw0KPiArCWFjeC0+c3luY19t
b2RlID0gd2wtPmNvbmYuc2cucGFyYW1zW1dMMThYWF9DT05GX1NHX1RJTUVfU1lOQ107DQo+ICsJ
bWVtY3B5KGFjeC0+em9uZV9tYWNfYWRkciwgd2wtPnpvbmVfbWFzdGVyX21hY19hZGRyLCBFVEhf
QUxFTik7DQo+ICsNCj4gKwlyZXQgPSB3bDEyNzFfY21kX2NvbmZpZ3VyZSh3bCwgQUNYX1RJTUVf
U1lOQ19DRkcsDQo+ICsJCQkJICAgYWN4LCBzaXplb2YoKmFjeCkpOw0KPiArCWlmIChyZXQgPCAw
KSB7DQo+ICsJCXdsMTI3MV93YXJuaW5nKCJhY3ggdGltZSBzeW5jIGNmZyBmYWlsZWQ6ICVkIiwg
cmV0KTsNCj4gKwkJZ290byBvdXQ7DQo+ICsJfQ0KPiArb3V0Og0KPiArCWtmcmVlKGFjeCk7DQo+
ICsJcmV0dXJuIHJldDsNCj4gK30NCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3dpcmVsZXNz
L3RpL3dsMTh4eC9hY3guaCBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3RpL3dsMTh4eC9hY3guaA0K
PiBpbmRleCAzNDJhMjk5Li4yZWRiYmJmIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL25ldC93aXJl
bGVzcy90aS93bDE4eHgvYWN4LmgNCj4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvdGkvd2wx
OHh4L2FjeC5oDQo+IEBAIC0zNyw2ICszNyw3IEBAIGVudW0gew0KPiAgCUFDWF9SWF9CQV9GSUxU
RVIJCSA9IDB4MDA1OCwNCj4gIAlBQ1hfQVBfU0xFRVBfQ0ZHICAgICAgICAgICAgICAgICA9IDB4
MDA1OSwNCj4gIAlBQ1hfRFlOQU1JQ19UUkFDRVNfQ0ZHCQkgPSAweDAwNUEsDQo+ICsJQUNYX1RJ
TUVfU1lOQ19DRkcJCSA9IDB4MDA1QiwNCj4gIH07DQo+ICANCj4gIC8qIG51bWJlcnMgb2YgYml0
cyB0aGUgbGVuZ3RoIGZpZWxkIHRha2VzIChhZGQgMSBmb3IgdGhlIGFjdHVhbCBudW1iZXIpICov
DQo+IEBAIC0zODgsNiArMzg5LDE3IEBAIHN0cnVjdCBhY3hfZHluYW1pY19md190cmFjZXNfY2Zn
IHsNCj4gIAlfX2xlMzIgZHluYW1pY19md190cmFjZXM7DQo+ICB9IF9fcGFja2VkOw0KPiAgDQo+
ICsvKg0KPiArICogQUNYX1RJTUVfU1lOQ19DRkcNCj4gKyAqIGNvbmZpZ3VyZSB0aGUgdGltZSBz
eW5jIHBhcmFtZXRlcnMNCj4gKyAqLw0KPiArc3RydWN0IGFjeF90aW1lX3N5bmNfY2ZnIHsNCj4g
KwlzdHJ1Y3QgYWN4X2hlYWRlciBoZWFkZXI7DQo+ICsJdTggc3luY19tb2RlOw0KPiArCXU4IHpv
bmVfbWFjX2FkZHJbRVRIX0FMRU5dOw0KPiArCXU4IHBhZGRpbmdbMV07DQo+ICt9IF9fcGFja2Vk
Ow0KPiArDQo+ICBpbnQgd2wxOHh4X2FjeF9ob3N0X2lmX2NmZ19iaXRtYXAoc3RydWN0IHdsMTI3
MSAqd2wsIHUzMiBob3N0X2NmZ19iaXRtYXAsDQo+ICAJCQkJICB1MzIgc2Rpb19ibGtfc2l6ZSwg
dTMyIGV4dHJhX21lbV9ibGtzLA0KPiAgCQkJCSAgdTMyIGxlbl9maWVsZF9zaXplKTsNCj4gQEAg
LTQwMiw1ICs0MTQsNiBAQCBpbnQgd2wxOHh4X2FjeF9pbnRlcnJ1cHRfbm90aWZ5X2NvbmZpZyhz
dHJ1Y3Qgd2wxMjcxICp3bCwgYm9vbCBhY3Rpb24pOw0KPiAgaW50IHdsMTh4eF9hY3hfcnhfYmFf
ZmlsdGVyKHN0cnVjdCB3bDEyNzEgKndsLCBib29sIGFjdGlvbik7DQo+ICBpbnQgd2wxOHh4X2Fj
eF9hcF9zbGVlcChzdHJ1Y3Qgd2wxMjcxICp3bCk7DQo+ICBpbnQgd2wxOHh4X2FjeF9keW5hbWlj
X2Z3X3RyYWNlcyhzdHJ1Y3Qgd2wxMjcxICp3bCk7DQo+ICtpbnQgd2wxOHh4X2FjeF90aW1lX3N5
bmNfY2ZnKHN0cnVjdCB3bDEyNzEgKndsKTsNCj4gIA0KPiAgI2VuZGlmIC8qIF9fV0wxOFhYX0FD
WF9IX18gKi8NCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3RpL3dsMTh4eC9k
ZWJ1Z2ZzLmMgYi9kcml2ZXJzL25ldC93aXJlbGVzcy90aS93bDE4eHgvZGVidWdmcy5jDQo+IGlu
ZGV4IDg2Y2NmODQuLjllMjg3NDggMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvbmV0L3dpcmVsZXNz
L3RpL3dsMTh4eC9kZWJ1Z2ZzLmMNCj4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvdGkvd2wx
OHh4L2RlYnVnZnMuYw0KPiBAQCAtNDA4LDYgKzQwOCw2NCBAQCBzdGF0aWMgY29uc3Qgc3RydWN0
IGZpbGVfb3BlcmF0aW9ucyByYWRhcl9kZWJ1Z19tb2RlX29wcyA9IHsNCj4gIH07DQo+ICAjZW5k
aWYgLyogQ0ZHODAyMTFfQ0VSVElGSUNBVElPTl9PTlVTICovDQo+ICANCj4gK3N0YXRpYyBzc2l6
ZV90IHRpbWVfc3luY196b25lX2FkZHJfd3JpdGUoc3RydWN0IGZpbGUgKmZpbGUsDQo+ICsJCQkJ
CSBjb25zdCBjaGFyIF9fdXNlciAqdXNlcl9idWYsDQo+ICsJCQkJCSBzaXplX3QgY291bnQsIGxv
ZmZfdCAqcHBvcykgew0KPiArCXN0cnVjdCB3bDEyNzEgKndsID0gZmlsZS0+cHJpdmF0ZV9kYXRh
Ow0KPiArCWNoYXIgYnVmWyhFVEhfQUxFTiAqIDIpXTsNCj4gKwlpbnQgcmV0Ow0KPiArDQo+ICsJ
aWYgKGNvdW50IDwgKEVUSF9BTEVOICogMiArIDEpKSB7DQo+ICsJCXdsMTI3MV93YXJuaW5nKCJJ
bGxlZ2FsIE1BQyBhZGRyZXNzOiB3cm9uZyBzaXplIik7DQo+ICsJCXJldHVybiAtRUlOVkFMOw0K
PiArCX0NCj4gKw0KPiArCXJldCA9IGNvcHlfZnJvbV91c2VyKGJ1ZiwgdXNlcl9idWYsIChFVEhf
QUxFTiAqIDIpKTsNCj4gKwlpZiAocmV0IDwgMCkNCj4gKwkJcmV0dXJuIHJldDsNCj4gKw0KPiAr
CXJldCA9IGhleDJiaW4od2wtPnpvbmVfbWFzdGVyX21hY19hZGRyLCBidWYsIEVUSF9BTEVOKTsN
Cj4gKwlpZiAocmV0IDwgMCkgew0KPiArCQl3bDEyNzFfd2FybmluZygiSWxsZWdhbCBNQUMgYWRk
cmVzczogaW52YWxpZCBjaGFyYWN0ZXJzIik7DQo+ICsJCXJldHVybiByZXQ7DQo+ICsJfQ0KPiAr
DQo+ICsJbXV0ZXhfbG9jaygmd2wtPm11dGV4KTsNCj4gKw0KPiArCWlmICh1bmxpa2VseSh3bC0+
c3RhdGUgIT0gV0xDT1JFX1NUQVRFX09OKSkNCj4gKwkJZ290byBvdXQ7DQo+ICsNCj4gKwlyZXQg
PSB3bDEyNzFfcHNfZWxwX3dha2V1cCh3bCk7DQo+ICsJaWYgKHJldCA8IDApDQo+ICsJCWdvdG8g
b3V0Ow0KPiArDQo+ICsJcmV0ID0gd2wxOHh4X2FjeF90aW1lX3N5bmNfY2ZnKHdsKTsNCj4gKwlp
ZiAocmV0IDwgMCkNCj4gKwkJY291bnQgPSByZXQ7DQo+ICsNCj4gKwl3bDEyNzFfcHNfZWxwX3Ns
ZWVwKHdsKTsNCj4gK291dDoNCj4gKwltdXRleF91bmxvY2soJndsLT5tdXRleCk7DQo+ICsJcmV0
dXJuIGNvdW50Ow0KPiArfQ0KPiArDQo+ICtzdGF0aWMgc3NpemVfdCB0aW1lX3N5bmNfem9uZV9h
ZGRyX3JlYWQoc3RydWN0IGZpbGUgKmZpbGUsDQo+ICsJCQkJCWNoYXIgX191c2VyICp1c2VyYnVm
LA0KPiArCQkJCQlzaXplX3QgY291bnQsIGxvZmZfdCAqcHBvcykNCj4gK3sNCj4gKwlzdHJ1Y3Qg
d2wxMjcxICp3bCA9IGZpbGUtPnByaXZhdGVfZGF0YTsNCj4gKw0KPiArCXJldHVybiB3bDEyNzFf
Zm9ybWF0X2J1ZmZlcih1c2VyYnVmLCBjb3VudCwgcHBvcywNCj4gKwkJCQkgICAgIiVwTVxuIiwg
d2wtPnpvbmVfbWFzdGVyX21hY19hZGRyKTsNCj4gK30NCj4gKw0KPiArc3RhdGljIGNvbnN0IHN0
cnVjdCBmaWxlX29wZXJhdGlvbnMgdGltZV9zeW5jX3pvbmVfYWRkcl9vcHMgPSB7DQo+ICsJLndy
aXRlICA9IHRpbWVfc3luY196b25lX2FkZHJfd3JpdGUsDQo+ICsJLnJlYWQgPSB0aW1lX3N5bmNf
em9uZV9hZGRyX3JlYWQsDQo+ICsJLm9wZW4gICA9IHNpbXBsZV9vcGVuLA0KPiArCS5sbHNlZWsg
PSBkZWZhdWx0X2xsc2VlaywNCj4gK307DQo+ICsNCj4gIGludCB3bDE4eHhfZGVidWdmc19hZGRf
ZmlsZXMoc3RydWN0IHdsMTI3MSAqd2wsDQo+ICAJCQkgICAgIHN0cnVjdCBkZW50cnkgKnJvb3Rk
aXIpDQo+ICB7DQo+IEBAIC01NzYsNiArNjM0LDcgQEAgaW50IHdsMTh4eF9kZWJ1Z2ZzX2FkZF9m
aWxlcyhzdHJ1Y3Qgd2wxMjcxICp3bCwNCj4gICNpZmRlZiBDT05GSUdfQ0ZHODAyMTFfQ0VSVElG
SUNBVElPTl9PTlVTDQo+ICAJREVCVUdGU19BREQocmFkYXJfZGVidWdfbW9kZSwgbW9kZGlyKTsN
Cj4gICNlbmRpZg0KPiArCURFQlVHRlNfQUREKHRpbWVfc3luY196b25lX2FkZHIsIG1vZGRpcik7
DQo+ICAJREVCVUdGU19BREQoZHluYW1pY19md190cmFjZXMsIG1vZGRpcik7DQo+ICANCj4gIAly
ZXR1cm4gMDsNCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3RpL3dsMTh4eC9l
dmVudC5jIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvdGkvd2wxOHh4L2V2ZW50LmMNCj4gaW5kZXgg
MmM1ZGY0My4uYjM2Y2UxOCAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvdGkv
d2wxOHh4L2V2ZW50LmMNCj4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvdGkvd2wxOHh4L2V2
ZW50LmMNCj4gQEAgLTIyLDYgKzIyLDcgQEANCj4gICNpbmNsdWRlIDxuZXQvZ2VuZXRsaW5rLmg+
DQo+ICAjaW5jbHVkZSAiZXZlbnQuaCINCj4gICNpbmNsdWRlICJzY2FuLmgiDQo+ICsjaW5jbHVk
ZSAiY29uZi5oIg0KPiAgI2luY2x1ZGUgIi4uL3dsY29yZS9jbWQuaCINCj4gICNpbmNsdWRlICIu
Li93bGNvcmUvZGVidWcuaCINCj4gICNpbmNsdWRlICIuLi93bGNvcmUvdmVuZG9yX2NtZC5oIg0K
PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvdGkvd2xjb3JlL3dsY29yZS5oIGIv
ZHJpdmVycy9uZXQvd2lyZWxlc3MvdGkvd2xjb3JlL3dsY29yZS5oDQo+IGluZGV4IDhmMjhhYTAu
LjE4Mjc1NDYgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3RpL3dsY29yZS93
bGNvcmUuaA0KPiArKysgYi9kcml2ZXJzL25ldC93aXJlbGVzcy90aS93bGNvcmUvd2xjb3JlLmgN
Cj4gQEAgLTUwMSw2ICs1MDEsOSBAQCBzdHJ1Y3Qgd2wxMjcxIHsNCj4gIA0KPiAgCS8qIGR5bmFt
aWMgZncgdHJhY2VzICovDQo+ICAJdTMyIGR5bmFtaWNfZndfdHJhY2VzOw0KPiArDQo+ICsJLyog
dGltZSBzeW5jIHpvbmUgbWFzdGVyICovDQo+ICsJdTggem9uZV9tYXN0ZXJfbWFjX2FkZHJbRVRI
X0FMRU5dOw0KPiAgfTsNCj4gIA0KPiAgaW50IHdsY29yZV9wcm9iZShzdHJ1Y3Qgd2wxMjcxICp3
bCwgc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldik7DQoNCg0K
^ permalink raw reply
* [RFC (v7)] add basic register-field manipulation macros
From: Jakub Kicinski @ 2016-08-18 17:11 UTC (permalink / raw)
To: torvalds
Cc: akpm, gregkh, davem, kvalo, linux-wireless, linux-kernel,
dinan.gunawardena, Jakub Kicinski
In-Reply-To: <CA+55aFz_MUXQjWjbQzb7f=+cQLtxQsba1azmbEVZOgy5Y7wfdQ@mail.gmail.com>
Hi!
This is what I came up with. Changes:
- drop the explicit type marking (u32/u64) - depend on the type
of the mask instead;
- only allow compilation time constant masks;
- barf at "type of register too small to ever match mask" on get;
- rename PUT -> PREP.
I did not put the new marcos in bitops.h (where GENMASK lives)
because of the dependency on bug.h. If I did there would be
a circular dependency like this:
bitops.h -> linux/bug.h -> asm-generic/bug.h -> kernel.h -> bitops.h
Which makes things really ugly. I tried to remove the kernel.h
include from bug.h by separating panic-related definitions into
a new header. There were still cycles coming from the notifier.h
which I had to include for panic notifier...
Reviewed-by: Dinan Gunawardena <dinan.gunawardena@netronome.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
include/linux/bitfield.h | 93 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/bug.h | 3 ++
2 files changed, 96 insertions(+)
create mode 100644 include/linux/bitfield.h
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
new file mode 100644
index 000000000000..32ca8863e66d
--- /dev/null
+++ b/include/linux/bitfield.h
@@ -0,0 +1,93 @@
+/*
+ * Copyright (C) 2014 Felix Fietkau <nbd@nbd.name>
+ * Copyright (C) 2004 - 2009 Ivo van Doorn <IvDoorn@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _LINUX_BITFIELD_H
+#define _LINUX_BITFIELD_H
+
+#include <linux/bug.h>
+
+/*
+ * Bitfield access macros
+ *
+ * FIELD_{GET,PREP} macros take as first parameter shifted mask
+ * from which they extract the base mask and shift amount.
+ * Mask must be a compilation time constant.
+ *
+ * Example:
+ *
+ * #define REG_FIELD_A GENMASK(6, 0)
+ * #define REG_FIELD_B BIT(7)
+ * #define REG_FIELD_C GENMASK(15, 8)
+ * #define REG_FIELD_D GENMASK(31, 16)
+ *
+ * Get:
+ * a = FIELD_GET(REG_FIELD_A, reg);
+ * b = FIELD_GET(REG_FIELD_B, reg);
+ *
+ * Set:
+ * reg = FIELD_PREP(REG_FIELD_A, 1) |
+ * FIELD_PREP(REG_FIELD_B, 0) |
+ * FIELD_PREP(REG_FIELD_C, c) |
+ * FIELD_PREP(REG_FIELD_D, 0x40);
+ *
+ * Modify:
+ * reg &= ~REG_FIELD_C;
+ * reg |= FIELD_PREP(REG_FIELD_C, c);
+ */
+
+#define _bf_shf(x) (__builtin_ffsll(x) - 1)
+
+#define _BF_FIELD_CHECK(_mask, _reg, _val, _pfx) \
+ ({ \
+ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \
+ _pfx "mask is not constant"); \
+ BUILD_BUG_ON_MSG(!(_mask), _pfx "mask is zero"); \
+ BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \
+ ~((_mask) >> _bf_shf(_mask)) & (_val) : 0, \
+ _pfx "value too large for the field"); \
+ BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull, \
+ _pfx "type of reg too small for mask"); \
+ __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) + \
+ (1ULL << _bf_shf(_mask))); \
+ })
+
+/**
+ * FIELD_PREP() - prepare a bitfield element
+ * @_mask: shifted mask defining the field's length and position
+ * @_val: value to put in the field
+ *
+ * FIELD_PREP() masks and shifts up the value. The result should
+ * be combined with other fields of the bitfield using logical OR.
+ */
+#define FIELD_PREP(_mask, _val) \
+ ({ \
+ _BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \
+ ((typeof(_mask))(_val) << _bf_shf(_mask)) & (_mask); \
+ })
+
+/**
+ * FIELD_GET() - extract a bitfield element
+ * @_mask: shifted mask defining the field's length and position
+ * @_reg: 32bit value of entire bitfield
+ *
+ * FIELD_GET() extracts the field specified by @_mask from the
+ * bitfield passed in as @_reg by masking and shifting it down.
+ */
+#define FIELD_GET(_mask, _reg) \
+ ({ \
+ _BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \
+ (typeof(_mask))(((_reg) & (_mask)) >> _bf_shf(_mask)); \
+ })
+
+#endif
diff --git a/include/linux/bug.h b/include/linux/bug.h
index e51b0709e78d..292d6a10b0c2 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -13,6 +13,7 @@ enum bug_trap_type {
struct pt_regs;
#ifdef __CHECKER__
+#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
#define BUILD_BUG_ON_ZERO(e) (0)
#define BUILD_BUG_ON_NULL(e) ((void*)0)
@@ -24,6 +25,8 @@ struct pt_regs;
#else /* __CHECKER__ */
/* Force a compilation error if a constant expression is not a power of 2 */
+#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) \
+ BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
#define BUILD_BUG_ON_NOT_POWER_OF_2(n) \
BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/3] ath10k: Improve logging message.
From: Mohammed Shafi Shajakhan @ 2016-08-19 6:35 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
In-Reply-To: <1471569995-10028-3-git-send-email-greearb@candelatech.com>
Hi Ben,
On Thu, Aug 18, 2016 at 06:26:35PM -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Helps to know the sta pointer.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index d96c06e..82bc0da 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -6491,8 +6491,8 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
> * Existing station deletion.
> */
> ath10k_dbg(ar, ATH10K_DBG_MAC,
> - "mac vdev %d peer delete %pM (sta gone)\n",
> - arvif->vdev_id, sta->addr);
> + "mac vdev %d peer delete %pM (sta gone) sta: %p\n",
> + arvif->vdev_id, sta->addr, sta);
good to rebase over Maharaja's change (%p to %pK)
https://patchwork.kernel.org/patch/9263691/
>
> ret = ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
> if (ret)
> --
> 2.4.11
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH net-next] net: bgmac: support Ethernet core on BCM53573 SoCs
From: David Miller @ 2016-08-19 6:36 UTC (permalink / raw)
To: zajec5
Cc: netdev, rafal, jon.mason, arnd, f.fainelli, tremyfr, nbd,
linux-kernel, linux-wireless
In-Reply-To: <1471467662-18319-1-git-send-email-zajec5@gmail.com>
From: Rafał Miłecki <zajec5@gmail.com>
Date: Wed, 17 Aug 2016 23:00:30 +0200
> From: Rafał Miłecki <rafal@milecki.pl>
>
> BCM53573 is a new series of Broadcom's SoCs. It's based on ARM and can
> be found in two packages (versions): BCM53573 and BCM47189. It shares
> some code with the Northstar family, but also requires some new quirks.
>
> First of all there can be up to 2 Ethernet cores on this SoC. If that is
> the case, they are connected to two different switch ports allowing some
> more complex/optimized setups. It seems the second unit doesn't come
> fully configured and requires some IRQ quirk.
>
> Other than that only the first core is connected to the PHY. For the
> second one we have to register fixed PHY (similarly to the Northstar),
> otherwise generic PHY driver would get some invalid info.
>
> This has been successfully tested on Tenda AC9 (BCM47189B0).
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
From: Michal Kazior @ 2016-08-19 6:59 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k@lists.infradead.org, linux-wireless
In-Reply-To: <1471569995-10028-1-git-send-email-greearb@candelatech.com>
On 19 August 2016 at 03:26, <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> I was seeing kernel crashes due to accessing freed memory
> while debugging a 9984 firmware that was crashing often.
>
> This patch fixes the crashes. I am not certain if there
> is a better way or not.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless=
/ath/ath10k/mac.c
> index 5659ef1..916119c 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -4172,8 +4172,10 @@ static void ath10k_mac_txq_init(struct ieee80211_t=
xq *txq)
> static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq=
*txq)
> {
> struct ath10k_txq *artxq =3D (void *)txq->drv_priv;
> + struct ath10k_txq *tmp, *walker;
> struct ath10k_skb_cb *cb;
> struct sk_buff *msdu;
> + struct ieee80211_txq *txq_tmp;
> int msdu_id;
>
> if (!txq)
> @@ -4182,6 +4184,14 @@ static void ath10k_mac_txq_unref(struct ath10k *ar=
, struct ieee80211_txq *txq)
> spin_lock_bh(&ar->txqs_lock);
> if (!list_empty(&artxq->list))
> list_del_init(&artxq->list);
> +
> + /* Remove from ar->txqs in case it still exists there. */
> + list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
> + txq_tmp =3D container_of((void *)walker, struct ieee80211=
_txq,
> + drv_priv);
> + if (txq_tmp =3D=3D txq)
> + list_del(&walker->list);
> + }
How could this even happen? All artxq->list accesses (add/del) are
protected by txqs_lock so this shouldn't happen, no?
Do you perhaps have the logic around txqs reworked in your tree?
Micha=C5=82
^ permalink raw reply
* Re: [RFC (v7)] add basic register-field manipulation macros
From: Kalle Valo @ 2016-08-19 9:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jakub Kicinski, Andrew Morton, Greg Kroah-Hartman, David Miller,
Linux Wireless List, Linux Kernel Mailing List, dinan.gunawardena
In-Reply-To: <CA+55aFytOu02ZvRf+gxCCeP98qbv8wXzOds8Ocu-Ps4mKbGCkQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Aug 18, 2016 at 10:11 AM, Jakub Kicinski
> <jakub.kicinski@netronome.com> wrote:
>> Hi!
>>
>> This is what I came up with. Changes:
>
> I can live with this, certainly. I'm not really sure how many drivers
> (or perhaps core code, for that matter) will actually start using it,
> but it at least _looks_ like a usable interface that seems to be quite
> resistant to people doing stupid things with it that would result in
> surprising results (either performance or semantics).
I'm guessing that at least in ath9k and ath10k there would be use of
these macros.
> So I'm ok with something like this coming through (for example) the
> wireless tree if the drivers there are the first ones to start using
> this.
>
> Let's see if anybody else objects.
Great, thanks for the help. Let's wait for other comments and Jakub can
then resend this without RFC. I can then take it through my tree.
--
Kalle Valo
^ permalink raw reply
* Re: ath9k: Fix beacon configuration assertion failure
From: Kalle Valo @ 2016-08-19 9:13 UTC (permalink / raw)
To: Adi Ratiu, Benjamin Berg
Cc: linux-wireless, kvalo, ath9k-devel, ath9k-devel, linux-kernel
In-Reply-To: <20160815150028.7909-1-adi@adirat.com>
Adi Ratiu <adi@adirat.com> wrote:
> commit cfda2d8e2314 ("ath9k: Fix beacon configuration for
> addition/removal of interfaces") reworked beacon configs to happen at
> IF changes and missed cases when NL80211_IFTYPE_STATION has no beacons
> with the corresponding values iter_data.primary_beacon_vif == 0 and
> iter_data.nbcnvifs == 0 in ath9k_calculate_summary_state(), thus
> calling ath9k_beacon_config() with null and giving the below warning.
>
> Fix this by calling beacon config only when a beacon actually exists,
> i.e. by checking iter_data.beacons which should be set only inside
> ath9k_vif_iter_set_beacon() (the line "iter_data.beacons = true;" in
> ath9k_calculate_summary_state() is a bug in above rework commit).
>
> [ 16.910537] ------------[ cut here ]------------
> [ 16.910549] WARNING: CPU: 2 PID: 6 at drivers/net/wireless/ath/ath9k/beacon.c:642 ath9k_beacon_config+0x12c/0x130 [ath9k]
> [ 16.910551] Modules linked in: intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel hid_generic aesni_intel usbhid hid aes_x86_64 joydev mousedev arc4 lrw ath9k dell_laptop ath9k_common ath9k_hw ath mac80211 gf128mul glue_helper ablk_helper dell_smbios input_leds cryptd led_class snd_hda_codec_hdmi psmouse cfg80211 serio_raw atkbd snd_hda_codec_realtek libps2 rfkill r8169 sr_mod snd_hda_codec_generic dcdbas cdrom mii snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core i8042 snd_pcm snd_timer serio ac xhci_pci xhci_hcd battery i2c_i801 tpm_tis pcspkr tpm_tis_core evdev shpchp lpc_ich i2c_smbus tpm sch_fq_codel ip_tables x_tables
> [ 16.910620] CPU: 2 PID: 6 Comm: kworker/u16:0 Not tainted 4.8.0-rc1-next-20160815-g118253a #1
> [ 16.910621] Hardware name: Dell Inc. Inspiron 3521/018DYG, BIOS A14 07/31/2015
> [ 16.910648] Workqueue: phy0 ieee80211_iface_work [mac80211]
> [ 16.910652] 0000000000000000 ffff880159f13630 ffffffff813140f0 0000000000000000
> [ 16.910657] 0000000000000000 ffff880159f13670 ffffffff8106b22b 0000028200000202
> [ 16.910661] ffff880156bc1500 0000000000000000 ffff880153cc8018 ffff880153cc8018
> [ 16.910666] Call Trace:
> [ 16.910674] [<ffffffff813140f0>] dump_stack+0x63/0x83
> [ 16.910678] [<ffffffff8106b22b>] __warn+0xcb/0xf0
> [ 16.910682] [<ffffffff8106b31d>] warn_slowpath_null+0x1d/0x20
> [ 16.910690] [<ffffffffa02fceec>] ath9k_beacon_config+0x12c/0x130 [ath9k]
> [ 16.910696] [<ffffffffa03010f6>] ath9k_calculate_summary_state+0xf6/0x350 [ath9k]
> [ 16.910703] [<ffffffffa0301b46>] ath9k_bss_info_changed+0x186/0x1a0 [ath9k]
> [ 16.910720] [<ffffffffa025dd71>] ieee80211_bss_info_change_notify+0xb1/0x200 [mac80211]
> [ 16.910737] [<ffffffffa02c088c>] ieee80211_assoc_success+0x677/0xdeb [mac80211]
> [ 16.910746] [<ffffffff810adea2>] ? up+0x32/0x50
> [ 16.910751] [<ffffffff810bcf3b>] ? wake_up_klogd+0x3b/0x50
> [ 16.910755] [<ffffffff810bd489>] ? console_unlock+0x539/0x5f0
> [ 16.910760] [<ffffffff810bd794>] ? vprintk_emit+0x254/0x490
> [ 16.910765] [<ffffffff810bdb3f>] ? vprintk_default+0x1f/0x30
> [ 16.910769] [<ffffffff8114854d>] ? printk+0x48/0x50
> [ 16.910788] [<ffffffffa02ad0c2>] ieee80211_rx_mgmt_assoc_resp+0x152/0x4c0 [mac80211]
> [ 16.910807] [<ffffffffa02ade3f>] ieee80211_sta_rx_queued_mgmt+0x18f/0x840 [mac80211]
> [ 16.910813] [<ffffffff810d0a40>] ? lock_timer_base.isra.2+0x80/0xa0
> [ 16.910817] [<ffffffff810ad896>] ? cpuacct_charge+0x86/0xa0
> [ 16.910822] [<ffffffff8109d8e7>] ? update_curr+0xb7/0x160
> [ 16.910827] [<ffffffff8109e54c>] ? dequeue_entity+0x24c/0xa20
> [ 16.910831] [<ffffffff8109f2e3>] ? dequeue_task_fair+0x5c3/0x960
> [ 16.910848] [<ffffffffa02735b4>] ? ieee80211_iface_work+0xd4/0x410 [mac80211]
> [ 16.910865] [<ffffffffa0273775>] ieee80211_iface_work+0x295/0x410 [mac80211]
> [ 16.910870] [<ffffffff81090537>] ? finish_task_switch+0x77/0x1e0
> [ 16.910875] [<ffffffff810832d5>] process_one_work+0x1e5/0x470
> [ 16.910880] [<ffffffff810835a8>] worker_thread+0x48/0x4e0
> [ 16.910885] [<ffffffff81083560>] ? process_one_work+0x470/0x470
> [ 16.910888] [<ffffffff81088f09>] kthread+0xc9/0xe0
> [ 16.910894] [<ffffffff81028723>] ? __switch_to+0x2c3/0x610
> [ 16.910899] [<ffffffff8173a67f>] ret_from_fork+0x1f/0x40
> [ 16.910902] [<ffffffff81088e40>] ? kthread_create_on_node+0x40/0x40
> [ 16.910904] ---[ end trace aa169ad4461f2f18 ]---
>
> Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Benjamin, does this look reasonable to you? I'm planning to queue this for 4.8.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9281191/
^ permalink raw reply
* Re: [PATCH] wlcore: mesh: add zone time sync support
From: Kalle Valo @ 2016-08-19 9:57 UTC (permalink / raw)
To: Pedersen, Thomas; +Cc: Guy Mishol, linux-wireless@vger.kernel.org
In-Reply-To: <1471538527.3432.21.camel@qca.qualcomm.com>
"Pedersen, Thomas" <twp@qca.qualcomm.com> writes:
> On Mon, 2016-08-08 at 11:57 +0300, Guy Mishol wrote:
>> Add zone time sync support for mesh role.
>> This allows to configure the mesh peer
>> master of each zone for time synchronization.
>
> What is this? mac80211 already tries to maintain TSF sync with mesh
> peers if get/set TSF ops are supported by the driver.
Yeah, and why use debugfs?
--
Kalle Valo
^ permalink raw reply
* Re: ath9k: Fix beacon configuration assertion failure
From: Kalle Valo @ 2016-08-19 10:03 UTC (permalink / raw)
To: Adi Ratiu
Cc: Benjamin Berg, linux-wireless, ath9k-devel, ath9k-devel,
linux-kernel, Felix Fietkau
In-Reply-To: <fb48526fcf8f4b6db25c20b727c4a3d5@euamsexm01a.eu.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Adi Ratiu <adi@adirat.com> wrote:
>> commit cfda2d8e2314 ("ath9k: Fix beacon configuration for
>> addition/removal of interfaces") reworked beacon configs to happen at
>> IF changes and missed cases when NL80211_IFTYPE_STATION has no beacons
>> with the corresponding values iter_data.primary_beacon_vif == 0 and
>> iter_data.nbcnvifs == 0 in ath9k_calculate_summary_state(), thus
>> calling ath9k_beacon_config() with null and giving the below warning.
>>
>> Fix this by calling beacon config only when a beacon actually exists,
>> i.e. by checking iter_data.beacons which should be set only inside
>> ath9k_vif_iter_set_beacon() (the line "iter_data.beacons = true;" in
>> ath9k_calculate_summary_state() is a bug in above rework commit).
>>
>> [ 16.910537] ------------[ cut here ]------------
>> [ 16.910549] WARNING: CPU: 2 PID: 6 at drivers/net/wireless/ath/ath9k/beacon.c:642 ath9k_beacon_config+0x12c/0x130 [ath9k]
>> [ 16.910551] Modules linked in: intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel hid_generic aesni_intel usbhid hid aes_x86_64 joydev mousedev arc4 lrw ath9k dell_laptop ath9k_common ath9k_hw ath mac80211 gf128mul glue_helper ablk_helper dell_smbios input_leds cryptd led_class snd_hda_codec_hdmi psmouse cfg80211 serio_raw atkbd snd_hda_codec_realtek libps2 rfkill r8169 sr_mod snd_hda_codec_generic dcdbas cdrom mii snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core i8042 snd_pcm snd_timer serio ac xhci_pci xhci_hcd battery i2c_i801 tpm_tis pcspkr tpm_tis_core evdev shpchp lpc_ich i2c_smbus tpm sch_fq_codel ip_tables x_tables
>> [ 16.910620] CPU: 2 PID: 6 Comm: kworker/u16:0 Not tainted 4.8.0-rc1-next-20160815-g118253a #1
>> [ 16.910621] Hardware name: Dell Inc. Inspiron 3521/018DYG, BIOS A14 07/31/2015
>> [ 16.910648] Workqueue: phy0 ieee80211_iface_work [mac80211]
>> [ 16.910652] 0000000000000000 ffff880159f13630 ffffffff813140f0 0000000000000000
>> [ 16.910657] 0000000000000000 ffff880159f13670 ffffffff8106b22b 0000028200000202
>> [ 16.910661] ffff880156bc1500 0000000000000000 ffff880153cc8018 ffff880153cc8018
>> [ 16.910666] Call Trace:
>> [ 16.910674] [<ffffffff813140f0>] dump_stack+0x63/0x83
>> [ 16.910678] [<ffffffff8106b22b>] __warn+0xcb/0xf0
>> [ 16.910682] [<ffffffff8106b31d>] warn_slowpath_null+0x1d/0x20
>> [ 16.910690] [<ffffffffa02fceec>] ath9k_beacon_config+0x12c/0x130 [ath9k]
>> [ 16.910696] [<ffffffffa03010f6>] ath9k_calculate_summary_state+0xf6/0x350 [ath9k]
>> [ 16.910703] [<ffffffffa0301b46>] ath9k_bss_info_changed+0x186/0x1a0 [ath9k]
>> [ 16.910720] [<ffffffffa025dd71>] ieee80211_bss_info_change_notify+0xb1/0x200 [mac80211]
>> [ 16.910737] [<ffffffffa02c088c>] ieee80211_assoc_success+0x677/0xdeb [mac80211]
>> [ 16.910746] [<ffffffff810adea2>] ? up+0x32/0x50
>> [ 16.910751] [<ffffffff810bcf3b>] ? wake_up_klogd+0x3b/0x50
>> [ 16.910755] [<ffffffff810bd489>] ? console_unlock+0x539/0x5f0
>> [ 16.910760] [<ffffffff810bd794>] ? vprintk_emit+0x254/0x490
>> [ 16.910765] [<ffffffff810bdb3f>] ? vprintk_default+0x1f/0x30
>> [ 16.910769] [<ffffffff8114854d>] ? printk+0x48/0x50
>> [ 16.910788] [<ffffffffa02ad0c2>] ieee80211_rx_mgmt_assoc_resp+0x152/0x4c0 [mac80211]
>> [ 16.910807] [<ffffffffa02ade3f>] ieee80211_sta_rx_queued_mgmt+0x18f/0x840 [mac80211]
>> [ 16.910813] [<ffffffff810d0a40>] ? lock_timer_base.isra.2+0x80/0xa0
>> [ 16.910817] [<ffffffff810ad896>] ? cpuacct_charge+0x86/0xa0
>> [ 16.910822] [<ffffffff8109d8e7>] ? update_curr+0xb7/0x160
>> [ 16.910827] [<ffffffff8109e54c>] ? dequeue_entity+0x24c/0xa20
>> [ 16.910831] [<ffffffff8109f2e3>] ? dequeue_task_fair+0x5c3/0x960
>> [ 16.910848] [<ffffffffa02735b4>] ? ieee80211_iface_work+0xd4/0x410 [mac80211]
>> [ 16.910865] [<ffffffffa0273775>] ieee80211_iface_work+0x295/0x410 [mac80211]
>> [ 16.910870] [<ffffffff81090537>] ? finish_task_switch+0x77/0x1e0
>> [ 16.910875] [<ffffffff810832d5>] process_one_work+0x1e5/0x470
>> [ 16.910880] [<ffffffff810835a8>] worker_thread+0x48/0x4e0
>> [ 16.910885] [<ffffffff81083560>] ? process_one_work+0x470/0x470
>> [ 16.910888] [<ffffffff81088f09>] kthread+0xc9/0xe0
>> [ 16.910894] [<ffffffff81028723>] ? __switch_to+0x2c3/0x610
>> [ 16.910899] [<ffffffff8173a67f>] ret_from_fork+0x1f/0x40
>> [ 16.910902] [<ffffffff81088e40>] ? kthread_create_on_node+0x40/0x40
>> [ 16.910904] ---[ end trace aa169ad4461f2f18 ]---
>>
>> Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
>
> Benjamin, does this look reasonable to you? I'm planning to queue this for 4.8.
Actually, I see two patches which might be related but not identical:
ath9k: fix client mode beacon configuration
https://patchwork.kernel.org/patch/9247699/
ath9k: Fix beacon configuration assertion failure
https://patchwork.kernel.org/patch/9281191/
Felix (CCed) & Benjamin: please take a look and advice which one I
should take.
--
Kalle Valo
^ permalink raw reply
* Re: ath9k: fix misleading indent
From: Kalle Valo @ 2016-08-19 10:06 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Bob Copeland
In-Reply-To: <20160721163107.686-1-me@bobcopeland.com>
Bob Copeland <me@bobcopeland.com> wrote:
> Fixes smatch warning:
>
> ath9k_vif_iter_set_beacon() warn if statement not indented
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
4c51e7db87b7 ath9k: fix misleading indent
--
Sent by pwcli
https://patchwork.kernel.org/patch/9241937/
^ permalink raw reply
* Re: [1/1,V3] ath9k: consider return code on
From: Kalle Valo @ 2016-08-19 10:07 UTC (permalink / raw)
To: Eduardo Abinader; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <490b6e07-d357-7985-8796-80125322e82e@riverbed.com>
Eduardo Abinader <eduardo.abinader@riverbed.com> wrote:
> just to comply with current ath9k_hw_nvram_read to return value, hence
> behaving reacting accordingly.
>
> Signed-off-by: Eduardo Abinader <eduardo.abinader@riverbed.com>
Thanks, 1 patch applied to ath-next branch of ath.git:
a5d268277ad5 ath9k: consider return code on
--
Sent by pwcli
https://patchwork.kernel.org/patch/9249821/
^ permalink raw reply
* Re: [4.8] ath9k: fix using sta->drv_priv before initializing it
From: Kalle Valo @ 2016-08-19 10:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <20160802110322.38359-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> A station pointer can be passed to the driver on tx, before it has been
> marked as associated. Since ath9k_sta_state was initializing the entry
> too late, it resulted in some spurious crashes.
>
> Fixes: df3c6eb34da5 ("ath9k: Use sta_state() callback")
> Cc: stable@vger.kernel.org
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
I'm planning to queue this for 4.8.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9255463/
^ permalink raw reply
* Re: [1/8] wil6210: align to latest auto generated wmi.h
From: Kalle Valo @ 2016-08-19 10:12 UTC (permalink / raw)
To: Maya Erez; +Cc: Kalle Valo, Maya Erez, linux-wireless, wil6210
In-Reply-To: <1470138132-18071-2-git-send-email-qca_merez@qca.qualcomm.com>
Maya Erez <qca_merez@qca.qualcomm.com> wrote:
> Align to latest version of the auto generated wmi file
> describing the interface with FW.
>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Thanks, 8 patches applied to ath-next branch of ath.git:
0163b0319900 wil6210: align to latest auto generated wmi.h
f1b7764f8626 wil6210: fix HALP handling in case of HALP vote time-out
74b6ac586d9c wil6210: support rx key setting for all TIDs
ef86f249fa49 wil6210: change HALP logging category to IRQ
d35c2b6f8ffa wil6210: fix stop p2p device handling
b0c0e688e523 wil6210: Fix driver down flow
dc90506f1458 wil6210: prevent usage of incorrect TX hwtail
2690c4c0e83b wil6210: fix wiphy registration sequence
--
Sent by pwcli
https://patchwork.kernel.org/patch/9259343/
^ permalink raw reply
* Re: ath9k: Fix beacon configuration assertion failure
From: Ioan-Adrian Ratiu @ 2016-08-19 11:00 UTC (permalink / raw)
To: Kalle Valo
Cc: Benjamin Berg, linux-wireless, ath9k-devel, ath9k-devel,
linux-kernel, Felix Fietkau
In-Reply-To: <87fuq1yt1x.fsf@kamboji.qca.qualcomm.com>
Hi
On Fri, 19 Aug 2016, Kalle Valo <kvalo@codeaurora.org> wrote:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
>> Adi Ratiu <adi@adirat.com> wrote:
>>> commit cfda2d8e2314 ("ath9k: Fix beacon configuration for
>>> addition/removal of interfaces") reworked beacon configs to happen at
>>> IF changes and missed cases when NL80211_IFTYPE_STATION has no beacons
>>> with the corresponding values iter_data.primary_beacon_vif == 0 and
>>> iter_data.nbcnvifs == 0 in ath9k_calculate_summary_state(), thus
>>> calling ath9k_beacon_config() with null and giving the below warning.
>>>
>>> Fix this by calling beacon config only when a beacon actually exists,
>>> i.e. by checking iter_data.beacons which should be set only inside
>>> ath9k_vif_iter_set_beacon() (the line "iter_data.beacons = true;" in
>>> ath9k_calculate_summary_state() is a bug in above rework commit).
>>>
>>> [ 16.910537] ------------[ cut here ]------------
>>> [ 16.910549] WARNING: CPU: 2 PID: 6 at drivers/net/wireless/ath/ath9k/beacon.c:642 ath9k_beacon_config+0x12c/0x130 [ath9k]
>>> [ 16.910551] Modules linked in: intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel hid_generic aesni_intel usbhid hid aes_x86_64 joydev mousedev arc4 lrw ath9k dell_laptop ath9k_common ath9k_hw ath mac80211 gf128mul glue_helper ablk_helper dell_smbios input_leds cryptd led_class snd_hda_codec_hdmi psmouse cfg80211 serio_raw atkbd snd_hda_codec_realtek libps2 rfkill r8169 sr_mod snd_hda_codec_generic dcdbas cdrom mii snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core i8042 snd_pcm snd_timer serio ac xhci_pci xhci_hcd battery i2c_i801 tpm_tis pcspkr tpm_tis_core evdev shpchp lpc_ich i2c_smbus tpm sch_fq_codel ip_tables x_tables
>>> [ 16.910620] CPU: 2 PID: 6 Comm: kworker/u16:0 Not tainted 4.8.0-rc1-next-20160815-g118253a #1
>>> [ 16.910621] Hardware name: Dell Inc. Inspiron 3521/018DYG, BIOS A14 07/31/2015
>>> [ 16.910648] Workqueue: phy0 ieee80211_iface_work [mac80211]
>>> [ 16.910652] 0000000000000000 ffff880159f13630 ffffffff813140f0 0000000000000000
>>> [ 16.910657] 0000000000000000 ffff880159f13670 ffffffff8106b22b 0000028200000202
>>> [ 16.910661] ffff880156bc1500 0000000000000000 ffff880153cc8018 ffff880153cc8018
>>> [ 16.910666] Call Trace:
>>> [ 16.910674] [<ffffffff813140f0>] dump_stack+0x63/0x83
>>> [ 16.910678] [<ffffffff8106b22b>] __warn+0xcb/0xf0
>>> [ 16.910682] [<ffffffff8106b31d>] warn_slowpath_null+0x1d/0x20
>>> [ 16.910690] [<ffffffffa02fceec>] ath9k_beacon_config+0x12c/0x130 [ath9k]
>>> [ 16.910696] [<ffffffffa03010f6>] ath9k_calculate_summary_state+0xf6/0x350 [ath9k]
>>> [ 16.910703] [<ffffffffa0301b46>] ath9k_bss_info_changed+0x186/0x1a0 [ath9k]
>>> [ 16.910720] [<ffffffffa025dd71>] ieee80211_bss_info_change_notify+0xb1/0x200 [mac80211]
>>> [ 16.910737] [<ffffffffa02c088c>] ieee80211_assoc_success+0x677/0xdeb [mac80211]
>>> [ 16.910746] [<ffffffff810adea2>] ? up+0x32/0x50
>>> [ 16.910751] [<ffffffff810bcf3b>] ? wake_up_klogd+0x3b/0x50
>>> [ 16.910755] [<ffffffff810bd489>] ? console_unlock+0x539/0x5f0
>>> [ 16.910760] [<ffffffff810bd794>] ? vprintk_emit+0x254/0x490
>>> [ 16.910765] [<ffffffff810bdb3f>] ? vprintk_default+0x1f/0x30
>>> [ 16.910769] [<ffffffff8114854d>] ? printk+0x48/0x50
>>> [ 16.910788] [<ffffffffa02ad0c2>] ieee80211_rx_mgmt_assoc_resp+0x152/0x4c0 [mac80211]
>>> [ 16.910807] [<ffffffffa02ade3f>] ieee80211_sta_rx_queued_mgmt+0x18f/0x840 [mac80211]
>>> [ 16.910813] [<ffffffff810d0a40>] ? lock_timer_base.isra.2+0x80/0xa0
>>> [ 16.910817] [<ffffffff810ad896>] ? cpuacct_charge+0x86/0xa0
>>> [ 16.910822] [<ffffffff8109d8e7>] ? update_curr+0xb7/0x160
>>> [ 16.910827] [<ffffffff8109e54c>] ? dequeue_entity+0x24c/0xa20
>>> [ 16.910831] [<ffffffff8109f2e3>] ? dequeue_task_fair+0x5c3/0x960
>>> [ 16.910848] [<ffffffffa02735b4>] ? ieee80211_iface_work+0xd4/0x410 [mac80211]
>>> [ 16.910865] [<ffffffffa0273775>] ieee80211_iface_work+0x295/0x410 [mac80211]
>>> [ 16.910870] [<ffffffff81090537>] ? finish_task_switch+0x77/0x1e0
>>> [ 16.910875] [<ffffffff810832d5>] process_one_work+0x1e5/0x470
>>> [ 16.910880] [<ffffffff810835a8>] worker_thread+0x48/0x4e0
>>> [ 16.910885] [<ffffffff81083560>] ? process_one_work+0x470/0x470
>>> [ 16.910888] [<ffffffff81088f09>] kthread+0xc9/0xe0
>>> [ 16.910894] [<ffffffff81028723>] ? __switch_to+0x2c3/0x610
>>> [ 16.910899] [<ffffffff8173a67f>] ret_from_fork+0x1f/0x40
>>> [ 16.910902] [<ffffffff81088e40>] ? kthread_create_on_node+0x40/0x40
>>> [ 16.910904] ---[ end trace aa169ad4461f2f18 ]---
>>>
>>> Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
>>
>> Benjamin, does this look reasonable to you? I'm planning to queue this for 4.8.
>
> Actually, I see two patches which might be related but not identical:
>
> ath9k: fix client mode beacon configuration
> https://patchwork.kernel.org/patch/9247699/
>
> ath9k: Fix beacon configuration assertion failure
> https://patchwork.kernel.org/patch/9281191/
Definitely we're touching the same logic and I'm leaning in the
direction of dropping my patch and using Felix's.
I can't test the other patch right noum though because I'm on vacantion.
I'll test next week and report back.
>
> Felix (CCed) & Benjamin: please take a look and advice which one I
> should take.
>
> --
> Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
From: Ben Greear @ 2016-08-19 13:34 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k@lists.infradead.org, linux-wireless
In-Reply-To: <CA+BoTQn0d1bEB662r-Yivmdk_21LhjCQjJP_GoPaj-WT2wA=1g@mail.gmail.com>
On 08/18/2016 11:59 PM, Michal Kazior wrote:
> On 19 August 2016 at 03:26, <greearb@candelatech.com> wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> I was seeing kernel crashes due to accessing freed memory
>> while debugging a 9984 firmware that was crashing often.
>>
>> This patch fixes the crashes. I am not certain if there
>> is a better way or not.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index 5659ef1..916119c 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -4172,8 +4172,10 @@ static void ath10k_mac_txq_init(struct ieee80211_txq *txq)
>> static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
>> {
>> struct ath10k_txq *artxq = (void *)txq->drv_priv;
>> + struct ath10k_txq *tmp, *walker;
>> struct ath10k_skb_cb *cb;
>> struct sk_buff *msdu;
>> + struct ieee80211_txq *txq_tmp;
>> int msdu_id;
>>
>> if (!txq)
>> @@ -4182,6 +4184,14 @@ static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
>> spin_lock_bh(&ar->txqs_lock);
>> if (!list_empty(&artxq->list))
>> list_del_init(&artxq->list);
>> +
>> + /* Remove from ar->txqs in case it still exists there. */
>> + list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
>> + txq_tmp = container_of((void *)walker, struct ieee80211_txq,
>> + drv_priv);
>> + if (txq_tmp == txq)
>> + list_del(&walker->list);
>> + }
>
> How could this even happen? All artxq->list accesses (add/del) are
> protected by txqs_lock so this shouldn't happen, no?
>
> Do you perhaps have the logic around txqs reworked in your tree?
I don't have any significant changes as far as I can tell.
I can build you a buggy 9984 firmware to reproduce the problem if you want...
Maybe the upstream patch could WARN_ON in this case to see if anyone else
ever hits it?
I did see a comment in the mac80211 about some assumptions on the driver with
regard to station teardown...I am not 100% sure ath10k meets that assumption,
so maybe that is why I could see this problem.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] rtlwifi: Fix missing country code for Great Britain
From: Larry Finger @ 2016-08-19 15:14 UTC (permalink / raw)
To: kvalo; +Cc: devel, linux-wireless, Larry Finger, Stable
Some RTL8821AE devices sold in Great Britain have the country code of
0x25 encoded in their EEPROM. This value is not tested in the routine
that establishes the regulatory info for the chip. The fix is to set
this code to have the same capabilities as the EU countries.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
---
drivers/net/wireless/realtek/rtlwifi/regd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
index 3524441..6ee6bf8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/regd.c
+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
@@ -345,9 +345,9 @@ static const struct ieee80211_regdomain *_rtl_regdomain_select(
return &rtl_regdom_no_midband;
case COUNTRY_CODE_IC:
return &rtl_regdom_11;
- case COUNTRY_CODE_ETSI:
case COUNTRY_CODE_TELEC_NETGEAR:
return &rtl_regdom_60_64;
+ case COUNTRY_CODE_ETSI:
case COUNTRY_CODE_SPAIN:
case COUNTRY_CODE_FRANCE:
case COUNTRY_CODE_ISRAEL:
@@ -406,6 +406,8 @@ static u8 channel_plan_to_country_code(u8 channelplan)
return COUNTRY_CODE_WORLD_WIDE_13;
case 0x22:
return COUNTRY_CODE_IC;
+ case 0x25:
+ return COUNTRY_CODE_ETSI;
case 0x32:
return COUNTRY_CODE_TELEC_NETGEAR;
case 0x41:
--
2.6.6
^ permalink raw reply related
* Re: [PATCH v2] brcmfmac: shut down AP and set IBSS mode only on primary interface
From: Rafał Miłecki @ 2016-08-19 15:53 UTC (permalink / raw)
To: Wright Feng
Cc: open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Arend Van Spriel, Kalle Valo, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, linux-wireless@vger.kernel.org, chln
In-Reply-To: <1470894260-18128-1-git-send-email-wright.feng@cypress.com>
On 11 August 2016 at 07:44, Wright Feng <wright.feng@cypress.com> wrote:
> When stopping hostap on virtual interface, driver will set INFRA and AP
> mode that may affect the functionality on primary interface. For example,
> if we create and stop hostapd on virtual interface then association
> cannot work on primary interface because INFRA mode has been set to IBSS.
> Hence we shut down AP and set IBSS mode only on primary interface.
You also excluded from execution code setting BRCMF_C_SET_AP to 0.
Does it get a reset at some point? Maybe with a "bss" call? I'm
wondering if it's possible to use interface in managed mode if it was
used as AP once.
--=20
Rafa=C5=82
^ 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