On Thu, Feb 28, 2013 at 12:47 PM, Adrian Chadd wrote:
>
> The MAC looks a lot like the 11n series chips from a programming
> perspective but with some key differences (eg keycache handling, some
> of the offload processing.) I'm sure the hardware could be coaxed into
> doing the multi-STA operati
From: Ben Greear
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath9k/debug.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index daae4d0..67a2a4b 100644
--- a/drivers/net/wirele
From: Ben Greear
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath9k/debug.c |3 +++
drivers/net/wireless/ath/ath9k/debug.h |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
ind
Hi Ben,
>
>> Any idea how feasible it is to do per-vif tx-power in ath9k? I think
>> it would come down to putting the desired tx-power into each packet
>> (as the VIF sends it towards the driver) and then changing the power
>> as packets were transmitted in the NIC...
> No need for 'changing the
On 03/04/2013 02:42 PM, Thomas Hühn wrote:
> Hi Ben,
>>
>>> Any idea how feasible it is to do per-vif tx-power in ath9k? I think
>>> it would come down to putting the desired tx-power into each packet
>>> (as the VIF sends it towards the driver) and then changing the power
>>> as packets were tran
On 2013-03-04 11:28 PM, Ben Greear wrote:
> It seems there is some mac80211 framework for handling per VIF tx-power
> settings now, but from what I can tell, this is not supported in ath9k.
Correct.
> Any idea how feasible it is to do per-vif tx-power in ath9k? I think
> it would come down to put
It seems there is some mac80211 framework for handling per VIF tx-power
settings now, but from what I can tell, this is not supported in ath9k.
Any idea how feasible it is to do per-vif tx-power in ath9k? I think
it would come down to putting the desired tx-power into each packet
(as the VIF send
On Mon, Mar 04, 2013 at 09:25:33PM +0100, Johannes Berg wrote:
> On Mon, 2013-03-04 at 13:23 -0600, Seth Forshee wrote:
>
> > I've been looking at power save in mac80211 over the past few days with
> > an eye towards allowing multiple interface to be supported, as a result
> > of comments Johannes
On Mon, 2013-03-04 at 13:23 -0600, Seth Forshee wrote:
> I've been looking at power save in mac80211 over the past few days with
> an eye towards allowing multiple interface to be supported, as a result
> of comments Johannes made at [1]. It seems like adding driver callbacks
> for PS which are sp
On 03/04/2013 11:23 AM, Seth Forshee wrote:
> On Mon, Mar 04, 2013 at 06:54:34PM +0100, Marco Porsch wrote:
>> Configure the device for PS mode if the local mesh PS parameters
>> allow so and the driver supports it.
>>
>> Add two callbacks to ieee80211_ops for mesh powersave:
>> - mesh_ps_doze - pu
On Mon, Mar 04, 2013 at 06:54:34PM +0100, Marco Porsch wrote:
> Configure the device for PS mode if the local mesh PS parameters
> allow so and the driver supports it.
>
> Add two callbacks to ieee80211_ops for mesh powersave:
> - mesh_ps_doze - put the device to sleep now, wake up at given
> TB
Configure the device for PS mode if the local mesh PS parameters
allow so and the driver supports it.
Add two callbacks to ieee80211_ops for mesh powersave:
- mesh_ps_doze - put the device to sleep now, wake up at given
TBTT
- mesh_ps_wakeup - wake the device up now for frame RX
These ops may be
Add ath9k_ops for .mesh_ps_doze and .mesh_ps_wakeup.
React to doze/wakeup calls issued by mac80211.
Add a PS status flag PS_MAC80211_CTL to store last mesh PS
command from mac80211.
Initialize HW beacon wakeup registers.
On doze call configure the device to wakeup at the given TSF
value.
Signed-
Move the beacon handler into mesh_neighbour_update where the STA
pointer is already available. This avoids additional overhead
and simplifies the handler.
The repositioning will also benefit mesh PS which uses T_r and
the updated T_offset value.
Allow calculating T_offset from probe response frames
On Wed, 2013-02-27 at 09:06 +0100, Marco Porsch wrote:
> >> struct ieee802_11_elems;
> >> struct ieee80211_mesh_sync_ops {
> >> - void (*rx_bcn_presp)(struct ieee80211_sub_if_data *sdata,
> >> -u16 stype,
> >> -struct ieee80211_mgmt
On Monday 04 Mar 2013, Tokarenko Roman wrote:
> Hello for everyone!
>
> I have "RouterBoard433AH" device under OpenWrt OS. Also I have
> communication module "RouberBoard R52N-m" with chip atheros9220. I would
> like to know if there are some approaches to change working frequency for
> this chip.
Hello Roman,
2013/3/4 Tokarenko Roman :
> Also I have communication module "RouberBoard R52N-m" with chip atheros9220.
> I would like to know if there are some approaches to change working frequency
> for this chip. I ask it here, because I suppose that this feature is made
> within driver.
Wh
Hello for everyone!
I have "RouterBoard433AH" device under OpenWrt OS. Also I have communication
module "RouberBoard R52N-m" with chip atheros9220. I would like to know if
there are some approaches to change working frequency for this chip. I ask it
here, because I suppose that this feature is
18 matches
Mail list logo
