Michal Kazior wrote:
On 3 September 2014 15:10, Robb rbarr...@gmail.com wrote:
You are making an assumption ath9k == ath9k_htc. This is not correct.
I would actually suspect the ath9k_htc *chips* actually are capable of
providing the necessary information to create survey dump but the
From: Sujith Manoharan c_man...@qca.qualcomm.com
If multiple channel contexts are active, then the opmode
can be different in each context. Since the RX filter is
calculated in ath_startrecv() before switching to the
new opmode, the wrong filters are chosen.
Fix this by calling
From: Sujith Manoharan c_man...@qca.qualcomm.com
ATH9K_RX_FILTER_COMP_BAR is used to receive BAR
completion frames and is set if the current channel
is HT. When channel contexts are enabled, instead of using
the mac80211 helpers, check if the current channel
definition is HT.
Signed-off
From: Sujith Manoharan c_man...@qca.qualcomm.com
Currently, different units are used for handling
sc-offchannel.duration. In scan mode, it contains jiffies and in RoC
mode, milliseconds is used. This causes confusion since in
ath_chanctx_switch(), TU_TO_USEC is used to determine the offchannel
From: Sujith Manoharan c_man...@qca.qualcomm.com
The NoA duration for a GO is half the beacon interval
and a concurrent context like a STA can be active only
for that duration, before switching back to the GO's
operating channel.
Currently, when multiple beacons are missed, the dwell
time
From: Sujith Manoharan c_man...@qca.qualcomm.com
The NoA duration for a GO is half the beacon interval
and a concurrent context like a STA can be active only
for that duration, before switching back to the GO's
operating channel.
Currently, when multiple beacons are missed, the dwell
time
From: Sujith Manoharan c_man...@qca.qualcomm.com
Since the NoA duration is the maximum time the GO interface
can be offline, it needs to include the time take to
switch channels in the HW.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/channel.c | 2
From: Sujith Manoharan c_man...@qca.qualcomm.com
This reverts commit 09ebb810927a110e4c354beb20308830d108a54b.
ath9k_hw_set_sta_beacon_timers() configures AR_TIM_PERIOD with
the beacon interval. Before this commit, the sleepduration was
never greater than the beacon interval. But now
From: Sujith Manoharan c_man...@qca.qualcomm.com
When interfaces of different types are present
in a context and an offchannel request is received
on a STA interface, we end up trying to process
beacons received when we are offchannel. This hits
the below warning since offchannel will not have
From: Sujith Manoharan c_man...@qca.qualcomm.com
In MCC mode, the TSF of a context needs to be
adjusted only if it is GO/AP.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/channel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net
Emmanuel Grumbach wrote:
mac80211 will not wait until the context switch happen specifically,
but if you can wait
in the driver in the flush() callback until the deauth is being sent -
whatever you need to
happen to have that done, context switch, TX queues to move etc... -
then you should
Sujith Manoharan wrote:
I don't think trying to switch channel contexts in the flush() callback
is a good idea. We would be changing the meaning of the callback if
we do that. Moreover flush() is called from many other places too, like the
PS code.
It seems appropriate to instruct a driver
Felix Fietkau wrote:
Wouldn't it make more sense to put this into ath9k_vif_iter()
I wanted to have a single place where we can have
p2p/mcc specific overrides that will not affect the normal
mode. Having a separate function for it seems reasonable, IMO.
Sujith
--
To unsubscribe from this list:
Sujith Manoharan wrote:
From: Sujith Manoharan c_man...@qca.qualcomm.com
Since RoC is done before frames marked with
IEEE80211_TX_CTL_TX_OFFCHAN are received by the driver,
setting force_channel is useless. We will be in
the required offchannel, so incoming frames can
be transmitted
From: Sujith Manoharan c_man...@qca.qualcomm.com
When multiple channel contexts are enabled, a p2p interface
that is assigned to a context will have an address that
is different from the device mac address, which is used
by wpa_s as the p2p device ID.
Certain frames like provision requests use
From: Sujith Manoharan c_man...@qca.qualcomm.com
Using the BSS information stored in mac80211 directly
is racy in certain conditions. For example, in a MCC
setup, if the scheduler is switching channels when
a local deauth is issued, calculation of the opmode/bssid
etc. is incorrect. To avoid
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/Kconfig | 8 +
drivers/net/wireless/ath/Makefile | 2 ++
drivers/net/wireless/ath/ath.h| 1 +
drivers/net/wireless/ath/main.c | 3 ++
drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/Kconfig | 8 +
drivers/net/wireless/ath/Makefile | 4 +++
drivers/net/wireless/ath/ath.h| 1 +
drivers/net/wireless/ath/main.c | 3 ++
drivers
Kalle Valo wrote:
Why add it to ath.ko module? What drivers are going to use this?
The debug code for ath9k is in ath.ko.
Sujith
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Kalle Valo wrote:
You mean ath_printk() friends? But that doesn't require tracing code
to be in ath.ko as well, right? If I understood correctly, trace.c could
be under ath9k directory and the kconfig option could be
ATH9K_TRACEPOINTS.
I think it's just misleading and confusing for the
Kalle Valo wrote:
The current debug printing code in ath10k is something like 100 lines, I
don't see the point of trying to make that common with all ath* drivers.
In my opinion ath.ko should only have code which used at least two
different drivers (and I consider ath9k.ko and ath9k_htc.ko
From: Sujith Manoharan c_man...@qca.qualcomm.com
There is no need to check if the current
channel context has active ACs queued up
if the TX queue is not empty.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c | 5 -
1 file changed, 4
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/channel.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
From: Sujith Manoharan c_man...@qca.qualcomm.com
When we are attempting to switch to a new
channel context, the TX queues are flushed, but
the mac80211 queues are not stopped and traffic
can still come down to the driver.
This patch fixes it by stopping the queues
assigned to the current context
From: Sujith Manoharan c_man...@qca.qualcomm.com
Change the ath9k_chanctx_wake_queues() API so
that we can pass the channel context that needs its
queues to be stopped.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ath9k.h | 5 +++--
drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
When a full chip reset is done, all the queues
across all VIFs are stopped, but if MCC is enabled,
only the queues of the current context is awakened,
when we complete the reset.
This results in unfairness for the inactive context.
Since frames
From: Sujith Manoharan c_man...@qca.qualcomm.com
Pending MCC fixes, rebased over -rc7.
Sujith Manoharan (10):
ath: Add support for tracing
ath9k: Print RoC expiration
ath9k: Check pending frames properly
ath9k: Fix pending frame check
ath9k: Remove duplicate code
ath9k: Fix queue
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/channel.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/Kconfig | 8 +
drivers/net/wireless/ath/Makefile | 4 +++
drivers/net/wireless/ath/ath.h| 1 +
drivers/net/wireless/ath/main.c | 3 ++
drivers
From: Sujith Manoharan c_man...@qca.qualcomm.com
There is no need to check if the current
channel context has active ACs queued up
if the TX queue is not empty.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c | 5 -
1 file changed, 4
From: Sujith Manoharan c_man...@qca.qualcomm.com
When draining of the TX queues fails, a
full HW reset is done. ath_reset() makes sure
that the queues in mac80211 are restarted,
so there is no need to wake them up again.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
Change the ath9k_chanctx_wake_queues() API so
that we can pass the channel context that needs its
queues to be stopped.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ath9k.h | 5 +++--
drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
When a full chip reset is done, all the queues
across all VIFs are stopped, but if MCC is enabled,
only the queues of the current context is awakened,
when we complete the reset.
This results in unfairness for the inactive context.
Since frames
From: Sujith Manoharan c_man...@qca.qualcomm.com
When we are attempting to switch to a new
channel context, the TX queues are flushed, but
the mac80211 queues are not stopped and traffic
can still come down to the driver.
This patch fixes it by stopping the queues
assigned to the current context
From: Sujith Manoharan c_man...@qca.qualcomm.com
When a channel context is removed, the hw_queue_base
is set to -1, this will result in a panic because
ath9k_chanctx_stop_queues() can be called on an interface
that is not assigned to any context yet - for example,
when trying to scan.
Fix
Grumbach, Emmanuel wrote:
I can't really tell... I guess it depends on the firmware / hardware. On these
devices (dvm), the firmware would take a very long time to send / drop the
packets. I guess it is a bug, and users have been suffering from this for a
very long time. Thing is that I was
Dan Carpenter wrote:
Hello Sujith Manoharan,
This is a semi-automatic email about new static checker warnings.
The patch e6664dff0608: ath: Add support for tracing from Sep 27,
2014, leads to the following Smatch complaint:
drivers/net/wireless/ath/main.c:88 ath_printk()
error
From: Sujith Manoharan c_man...@qca.qualcomm.com
Various fixes for -next.
Sujith Manoharan (6):
ath: Fix smatch warning
ath9k: Fix crash in MCC mode
ath9k: Fix sequence number assignment
ath9k: Use sta_state() callback
ath9k: Enable multi-channel properly
ath9k: Process beacons
From: Sujith Manoharan c_man...@qca.qualcomm.com
drivers/net/wireless/ath/main.c:88 ath_printk()
error: we previously assumed 'common-hw' could be null (see line 82)
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
From: Sujith Manoharan c_man...@qca.qualcomm.com
In MCC mode, currently the decision to enable
the multi-channel state machine is done
based on the association status if one of
the interfaces assigned to a context is in
station mode.
This allows the driver to switch to the other
context before
From: Sujith Manoharan c_man...@qca.qualcomm.com
Currently, ath9k uses a global counter for all
frames that need to be assigned a sequence number.
QoS-data frames are handled properly since they
have a per-tid counter. But, beacons and other
management frames use the same counter even if
multiple
From: Sujith Manoharan c_man...@qca.qualcomm.com
When the current operating channel context has
been marked as ATH_CHANCTX_STATE_FORCE_ACTIVE,
do not process beacons that might be received,
since we have to wait for the station to become
authorized.
Signed-off-by: Sujith Manoharan c_man
Rajkumar Manoharan wrote:
These changes are the extension of pktlog for dumping tx and rx
frames to user space. I am rebasing Michal's work on top of pktlog.
-Rajkumar
Michal Kazior (3):
ath10k: add tracepoint for wmi mgmt tx frames
ath10k: add tracepoint for wmi bcn tx
ath10k:
From: Sujith Manoharan c_man...@qca.qualcomm.com
Currently, ath9k uses a global counter for all
frames that need to be assigned a sequence number.
QoS-data frames are handled properly since they
have a per-tid counter. But, beacons and other
management frames use the same counter even if
multiple
From: Sujith Manoharan c_man...@qca.qualcomm.com
When the current operating channel context has
been marked as ATH_CHANCTX_STATE_FORCE_ACTIVE,
do not process beacons that might be received,
since we have to wait for the station to become
authorized.
Also, since the cached TSF value will be zero
From: Sujith Manoharan c_man...@qca.qualcomm.com
drivers/net/wireless/ath/main.c:88 ath_printk()
error: we previously assumed 'common-hw' could be null (see line 82)
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
John W. Linville wrote:
Hmmm...am I missing something?
CC drivers/net/wireless/ath/ath9k/tx99.o
In file included from include/linux/byteorder/little_endian.h:4:0,
from ./arch/x86/include/uapi/asm/byteorder.h:4,
from include/asm-generic/bitops/le.h:5,
From: Sujith Manoharan c_man...@qca.qualcomm.com
When the current operating channel context has
been marked as ATH_CHANCTX_STATE_FORCE_ACTIVE,
do not process beacons that might be received,
since we have to wait for the station to become
authorized.
Also, since the cached TSF value will be zero
From: Sujith Manoharan c_man...@qca.qualcomm.com
Currently, ath9k uses a global counter for all
frames that need to be assigned a sequence number.
QoS-data frames are handled properly since they
have a per-tid counter. But, beacons and other
management frames use the same counter even if
multiple
From: Sujith Manoharan c_man...@qca.qualcomm.com
v3: Fix compilation error when TX99 is enabled.
Sujith Manoharan (4):
ath9k: Fix sequence number assignment
ath9k: Use sta_state() callback
ath9k: Enable multi-channel properly
ath9k: Process beacons properly
drivers/net/wireless/ath
From: Sujith Manoharan c_man...@qca.qualcomm.com
Fixes related to reset.
Sujith Manoharan (3):
ath9k: Unify reset API
ath9k: Set ATH_OP_HW_RESET before HW reset
ath9k: Disable beacon tasklet during reset
drivers/net/wireless/ath/ath9k/ath9k.h | 3 +--
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
Instead of having ath_reset_internal() and ath_reset()
as two separate calls to perform a HW reset, have
one function. This makes sure that the behavior will
be the same at all callsites.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
From: Sujith Manoharan c_man...@qca.qualcomm.com
When a chip reset is done, all running timers,
tasklets etc. are stopped but the beacon tasklet
is left running. Fix this.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c | 2 ++
1 file changed
Michal Kazior wrote:
I think you've just found an ath10k bug.
I've been running through Rx code lately. I was looking at
htt_rx_mpdu_status and noticed it was a bit greedy. I then recalled
someone was complaining about RTS reception.
Maybe the RX filter to receive control frames is not set
From: Sujith Manoharan c_man...@qca.qualcomm.com
The timeout value for flushing the TX queues
is hardcoded at 200ms right now. Use a channel
context-specific value instead to allow adjustments
to the timeout in case MCC is enabled.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
From: Sujith Manoharan c_man...@qca.qualcomm.com
When an active context transitions to inactive
state, the NoA schedule needs to be removed
for the context that has beaconing enabled.
Not doing this will affect p2p clients.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers
Johannes Berg wrote:
I'm a bit conflicted about this. If we add mgd_prepare_tx() here, what's
to say that we don't need to also do this for a variety of other frames?
Like sending delBA action frames? I guess the difference would be that
we don't disassoc immediately in those case.
Deauth was
From: Sujith Manoharan c_man...@qca.qualcomm.com
MCC fixes for -next.
Sujith Manoharan (9):
ath9k: Add a function to check for an active GO
ath9k: Check for active GO in mgd_prepare_tx()
ath9k: Use a helper function for offchannel NoA
ath9k: Use a helper function to set NoA
ath9k: Use
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/channel.c | 61 +++-
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
From: Sujith Manoharan c_man...@qca.qualcomm.com
mac80211 has to be notified when a RoC period
expires in the driver. In MCC mode, since the
offchannel/RoC timer is set with the requested
duration, ieee80211_remain_on_channel_expired() needs
to be called when the timer expires.
But, currently
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/channel.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/drivers
From: Sujith Manoharan c_man...@qca.qualcomm.com
MCC is currently used in CUS227, an Allplay
device. Since audio streaming will be affected
with long offchannel periods, reduce the max.
offchannel duration to 200ms.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net
John,
Please drop this patch.
Sujith
Malinen, Jouni wrote:
On 15/10/14 3:59 am, Sujith Manoharan suj...@msujith.org wrote:
MCC is currently used in CUS227, an Allplay
device. Since audio streaming will be affected
with long offchannel periods, reduce the max.
offchannel duration
From: Sujith Manoharan c_man...@qca.qualcomm.com
Scan completion for drivers that use HW scanning
causes a warning to be hit if the interface has been
removed. Since cfg80211 ensures that both use-after-free
and scheduling a new scan doesn't happen in this case,
WARN_ON_ONCE can be used
From: Sujith Manoharan c_man...@qca.qualcomm.com
mac80211 currently has a race which can be hit
with this sequence:
* Start a scan operation.
* TX BA is initiated by ieee80211_start_tx_ba_session().
* Driver sets up internal state and calls
ieee80211_start_tx_ba_cb_irqsafe().
* mac80211 adds
Emmanuel Grumbach wrote:
It is not really my business, but how come this happen with ath9k?
The scan should be cancelled before the interface is removed. You mean
that the scan cancellation is
asynchronous and the notification of the cancellation termination can
come after the cfg80211 has
From: Sujith Manoharan c_man...@qca.qualcomm.com
Instead of using the sta_add()/sta_remove() callbacks,
use the sta_state() callback since this gives
more fine-grained control.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c | 28
From: Sujith Manoharan c_man...@qca.qualcomm.com
When the current operating channel context has
been marked as ATH_CHANCTX_STATE_FORCE_ACTIVE,
do not process beacons that might be received,
since we have to wait for the station to become
authorized.
Also, since the cached TSF value will be zero
From: Sujith Manoharan c_man...@qca.qualcomm.com
mac80211 has to be notified when a RoC period
expires in the driver. In MCC mode, since the
offchannel/RoC timer is set with the requested
duration, ieee80211_remain_on_channel_expired() needs
to be called when the timer expires.
But, currently
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/channel.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/drivers
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/channel.c | 61 +++-
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
From: Sujith Manoharan c_man...@qca.qualcomm.com
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/channel.c | 45 ++--
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
From: Sujith Manoharan c_man...@qca.qualcomm.com
If a GO interface is active when we receive a
mgd_prepare_tx() call, then we need to send
out a new NoA before switching to a new context.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ath9k.h | 2
From: Sujith Manoharan c_man...@qca.qualcomm.com
Since both the arguments need to satisfy
the alignment requirements of ether_addr_copy(),
use memcpy() in cases where there will be no
big performance benefit and make sure that
ether_addr_copy() calls use properly aligned
arguments.
Signed-off
From: Sujith Manoharan c_man...@qca.qualcomm.com
When a chip reset is done, all running timers,
tasklets etc. are stopped but the beacon tasklet
is left running. Fix this.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c | 2 ++
1 file changed
From: Sujith Manoharan c_man...@qca.qualcomm.com
ATH_CHANCTX_EVENT_AUTHORIZED is required to trigger
the MCC scheduler when a station interface becomes
authorized. But, since the driver gets station state
notifications when the current operating mode is AP
too, make sure that we send
From: Sujith Manoharan c_man...@qca.qualcomm.com
Instead of having ath_reset_internal() and ath_reset()
as two separate calls to perform a HW reset, have
one function. This makes sure that the behavior will
be the same at all callsites.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
From: Sujith Manoharan c_man...@qca.qualcomm.com
When an active context transitions to inactive
state, the NoA schedule needs to be removed
for the context that has beaconing enabled.
Not doing this will affect p2p clients.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers
From: Sujith Manoharan c_man...@qca.qualcomm.com
When a HW reset is done, the interrupt tasklet is
disabled before ISRs are disabled in the HW. This
allows a small window where the HW can still generate
interrupts. Since the tasklet is disabled and not killed,
it is not scheduled but deferred
From: Sujith Manoharan c_man...@qca.qualcomm.com
An offchannel operation also needs to have
a flush timeout that doesn't exceed the NoA
absence duration of a GO context, so use
channel_switch_time. The first offchannel
operation is set a flush timeout of 10ms since
channel_switch_time
From: Sujith Manoharan c_man...@qca.qualcomm.com
The timeout value for flushing the TX queues
is hardcoded at 200ms right now. Use a channel
context-specific value instead to allow adjustments
to the timeout in case MCC is enabled.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
From: Sujith Manoharan c_man...@qca.qualcomm.com
Pending frames in the driver can be present
either in the HW queues or SW. ath9k_has_pending_frames()
currently checks for the HW queues first and then
checks if any ACs are queued in the driver.
In MCC mode, we need to check the HW queues alone
From: Sujith Manoharan c_man...@qca.qualcomm.com
In MCC mode, currently the decision to enable
the multi-channel state machine is done
based on the association status if one of
the interfaces assigned to a context is in
station mode.
This allows the driver to switch to the other
context before
From: Sujith Manoharan c_man...@qca.qualcomm.com
mac80211 currently has a race which can be hit
with this sequence:
* Start a scan operation.
* TX BA is initiated by ieee80211_start_tx_ba_session().
* Driver sets up internal state and calls
ieee80211_start_tx_ba_cb_irqsafe().
* mac80211 adds
From: Sujith Manoharan c_man...@qca.qualcomm.com
The flush timeout in MCC mode is very small, since
we are constrained by the time slice for each
channel context, but since only the HW queues are
flushed when switching contexts, it is acceptable.
Since the SW queues are also emptied
From: Sujith Manoharan c_man...@qca.qualcomm.com
This patch makes sure that a GO interface
sends out a new NoA schedule with 200ms duration
when mgd_prepare_tx() is called.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
Instead of using ATH_CHANCTX_EVENT_ASSIGN to abort
a HW scan when a new interface becomes active, use the
mgd_prepare_tx() callback. This allows us to make
sure that the GO's channel becomes operational by
using flush_work().
Signed-off-by: Sujith
Felix Fietkau wrote:
- else if (AR_SREV_9340(ah))
- INIT_INI_ARRAY(ah-iniModesTxGain,
- ar9340Modes_ub124_tx_gain_table_1p0);
Shouldn't the array in ar9340_initvals.h also be removed ?
Sujith
--
To unsubscribe from this list: send the line unsubscribe
Felix Fietkau wrote:
ar9002_hw_pa_cal(ah, true);
+ ath9k_hw_start_nfcal(ah, true);
if (ah-caldata)
set_bit(NFCAL_PENDING, ah-caldata-cal_flags);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 8be4b14..85a7817
Felix Fietkau wrote:
+ if (!ar9002_hw_per_calibration(ah, chan, rxchainmask, currCal))
+ return 0;
+
+ ah-cal_list_curr = currCal = currCal-calNext;
+ if (currCal-calState == CAL_WAITING) {
+
Johannes Berg wrote:
If it's a mac80211 race, wouldn't it make sense to fix it in mac80211?
Yes, definitely. :-)
But, we also ran into issues where starting a BA session
when HW scan was in progress (with MCC enabled) caused connectivity
problems, hence this fix in ath9k.
Regarding the BA
Johannes Berg wrote:
Those commits say they *fix* the race though, so in case I was wrong you
should report the sequence of events so we can look at fixing it
properly?
The commits fix both the issues (use-after-free, new scan) correctly,
so I don't see a race ? If the driver is slow in
Johannes Berg wrote:
But the driver can/should just do it when the interface is removed from
it? Otherwise it has no valid way to run/continue the scan anyway?
cancel_hw_scan() is called before remove_interface() and if the
interface is removed in cfg80211 before __cfg80211_scan_done() gets
a
Johannes Berg wrote:
I'm not sure that's true - the WARN_ON you're modifying keys off
something that happens in cfg80211_scan_done(), not
__cfg80211_scan_done(), so as long as the driver called
cfg80211_scan_done() properly things should be OK?
Here is a trace log showing the issue -
Johannes Berg wrote:
Maybe we need something like this:
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index af0d094b2f2f..45b74ab1c59d 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -985,7 +985,6 @@ void ieee80211_scan_cancel(struct ieee80211_local *local)
From: Sujith Manoharan c_man...@qca.qualcomm.com
Enabling HW queue control for normal (non-mcc) mode
causes problems with queue management, resulting
in traffic stall. Since it is mainly required for
fairness in MCC mode, disable it for the general case.
Bug: https://dev.openwrt.org/ticket/18164
From: Sujith Manoharan c_man...@qca.qualcomm.com
Initval updates for AR9580 and AR955x.
$ ./verify_checksums.sh
ar955x-1p0 b98d3c01075feed8b7154f5bfa8f122268cbe3c7 pass
ar9580-1p0 c7c799f2a30aff70b2125ea06cef23d1529c38fa fail
+03f9364192c676aa398e7da84e31f9db33ae2da4
From: Sujith Manoharan c_man...@qca.qualcomm.com
* Fix a 11b/EVM issue by adjusting
FIR filter coefficients.
* Fix a problem with receiving probe request
frames sent at 11b rate.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
This fixes RX sensitivity issues with AR9580.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
.../net/wireless/ath/ath9k/ar9580_1p0_initvals.h | 144 -
1 file changed, 143 insertions(+), 1 deletion(-)
diff
Hi,
This series looks good to me...
Sujith
Felix Fietkau wrote:
The initvals use up quite a bit of space, and PC-OEM support is
typically not needed on embedded systems
Signed-off-by: Felix Fietkau n...@openwrt.org
---
drivers/net/wireless/ath/ath9k/Kconfig | 5
1 - 100 of 257 matches
Mail list logo
