AR5K_INT_SWBA can't generate interruption for sending beacons

AR5K_INT_SWBA can't generate interruption for sending beacons

[cao jing]

Hi,

I'm working on mac80211 and ath5k. I found that the AR5K_INT_SWBA
interruption can't be generated. So I can't send beacons by this
interruption. Anyone knows what's going on with it?

Thank you very much!

Jing

Re: AR5K_INT_SWBA can't generate interruption for sending beacons

[Holger Schurig]

> Hi,
>
> I'm working on mac80211 and ath5k. I found that the
> AR5K_INT_SWBA interruption can't be generated. So I can't send
> beacons by this interruption. Anyone knows what's going on
> with it?
>
> Thank you very much!

ath5k didn't make it yet to wireless-testing. That is the git 
tree for all wireless stuff that finally will make it into 
mainline Linux. See http://linuxwireless.org for more detail.

I know that some people from the the OpenMoko work with ATH5K, 
but so far none of the people that work with ATH5K bothered to 
submit the driver have submitted the driver or asked for 
review/inclusion. Therefore I fear that the work development 
force isn't united, but scattered here ...


Also, because ath5k didn't make it into wireless-testing yet, you 
might not find people that know the device well enought here.

Re: AR5K_INT_SWBA can't generate interruption for sending beacons

[Holger Schurig]

Oh, I was speaking complete nonsense. I confused ath5k with 
ath6k.

Re: AR5K_INT_SWBA can't generate interruption for sending beacons

[bruno randolf]

On Tuesday 15 April 2008 10:36:55 Holger Schurig wrote:
> > I'm working on mac80211 and ath5k. I found that the
> > AR5K_INT_SWBA interruption can't be generated. So I can't send
> > beacons by this interruption. Anyone knows what's going on
> > with it?

the current code in wireless-testing uses SWBA not to send beacons but to keep 
track of the next beacon time NBTT. this is necessary to work around certain 
hardware limitations. once configured, the beacons are sent automatically by 
the hardware at the right time. of course it would be possible to change the 
code to generate a new beacon at every SWBA but as long as the beacon 
contents don't change very often i don't see the point of doing so.

> ath5k didn't make it yet to wireless-testing. That is the git
> tree for all wireless stuff that finally will make it into
> mainline Linux. See http://linuxwireless.org for more detail.

i don't know how you come to that conclusion - ath5k *is* in wireless-testing 
and there are a few people working on it.

bruno

Re: AR5K_INT_SWBA can't generate interruption for sending beacons

[Jouni Malinen]

On Tue, Apr 15, 2008 at 10:59:05AM +0200, bruno randolf wrote:
> the current code in wireless-testing uses SWBA not to send beacons but to keep 
> track of the next beacon time NBTT. this is necessary to work around certain 
> hardware limitations. once configured, the beacons are sent automatically by 
> the hardware at the right time. of course it would be possible to change the 
> code to generate a new beacon at every SWBA but as long as the beacon 
> contents don't change very often i don't see the point of doing so.

In AP mode, beacon payload changes for _every beacon_ unless you use
DTIM Period of 1. In order to make power saving work correctly, the
drivers need to update the beacon data for every beacon.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: AR5K_INT_SWBA can't generate interruption for sending beacons

[bruno randolf]

On Wednesday 16 April 2008 08:01:09 Jouni Malinen wrote:
> On Tue, Apr 15, 2008 at 10:59:05AM +0200, bruno randolf wrote:
> > the current code in wireless-testing uses SWBA not to send beacons but to
> > keep track of the next beacon time NBTT. this is necessary to work around
> > certain hardware limitations. once configured, the beacons are sent
> > automatically by the hardware at the right time. of course it would be
> > possible to change the code to generate a new beacon at every SWBA but as
> > long as the beacon contents don't change very often i don't see the point
> > of doing so.
>
> In AP mode, beacon payload changes for _every beacon_ unless you use
> DTIM Period of 1. In order to make power saving work correctly, the
> drivers need to update the beacon data for every beacon.

thats's true - i was thinking of IBSS mode first of all since AP mode is not 
supported yet by ath5k. actually also in IBSS mode the beacon contents would 
have to change for power saving, this is also not implemented yet.

bruno