On Mon, Sep 03, 2012 at 07:31:34PM +0530, Mohammed Shafi wrote:
Hi Antonio,
Other than that, patch 2/6 should be modified to take into account IBSS
mode.
yeah saw your patch, that in ath9k_htc IBSS interface can coexist with
one more interface.
sorry for the delayed
Hello,
In our experiments, we use iperf to saturate the wireless link. When we
create the monitor mode interface on the sender client the throughput
drops to 25Mbps from 29Mbps. The throughout is not affected if the
monitor mode interface is created on the receiver client through. we
have
Hi Antonio,
the
ath9k_htc maintainer said
TSF sync may be an issue if we have IBSS interface coexistence, any
thoughts about this (or)
this should be fine based on your testing. please let me know!
Well, during my test I didn't hit any problem, but since the ath9k_htc
maintainer has
On Tue, Aug 21, 2012 at 4:04 PM, Ming Lei ming@canonical.com wrote:
It is not necessary to hold the firmware memory during the whole
driver lifetime, and obviously it does waste memory. Suppose there
are 4 ath9k-htc usb dongles working, kernel has to consume about
4*50KBytes RAM to cache
monitor interface is a virtual interface. So, two interfaces are taking the
same physical resource and there is a context switch while going back and
forth !
This will decrease the throughput as the actual interface is getting less
time to sense the channel.
Thats what I think !
-
Abhinav Narain
So, why the monitor interface has no effect on the receiver client? What
you mentioned should be true on the receiving side as well.
Thanks,
Ali
On 9/4/2012 9:21 AM, abhinav narain wrote:
monitor interface is a virtual interface. So, two interfaces are
taking the same physical resource and
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
There is a possibility that AR_MCI_GPM_1 register can
return 0xdeadbeef and this results in caching of invalid
GPM index in ar9003_mci_is_gpm_valid. Ensure we
have appropriate checks to avoid this.
Cc: xijin luo xi...@qca.qualcomm.com
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
Its more correct to convert btcoex_period to 'us' while
comparing with btcoex_no_stomp which is in 'us'.
Did not find any functionality issues being fixed,
as the generic hardware timer triggers are usually
refreshed with the newer duty
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
Additionally it has a neat debug message informing us
that we are stopping the ANI algorithm.
Signed-off-by: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c |2 +-
1 files changed, 1
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
Signed-off-by: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ath9k.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
*Remove all the checks that will be handled by cfg80211
based on the interface combination advertised. For instance,
driver supports at the maximum 8 beaconing interface, while
we advertise maximum 8 beaconing interface in the interface
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
Signed-off-by: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
Enable BTCOEX for WB193(which seems to be the only supported
ath9k_htc BTCOEX chipset)only when it is enabled via modparam,
rather than enabling it by default.
Cc: Vivek Natarajan natar...@qualcomm.com
Signed-off-by: Mohammed Shafi
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
Before disabling BTCOEX in the h/w cancel all BTCOEX related
works. This is similar to the commit in ath9k(c32cdbd8)
ath9k: Stop the BTCOEX timers before disabling BTCOEX
Signed-off-by: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
14 matches
Mail list logo
