On Wed, 2011-11-09 at 11:54 -0800, Ben Greear wrote: > > However, it's not really going to work well for multi-channel capable > > drivers: say the driver is continually switching between channels 1 and > > 11 for multi-channel operation, but now you want to do a p2p listen > > phase on channel 6. That needs to interact with the driver since it has > > to stop switching, and it'd be much easier to have the driver manage > > that interaction. > > If mac80211 is controlling the channel switching with off-channel work > items, can't it just keep the nic on channel 6 doing the p2p listen > for the proper amount of time? Why does the driver have to make > the decision? mac80211 isn't going to be controlling the switching between 1 and 11 at all though. And there will be drivers like iwlwifi and wl12xx that want to control the "stay on channel 6" as well. > If you expect the driver might have pkts queued for multiple channels, > and that is why it would be switching, then you could just have a mac80211 > call that says 'stay on this channel (6) until I tell you otherwise'. > The driver could then stop it's automated switching. That would seem > fairly easy to implement. Yes, that's what we'll probably need. Actually we already have that in a way with the remain_on_channel, but it's not used for work/scan/etc. today, only for p2p. > Worst case, you flush all buffers and > then it should certainly stop switching? (The hard part would seem to be making the > driver able to deal with multiple xmit queues and doing automated > switching in the first place. It certainly never worked well when > ath9k tried to do something similar with virtual phys) At least for iwlwifi I expect we'd have multiple hardware queues with the uCode handling the switching. > > Thing is that this doesn't really work too well even today with a lot of > > devices we support, e.g. iwlwifi or even iwlegacy isn't really built to > > do this. You're mostly looking at it from an ath9k perspective I suppose > > where all of this is really quite simple :-) > > If you can put the scan state machine into the work logic, > the work logic will get much better testing, and hopefully > that will simplify the on-off channel logic (just having no > scan_channel to worry about would simplify on/off channel > logic that I wrote (and which was just removed). > > The only driver I have any idea about is ath9k: What does iw* do > that makes this difficult? Uh, that would be a really really long explanation so I think for now you'll just have to take my word for it. It's just the way the firmware is designed. 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
