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@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
