On Tuesday 03 July 2012 08:47 PM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> We are doing MCI cleanup eventhough BTCOEX is not enabled
> via module parameter. This means we do ath_mci_cleanup
> though we skipped calling ath_mci_setup. Yet it does not
>
From: Mohammed Shafi Shajakhan
We are doing MCI cleanup eventhough BTCOEX is not enabled
via module parameter. This means we do ath_mci_cleanup
though we skipped calling ath_mci_setup. Yet it does not
causes any issues now as we free the DMA buffer allocated
only when it is allocated during
On Tue, Jul 3, 2012 at 6:57 PM, Ana Elisa de Campos Lobo
wrote:
> Hi all,
>
> I´m completely newbie in Linux drivers. In my project we are planning to
> connect an AR9390 Atheros chip on a GRX288 Lantiq board. This board has a
> software framework (UGW 5.2) which is based on Linux kernel 2.6.32.42
Please try compat wireless
http://linuxwireless.org/en/users/Download/
tar jxvf compat-wireless-$(date -I).tar.bz2
it will be
tar jxvf compat-wireless-2.6.tar.bz2
cd compat-wireless-2012-04-08
./scripts/driver-select ath9k
make
sudo make install
sudo make unload
sudo modprobe -v ath9k
2012/7/2
Hi Kamran,
> Is there any field set in the first or the last MPDU in an aggregated
> A-MPDU to show that it is first or the last receptively? If yes do you
> think it can be recovered in the wireshark?
based on my basic understanding, we will set more_aggregation bit cleared for
all descriptors fo
From: Mohammed Shafi Shajakhan
BTCOEX flags are set/cleared by atomic operations.
We got to do the same in ath9k_btcoex_timer_resume,
while clearing those BTCOEX flags.
Acked-by: Sujith Manoharan
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k/gpio.c |3 ++-
1
From: Mohammed Shafi Shajakhan
BTCOEX flags are set/cleared by atomic operations.
We got to do the same in ath9k_btcoex_timer_resume,
while clearing those BTCOEX flags.
Cc: Sujith Manoharan
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k/gpio.c |3 ++-
1 files
Hi,
On Thu, Jun 28, 2012 at 12:49 AM, Arvydas Sidorenko wrote:
> Commit fad29cd2f59949581050a937786c2c9bc78b2f04 broke the build if
> no CONFIG_ATH9K_BTCOEX_SUPPORT is enabled.
>
> Signed-off-by: Arvydas Sidorenko
> ---
> drivers/net/wireless/ath/ath9k/main.c | 2 ++
> 1 files changed, 2 ins
On Wednesday 27 June 2012 08:30 PM, Mohammed Shafi Shajakhan wrote:
> Hi Felix,
>
> On Wednesday 27 June 2012 08:18 PM, Felix Fietkau wrote:
>> On 2012-06-27 4:30 PM, Mohammed Shafi Shajakhan wrote:
>>> From: Mohammed Shafi Shajakhan
>>>
>>> see
Hi Felix,
On Wednesday 27 June 2012 08:18 PM, Felix Fietkau wrote:
> On 2012-06-27 4:30 PM, Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> seems i got a message like this
>> ath: phy0: BT_Status_Update: is_link=0, linkId=2,
>> s
From: Mohammed Shafi Shajakhan
ath9k_hw_mci_is_enabled wrapper also takes care of
ATH9K_HW_CAP_MCI being set for the AR9462 under test.
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k/gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a
From: Mohammed Shafi Shajakhan
seems i got a message like this
ath: phy0: BT_Status_Update: is_link=0, linkId=2,
state=1, SEQ=-2085766476 initially.
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k/mci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
From: Mohammed Shafi Shajakhan
ath9k_hw_mci_is_enabled wrapper also takes care of
ATH9K_HW_CAP_MCI being set for the AR9462 under test.
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k/gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a
Hi Johannes,
On Tuesday 26 June 2012 12:20 PM, Johannes Berg wrote:
> On Tue, 2012-06-26 at 10:54 +0530, Mohammed Shafi Shajakhan wrote:
>
>> the user pattern needs bit more stuff, we need to convert it to our chip
>> specific format(ie proper 802.11 format), previously there
Hi Sujith,
On Tuesday 26 June 2012 12:51 AM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>> +#ifdef CONFIG_PM_SLEEP
>> +
>> +void ath_wow_cleanup(struct ath_softc *sc)
>> +{
>> +struct ath9k_wow_info *wow_info =&sc->wow_info;
>> +
Hi Sujith,
On Tuesday 26 June 2012 12:14 AM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>> +static void ath9k_hw_set_powermode_wow_sleep(struct ath_hw *ah)
>> +{
>> +struct ath_common *common = ath9k_hw_common(ah);
>> +
>> +REG_SET_BIT(a
Hi Sujith,
On Monday 25 June 2012 10:54 PM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> support WoW for all chipsets starting from AR9280, AR9285, AR9287,
>> AR9380, AR9382, AR9485, AR9462. Really all hardware
Hi Sujith,
On Monday 25 June 2012 10:49 PM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> *MAC WoW registers
>>
>> back-off shift, MAC interrupt enable, magic packet enable,
>> pattern match enable, aifs
On Mon, Jun 25, 2012 at 8:00 PM, lastnoname wrote:
> Hi every body!
> In ath9k defines a tx under run interrupt:
> #define AR_ISR_TXURN 0x0800
> but what does such interrupt mean? The driver doesnt't use it, When will it
> happen? Thanks all!
tx unde-run please take a look at bool
a
From: Mohammed Shafi Shajakhan
Hardware needs to be AWAKE and should maintain association
with the AP to process WoW triggers any time
Cc: Senthil Balasubramanian
Cc: Rajkumar Manoharan
Cc: vadi...@qca.qualcomm.com
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k
From: Mohammed Shafi Shajakhan
add suspend/resume/set_wakeup callbacks to the driver
*suspend
- bail out only if all the conditions for configuring WoW.
is fine, currently multivif case is not handled
- check for associated state.
- map wow triggers from user space data.
- add deauth
From: Mohammed Shafi Shajakhan
to help the developers and users to debug/know
whats happening with WoW
Cc: Senthil Balasubramanian
Cc: Rajkumar Manoharan
Cc: vadi...@qca.qualcomm.com
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath.h |2 ++
1 files changed, 2
From: Mohammed Shafi Shajakhan
add a new file wow.c which takes care of the hardware code
for WoW.
*program the descriptors and data words to periodically
send Keep Alive Frames.
*program the user defined patterns/masks and pattern length
in the hardware registers.
*'ath9k_hw_wow_enabl
From: Mohammed Shafi Shajakhan
for AR9002 family of chipsets and for WoW sleep, we reprogram
the SerDes so that the PLL and CHK REQ are both enabled. this
uses more power but in certain cases this is required as otherwise
WoW sleep is unstable and chip may disappear.
Cc: Senthil Balasubramanian
From: Mohammed Shafi Shajakhan
currently the code supports WoW triggers due to
*magic packet
*user defined patterns
*deauth and disassoc patterns
*disconnect - beacon miss, last beacon received timeout,
no ack for keeep alive frames.
we need to support other WoW offload features in the
near
From: Mohammed Shafi Shajakhan
support WoW for all chipsets starting from AR9280, AR9285, AR9287,
AR9380, AR9382, AR9485, AR9462. Really all hardware may not support
WoW even though the flag is set and the WoW working depends on
your laptop, BIOS apart from the hardware.
Cc: Senthil
From: Mohammed Shafi Shajakhan
have seperate wow capability flags for
*basic wow support
*device capable of matching exact user defined pattern
or de-authentication/disassoc pattern
*device such AR9280 requires first four bytes for
all sort of patterns
Cc: Senthil Balasubramanian
Cc: Rajkumar
From: Mohammed Shafi Shajakhan
*add structures, macros and variables for WoW, so that the driver
can make use of it.
*maintain a list for user enabled patterns and masks
*track pattern slots for the hardware limitation on the
maximum number of patterns that can be stored.
*track interrupts
From: Mohammed Shafi Shajakhan
*MAC WoW registers
back-off shift, MAC interrupt enable, magic packet enable,
pattern match enable, aifs, slot wait period, keep alive
frame failure count, beacon fail enable, beacon timeout,
keep alive timeout, auto keep alive disable,
keep alive fail disable and
From: Mohammed Shafi Shajakhan
Add support for hardware WoW in ath9k. Magic-packet,
beacon loss triggers, deauth/disassoc patterns
(a special case of user pattern) are tested with
AR9485. User pattern needs a bit of investigation
on parsing to appropriate 802.11 format.
we will do more rigorous
Hi John,
please wait, will send a version v3 version for this, because of a bug
that occured while rebasing to the latest wireless testing. if you had
already applied, please let me know, i will send a proper fix for that.
thank you.
On Saturday 23 June 2012 09:29 PM, Mohammed Shafi Shajakhan
Hi John,
please wait, i will send a v3 for this. i missed something while
rebasing with the latest wireless-testing.
On Saturday 23 June 2012 09:29 PM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> add suspend/resume/set_wakeup callbacks to the driver
>
From: Mohammed Shafi Shajakhan
Hardware needs to be AWAKE and should maintain association
with the AP to process WoW triggers any time
Cc: Senthil Balasubramanian
Cc: Rajkumar Manoharan
Cc: vadi...@qca.qualcomm.com
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k
From: Mohammed Shafi Shajakhan
add suspend/resume/set_wakeup callbacks to the driver
*suspend
- bail out only if all the conditions for configuring WoW.
is fine, currently multivif case is not handled
- check for associated state.
- map wow triggers from user space data.
- add deauth
From: Mohammed Shafi Shajakhan
to help the developers and users to debug/know
whats happening with WoW
Cc: Senthil Balasubramanian
Cc: Rajkumar Manoharan
Cc: vadi...@qca.qualcomm.com
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath.h |2 ++
1 files changed, 2
From: Mohammed Shafi Shajakhan
add a new file wow.c which takes care of the hardware code
for WoW.
*program the descriptors and data words to periodically
send Keep Alive Frames.
*program the user defined patterns/masks and pattern length
in the hardware registers.
*'ath9k_hw_wow_enabl
From: Mohammed Shafi Shajakhan
for AR9002 family of chipsets and for WoW sleep, we reprogram
the SerDes so that the PLL and CHK REQ are both enabled. this
uses more power but in certain cases this is required as otherwise
WoW sleep is unstable and chip may disappear.
Cc: Senthil Balasubramanian
From: Mohammed Shafi Shajakhan
currently the code supports WoW triggers due to
*magic packet
*user defined patterns
*deauth and disassoc patterns
*disconnect - beacon miss, last beacon received timeout,
no ack for keeep alive frames.
we need to support other WoW offload features in the
near
From: Mohammed Shafi Shajakhan
support WoW for all chipsets starting from AR9280, AR9285, AR9287,
AR9380, AR9382, AR9485, AR9462. Really all hardware may not support
WoW even though the flag is set and the WoW working depends on
your laptop, BIOS apart from the hardware.
Cc: Senthil
From: Mohammed Shafi Shajakhan
have seperate wow capability flags for
*basic wow support
*device capable of matching exact user defined pattern
or de-authentication/disassoc pattern
*device such AR9280 requires first four bytes for
all sort of patterns
Cc: Senthil Balasubramanian
Cc: Rajkumar
From: Mohammed Shafi Shajakhan
*add structures, macros and variables for WoW, so that the driver
can make use of it.
*maintain a list for user enabled patterns and masks
*track pattern slots for the hardware limitation on the
maximum number of patterns that can be stored.
*track interrupts
From: Mohammed Shafi Shajakhan
*MAC WoW registers
back-off shift, MAC interrupt enable, magic packet enable,
pattern match enable, aifs, slot wait period, keep alive
frame failure count, beacon fail enable, beacon timeout,
keep alive timeout, auto keep alive disable,
keep alive fail disable and
From: Mohammed Shafi Shajakhan
Add support for hardware WoW in ath9k. Magic-packet,
beacon loss triggers, deauth/disassoc patterns
(a special case of user pattern) are tested with
AR9485. User pattern needs a bit of
investigation on parsing to appropriate 802.11 format.
we will do more rigorous
On Fri, Jun 22, 2012 at 2:45 PM, Matt Chen wrote:
> Hi Mohammed,
>
> 2012/6/20 Mohammed Shafi :
>> Hi Matt,
>>
>>> Both 0x2f and 0x2d can work fine to me of enabling
>>> wiphy_rfkill_start_polling() in gpio.c:ath_start_rfkill_poll().
>>>
>>
Hi Matt,
> Both 0x2f and 0x2d can work fine to me of enabling
> wiphy_rfkill_start_polling() in gpio.c:ath_start_rfkill_poll().
>
> 1) with 0x2f
> 0x404c address would change when press wifi button
> rfkill block : yes -> 0x0455
> rfkill block : no -> 0x0c55
> 2) with 0x2d
> 0x40
Hi Matt,
>> I do
>> 1) echo 0x402c > regidx
>> watch -n 1 regval
>> 2) echo 0x404c > regidx
>> watch -n1 regval
>>> i remember testing it in a acer laptop, it was working.
>> Both 1) and 2) shows no different in their value no matter how I press
>> the wifi button. :(
if hardrfkill is ena
Hi Raj,
On Tuesday 19 June 2012 11:20 PM, Rajkumar Manoharan wrote:
> On Tue, Jun 19, 2012 at 09:17:27PM +0530, Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> add a new file wow.c which takes care of the hardware code
>> for WoW.
> [...]
&g
Hi Julian,
>
> On Wed, Jun 20, 2012 at 1:47 AM, Mohammed Shafi Shajakhan
> wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> currently the code supports WoW triggers due to
>> *magic packet
>> *user defined patterns
>> *deauth and disassoc patte
On Tuesday 19 June 2012 10:50 PM, Rajkumar Manoharan wrote:
> On Tue, Jun 19, 2012 at 09:17:23PM +0530, Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> have seperate wow capability flags for
>> *basic wow support
>> *device capable of ma
Hi Raj,
On Tuesday 19 June 2012 11:08 PM, Rajkumar Manoharan wrote:
> On Tue, Jun 19, 2012 at 09:17:22PM +0530, Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> *add structures, macros and variables for WoW, so that the driver
>> can make use of
From: Mohammed Shafi Shajakhan
Cc: Senthil Balasubramanian
Cc: Rajkumar Manoharan
Cc: vadi...@qca.qualcomm.com
Tested-by: Mohammed Shafi Shajakhan
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k/pci.c |3 +++
1 files changed, 3 insertions(+), 0 deletions
From: Mohammed Shafi Shajakhan
add suspend/resume/set_wakeup callbacks to the driver
*suspend
- bail out only if all the conditions for configuring WoW
is fine, currently multivif case is not handled
- check for associated state
- map wow triggers from user space data
- add deauth/disassoc
From: Mohammed Shafi Shajakhan
to help the developers and users to debug/know
whats happening with WoW
Cc: Senthil Balasubramanian
Cc: Rajkumar Manoharan
Cc: vadi...@qca.qualcomm.com
Tested-by: Mohammed Shafi Shajakhan
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath
From: Mohammed Shafi Shajakhan
add a new file wow.c which takes care of the hardware code
for WoW.
*program the descriptors and data words to periodically
send Keep Alive Frames.
*program the user defined patterns/masks and pattern length
in the hardware registers.
*'ath9k_hw_wow_enabl
From: Mohammed Shafi Shajakhan
for AR9002 family of chipsets and for WoW sleep, we reprogram
the SerDes so that the PLL and CHK REQ are both enabled. this
uses more power but in certain cases this is required as otherwise
WoW sleep is unstable and chip may disappear.
Cc: Senthil Balasubramanian
From: Mohammed Shafi Shajakhan
currently the code supports WoW triggers due to
*magic packet
*user defined patterns
*deauth and disassoc patterns
*disconnect - beacon miss, last beacon received timeout,
no ack for keeep alive frames.
we need to support other WoW offload features in the
near
From: Mohammed Shafi Shajakhan
support WoW for all chipsets starting from AR9280, AR9285, AR9287,
AR9380, AR9382, AR9485, AR9462. Really all hardware may not support
WoW even though the flag is set and the WoW working depends on
your laptop, BIOS apart from the hardware.
Cc: Senthil
From: Mohammed Shafi Shajakhan
have seperate wow capability flags for
*basic wow support
*device capable of matching exact user defined pattern
or de-authentication/disassoc pattern
*device such AR9280 requires first four bytes for
all sort of patterns
Cc: Senthil Balasubramanian
Cc: Rajkumar
From: Mohammed Shafi Shajakhan
*add structures, macros and variables for WoW, so that the driver
can make use of it.
*maintain a list for user enabled patterns and masks
*track pattern slots for the hardware limitation on the
maximum number of patterns that can be stored.
*track interrupts
From: Mohammed Shafi Shajakhan
*MAC WoW registers
back-off shift, MAC interrupt enable, magic packet enable,
pattern match enable, aifs, slot wait period, keep alive
frame failure count, beacon fail enable, beacon timeout,
keep alive timeout, auto keep alive disable,
keep alive fail disable and
From: Mohammed Shafi Shajakhan
Add support for hardware WoW in ath9k. Magic-packet,
beacon loss triggers, deauth/disassoc patterns
(a special case of user pattern) are tested with
AR9485, AR9280. User pattern needs a bit of
investigation on parsing to appropriate 802.11 format.
we will do more
Hi Matt,
> I tested the latest kernel v3.5-rc3 ath9k for the Atheros [168c 0034],
> code name is Miami. I found no matter how I press the wifi button to
> enable/disable the wifi, it doesn't work to me.
> Even I found the rfkill status for this interface is not changing.
its a AR9462please poke a
Hi Raj,
On Monday 18 June 2012 01:34 PM, Rajkumar Manoharan wrote:
> On Mon, Jun 18, 2012 at 01:13:30PM +0530, Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> "ath9k: Fix softlockup in AR9485" with commit id
>> 64bc1239c790e051ff677e
From: Mohammed Shafi Shajakhan
"ath9k: Fix softlockup in AR9485" with commit id
64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported
issue, yet its better to avoid the possible infinite loop
in ar9003_get_pll_sqsum_dvc by having a timeout as suggested
by ath9k maintai
From: Mohammed Shafi Shajakhan
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath9k/pci.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/pci.c
b/drivers/net/wireless/ath/ath9k/pci.c
index 2b7fe51..b9e67e2 100644
From: Mohammed Shafi Shajakhan
add suspend/resume/set_wakeup callbacks to the driver
*suspend
- bail out only if all the conditions for configuring WoW
is fine, currently multivif case is not handled
- check for associated state
- map wow triggers from user space data
- add deauth/disassoc
From: Mohammed Shafi Shajakhan
to help the developers and users to debug/know
whats happening with WoW
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath.h b/drivers
From: Mohammed Shafi Shajakhan
add a new file wow.c which takes care of the hardware code
for WoW.
*program the descriptors and data words to periodically
send Keep Alive Frames.
*program the user defined patterns/masks and pattern length
in the hardware registers.
*'ath9k_hw_wow_enabl
From: Mohammed Shafi Shajakhan
for AR9002 family of chipsets and for WoW sleep, we reprogram
the SerDes so that the PLL and CHK REQ are both enabled. this
uses more power but in certain cases this is required as otherwise
WoW sleep is unstable and chip may disappear.
Signed-off-by: Luis R
From: Mohammed Shafi Shajakhan
currently the code supports WoW triggers due to
*magic packet
*user defined patterns
*deauth and disassoc patterns
*disconnect - beacon miss, last beacon received timeout,
no ack for keeep alive frames.
we need to support other WoW offload features in the
near
From: Mohammed Shafi Shajakhan
support WoW for all chipsets starting from AR9280, AR9285, AR9287,
AR9380, AR9382, AR9485, AR9462. Really all hardware may not support
WoW even though the flag is set and the WoW working depends on
your laptop, BIOS apart from the hardware.
Signed-off-by: Luis R
From: Mohammed Shafi Shajakhan
have seperate wow capability flags for
*basic wow support
*device capable of matching exact user defined pattern
or de-authentication/disassoc pattern
*device such AR9280 requires first four bytes for
all sort of patterns
Signed-off-by: Luis R. Rodriguez
Signed
From: Mohammed Shafi Shajakhan
*add structures, macros and variables for WoW, so that the driver
can make use of it.
*maintain a list for user enabled patterns and masks
*track pattern slots for the hardware limitation on the
maximum number of patterns that can be stored.
*track interrupts
From: Mohammed Shafi Shajakhan
*MAC WoW registers
back-off shift, MAC interrupt enable, magic packet enable,
pattern match enable, aifs, slot wait period, keep alive
frame failure count, beacon fail enable, beacon timeout,
keep alive timeout, auto keep alive disable,
keep alive fail disable and
From: Mohammed Shafi Shajakhan
Add support for hardware WoW in ath9k. Magic-packet,
beacon loss triggers are tested with AR9485, AR9280.
Hardware code was cleaned up addressing Rajkumar's
comments. User pattern needs a bit of investigation
on parsing to appropriate 802.11 format,
fe
Hi,
On Wed, Jun 13, 2012 at 1:14 AM, John W. Linville
wrote:
> Do you have a version that applies to 3.5 and earlier?
the back ported version of this patch
http://www.spinics.net/lists/linux-wireless/msg92125.html
>
> On Tue, Jun 12, 2012 at 08:13:43PM +0530, Mohammed Shafi Shajak
On Thu, Jun 14, 2012 at 1:42 AM, Holger Schurig
wrote:
> This is intentional.
>
> Install "iw" and use that instead.
please look into http://linuxwireless.org/en/users/Documentation/iw
--
thanks,
shafi
___
ath9k-devel mailing list
ath9k-devel@lists.at
Hi Sujith,
On Wednesday 13 June 2012 09:36 PM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> Please note this is the backported version for the linux
>> stable tree, while the patch for wireless-testing tree
&g
From: Mohammed Shafi Shajakhan
Please note this is the backported version for the linux
stable tree, while the patch for wireless-testing tree
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/92608
steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager
Hi John,
On Wednesday 13 June 2012 01:14 AM, John W. Linville wrote:
> Do you have a version that applies to 3.5 and earlier?
thanks, will soon send a back ported version for 3.5. thanks.
>
> On Tue, Jun 12, 2012 at 08:13:43PM +0530, Mohammed Shafi Shajakhan wrote:
>> From:
From: Mohammed Shafi Shajakhan
steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up
Call Trace:
[] ? ath_hw_check+0xe0/0xe0 [ath9k]
[] __const_udelay+0x28/0x30
[] ar9003_get_pll_sqsum_dvc+0x4a
Hi Sujith,
On Friday 08 June 2012 05:46 PM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>>> HZ can be configured to a user-defined value, so we need to make sure
>>> that the timing for the PLL work is what we want.
>>
>> ok, then we will change it.
On Thu, Jun 7, 2012 at 3:04 PM, Tvrtko Ursulin
wrote:
> On Tuesday 29 May 2012 13:12:33 Sujith Manoharan wrote:
>> > 118.779362 - 118.795238 (WARN_ON WARNING: at
>> > drivers/net/wireless/ath/ath9k/recv.c:531 ath_stoprecv+0x118/0x130
>> > [ath9k]())
>> >
>> > 524.162432 - 524.753750
>> > 1544.6106
From: Mohammed Shafi Shajakhan
'cfg80211: fix interface combinations' ensures that if an interface
type is not advertised by the driver in any of the interface combinations
(via ieee80211_iface_combination) then it shall be treated as a single
incompatible interface. if there are mor
From: Mohammed Shafi Shajakhan
this patch is dependent on the patch "cfg80211: fix interface
combinations"
In ath9k currently we have ADHOC interface as a single incompatible
interface. when drv_add_interface is called during resume we got to
consider number of vifs already present i
Hi Johannes,
> You could just remove the entire check since the interface combinations
> you advertise don't allow it, I think? Or just fix those
> combinations :-)
i did not check this before, thanks a lot for your inputs. will send a
proper v2 after checking this out.
On Friday 01 June 2012 12:43 PM, Johannes Berg wrote:
> On Fri, 2012-06-01 at 12:39 +0530, Mohammed Shafi Shajakhan wrote:
>> Hi Johannes,
>>
>> On Friday 01 June 2012 12:14 PM, Johannes Berg wrote:
>>> On Fri, 2012-06-01 at 12:09 +0530, Mohammed Shafi Shajakhan wr
On Fri, Jun 1, 2012 at 2:41 PM, Sujith Manoharan
wrote:
> Sujith Manoharan wrote:
>> Why is all this required ? And anyway, the patch that you have given
>> doesn't contain any of the debugfs code...
>
> Bleh, it does contain the debugfs variable.
>
:) :) i have not tested it, sometime back but s
Hi Johannes,
On Friday 01 June 2012 12:14 PM, Johannes Berg wrote:
> On Fri, 2012-06-01 at 12:09 +0530, Mohammed Shafi Shajakhan wrote:
>> From: Mohammed Shafi Shajakhan
>>
>> In ath9k we make sure the following two things
>> *if the first interface is ADHOC we cann
From: Mohammed Shafi Shajakhan
In ath9k we make sure the following two things
*if the first interface is ADHOC we cannot have any other interface.
*we cannot add an ADHOC interface if there is already an interface
is present.
when drv_add_interface is called during resume we got to consider
On Thu, May 31, 2012 at 7:28 PM, Yashashree Jadhav
wrote:
> Hello Everyone,
>
> Can any one provide "patch file to disable ath9k rate control"
>
> "patch to fix MCS rate in ath9k "
pls find the attached (courtesy: Raj) pls backport for the fixed MCS
stuff if needed as its some what old.
>
>
> T
check in something like
/sys/kernel/debug/ieee80211/phy0/netdev:wlan0
> Kamran
>
>
> On Mon, May 28, 2012 at 8:40 PM, Mohammed Shafi
> wrote:
>>
>> On Mon, May 28, 2012 at 7:53 PM, Sujith Manoharan
>> wrote:
>> > Mohammed Shafi wrote:
>> >> Hi
> Chipset is AR9331. Thanks for the link. Shall try the same.
please also try with the latest patches posted for AR933X
http://www.spinics.net/lists/linux-wireless/msg90837.html
--
thanks,
shafi
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
On Thursday 31 May 2012 11:11 AM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>> should we check if (work_pending(&sc->hw_reset_work)) like we do in
>> ath_beacon_tasklet in all the other work routine that access hardware
>> registers in case the hw
Hi Sujith,
On Thursday 31 May 2012 08:14 AM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>> before the STA is associated PLL4(0x1618c) always seem to dump
>> zero, which causes a softlockup as we keep on polling infinitely
>> PLL4's 8th bit. Once PLL4
Hi Adrian,
On Thursday 31 May 2012 12:18 AM, Adrian Chadd wrote:
> (Yes, this is a public response.)
>
> Hi,
>
> That has me a bit concerned. Waiting for the STA to be associated is
> really just some kind of "settling" delay. You're still TX/RXing at
> that point.
yeah, but i am pretty sure in t
From: Mohammed Shafi Shajakhan
steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up
Call Trace:
[] ? ath_hw_check+0xe0/0xe0 [ath9k]
[] __const_udelay+0x28/0x30
[] ar9003_get_pll_sqsum_dvc+0x4a
On Wed, May 30, 2012 at 6:41 PM, Sunil Mehta wrote:
>
> Hi,
hi,
>
> We are working on Wi-Fi device in STA mode and find that the uplink
> throughput is very poor. Whereas when the same device is configured in AP
> mode its throughput performance is as expected.
>
> The application is based on AR
.067 ms 1779/13730 (13%)
> [ 3] 3.0- 4.0 sec 15.5 MBytes 130 Mbits/sec 0.162 ms 1807/12897 (14%)
> [ 3] 4.0- 5.0 sec 18.3 MBytes 154 Mbits/sec 0.032 ms 993/14078 (7.1%)
thanks for sharing the result. its very useful!
>
> Thank you,
> Shafi.
>
>
>
> On Wed, M
On Wed, May 30, 2012 at 4:28 AM, Stratos Keranidis wrote:
> HI,
hi,
>
> I checked in the archives and found that a proper way to disable AMPDU
> aggregation is to
>
> replace these two lines in /drivers/net/wireless/ath/ath9k/init.c of
> function ath9k_init_misc()
>
> sc->sc_flags |= SC_OP_TXAGG
101 - 200 of 940 matches
Mail list logo
