On 28 February 2012 07:59, Chadd, Adrian wrote:
> Hi,
>
> That's interesting. I have found the AR9280 to do the same. I hadn't gone
> digging into it though, I've been busy with other things but it was on my
> todo list. So thankyou for finding it. :-)
Well, now I've looked at it. :-)
>
> Spec
On 06/22/2012 08:42 AM, Holger Schurig wrote:
>> Is there any way to filter out frames received on other channels (so I only
>> receive frames from channel on which my AP is configured)?
>
> No, there isn't. Suppose the probe request was sent on channel 10. And
> your AP is on channel 11. Then your
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/pc
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
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath.h |2 ++
1 files changed, 2 inse
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_enable' is call
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 futu
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 Balasubraman
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 M
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 enable
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().
>>>
>>> 1) with 0x2f
>>> 0x404c address would change when pres
On 23 June 2012 00:42, Peter Stuge wrote:
> Pannir wrote:
>> Why is it happening on some boards and not others? Why is AR9382
>> more forgiving than AR9280?
>
> Silicon bugs fixed or different code path in the driver with bugs
> fixed or both.. Noone can answer, if they could I know that the
> dri
Pannir wrote:
> Why is it happening on some boards and not others? Why is AR9382
> more forgiving than AR9280?
Silicon bugs fixed or different code path in the driver with bugs
fixed or both.. Noone can answer, if they could I know that the
driver bugs would be fixed already.
//Peter
___
16 matches
Mail list logo
