On Thu, 2012-06-21 at 08:21 +0200, Michal Kazior wrote: > > The reason I'm talking about this is the channel concurrency framework > > that Michal is working on, which would conflict somehow with this I > > think. > > Hmm.. we should be able to deal with it. I have a couple of ideas: > > a) treat ACS AP as a non-fixed channel IBSS (i.e. reserve a single > channel resource); once channel notifications comes in we'd drop > the behaviour > > b) trust the driver it won't do anything funny (we already trust it > with channel switch notification) > > > The a) requires more tricks to be done. Once we run out of channels to > run on we need to either: > > 1) reject it and leave it to userspace to handle (i.e. retry .start_ap > without ACS) > > 2) disable ACS implicitly and pick a channel ourselves (we'd need to > do a synthetic channel switch notification to userspace) > > 3) extend ACS to accept channel list, so we could implicitly reduce it > to channels we're already on (probably involves some nice hackery) > Seems tricky :-) > The b) seems to have an issue. Consider the following scenario: > > [ no channels are used, max 1 channel concurrency, max 2 APs ] > 1. wlan0: .start_ap with ACS > [ driver is starting ACS AP.. ] > 2. wlan1: .start_ap on channel 1 > [ the driver is probably locked right now > as it needs to complete (1); even if it's not locked > (1) probably can't be influenced by (2) anymore. > once it completes (1) it might end up on channel 6 on wlan0. > this means (2) fails kind of unexpectedly ] I suspect that in this case the driver would have to fail the second .start_ap though, since it's actually doing ACS at that time ... johannes -- 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
