2011/1/12 Sujith <m.sujith@xxxxxxxxx>: > Björn Smedman wrote: >> 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... Thank you Sujith for the clarification. When you lay out the cases it makes more sense. But there are still border cases, like e.g. adding first a STA and then an AP interface. If I read main.c correctly the opmode will then be STA and the AP vif will be broken, right? Wouldn't it be better to keep counts of number of vifs by type and e.g. activate SWBA if (adhocvifs > 0 || apvifs > 0) and similar? Then it wouldn't mater in which order vifs are added, removed and changed. /Björn -- 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
