Re: [RFC] ath9k: Handle interface changes properly

[Rajkumar Manoharan <rmanoharan@atheros.com>]

On Wed, Jan 12, 2011 at 10:52:23PM +0530, Sujith wrote:
> Björn Smedman wrote:
> > On Wed, Jan 12, 2011 at 3:30 PM, Rajkumar Manoharan
> > <rmanoharan@atheros.com> wrote:
> > > The commit ""ath9k: Add change_interface callback" was failed
> > > to update of hw opmode, ani and interrupt mask. This leads
> > > to break p2p functionality on ath9k. And the existing add and
> > > remove interface functions are not handling hw opmode and
> > > ANI properly.
> > >
> > > This patch combines the common code in interface callbacks
> > > and also takes care of multi-vif cases.
> > 
> > How does your patch handle the race condition between the interface
> > change done in process context and the beacon tasklet triggered by
> > SWBA?
> > 
> > Also, perhaps more applicable to the commit log than the patch, how
> > can opmode be properly handled in multi-vif cases? I mean let's say I
> > have two AP vifs and then change one into STA, is the opmode then STA?
> > Compare that to the case where I have two STA vifs and change one into
> > AP; so again I have one AP and one STA vif but this time opmode is AP,
> > right? I can see how I can be wrong about these examples but I can't
> > really see how the opmode concept can be properly handled in multi-vif
> > cases.
> 
> The opmode should be calculated every time an interface is created/destroyed.
> 
> If an AP vif is already present when a STA is added, the opmode remains as AP.
> if a STA vif is changed into AP mode, then the opmode should be changed to AP,
> along with disabling PS for other STA interfaces.
> If an AP is present and a STA is added, the beacon interval can't be different.
> And there are a few other conditions as well...
> 
> And you are right, interface management is not protected with the beacon tasklet...
I dont see a race condition here because SWBA & beacon tasklet is disabled
before accessing beacon slot.

--
Rajkumar