Can anyone explain how the overall RSSI is calculated versus the per chain
RSSI? Sometimes, it seems to be the maximum of the per chain RSSI and
other times it's none of them.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
mac80211 configure rxfilter per HW,
so we don't need this per channel.
As I said before, I think there's value in mac80211 doing it per chanctx
or even per vif, and it should be more efficient to do so.
It's tempting to do it per vif
Advertise p2p device support when ath9k loaded with
use_chanctx=1.
This will fix problem, when first interface is an AP
and next we would like to run p2p_find.
Before p2p find (scan phase) failed with EOPNOTSUPP.
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
mac80211 configure rxfilter per HW,
so we don't need this per channel.
This fix problem when chanctx used and ath9k
allocate new internal ath_chanctx (eg. when
offchannel) and we loose rxfilter configuration.
Eg. when p2p_find (with use_chanctx=1), during
remain on channel, driver create new
Patches for problems I hit during P2P tests when
multichannel used (driver loaded with use_chanctx=1).
Janusz Dziedzic (3):
ath9k: handle RoC abort correctly
ath9k: make rxfilter per HW
ath9k: advertise p2p dev support when chanctx
drivers/net/wireless/ath/ath9k/ath9k.h | 3 ++-
On Mon, 2015-06-22 at 13:58 +0200, Johannes Berg wrote:
On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
mac80211 configure rxfilter per HW,
so we don't need this per channel.
As I said before, I think there's value in mac80211 doing it per chanctx
or even per vif, and it should
On Mon, Jun 22, 2015 at 5:13 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
In case we will get ROC abort we should not call
ieee80211_remain_on_channel_expired().
In other case I hit such warning on MIPS and
p2p negotiation failed (tested with use_chanctx=1).
ath: phy0: Starting RoC
In case we will get ROC abort we should not call
ieee80211_remain_on_channel_expired().
In other case I hit such warning on MIPS and
p2p negotiation failed (tested with use_chanctx=1).
ath: phy0: Starting RoC period
ath: phy0: Channel definition created: 2412 MHz
ath: phy0: Assigned next_chan to
On 2015-06-22 13:59, Johannes Berg wrote:
On Mon, 2015-06-22 at 13:58 +0200, Johannes Berg wrote:
On Mon, 2015-06-22 at 13:43 +0200, Janusz Dziedzic wrote:
mac80211 configure rxfilter per HW,
so we don't need this per channel.
As I said before, I think there's value in mac80211 doing it
On 22 June 2015 at 13:56, Krishna Chaitanya chaitanya.m...@gmail.com wrote:
On Mon, Jun 22, 2015 at 5:13 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
In case we will get ROC abort we should not call
ieee80211_remain_on_channel_expired().
In other case I hit such warning on MIPS and
On Mon, Jun 22, 2015 at 6:32 PM, Michal Kazior michal.kaz...@tieto.com wrote:
On 22 June 2015 at 13:56, Krishna Chaitanya chaitanya.m...@gmail.com wrote:
On Mon, Jun 22, 2015 at 5:13 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
In case we will get ROC abort we should not call
11 matches
Mail list logo
