On 22 January 2014 13:36, Luca Coelho <luca@xxxxxxxxx> wrote: > On Wed, 2014-01-22 at 11:19 +0100, Johannes Berg wrote: >> On Wed, 2014-01-22 at 11:13 +0100, Michal Kazior wrote: [...] >> > What about cfg80211 intf combinations? If GO sends a channel switch it >> > will fail on num_available_channels unless you implicitly consider the >> > userspace event you mentioned or export CSA state down to cfg80211. >> >> Yeah, that's a good point, need to consider that. > > Very good point. I hadn't thought about it. When mac80211 decides to > change channel to an existing context, it needs to know whether the > combination will be valid or not. > > >> > At one point I was wondering if channel contexts should be actually >> > exposed in cfg80211. It would probably make it easier to coordinate >> > some CSA scenarios like this in a sane way, don't you think? But then >> > again that's quite big of a change. >> >> Yeah that'd be a bit of a change, but maybe it's worth it? Not sure. > > That's probably going to be necessary. How would mac80211 be able to > know if the future combination would be possible or not? I thought about > asking cfg80211 if the combination would be okay when reserving a > context, but that wouldn't work if we have >= 2 reservations. cfg80211 > needs to know about the reservations as well. :( You could probably get away without exposing channel contexts to cfg80211 as long as you at least provide some level of channel switching state back to cfg80211. You could have a 'channel switch state' which says a channel X will become channel Y for A,B,C.. interfaces "soon". mac80211 (or any cfg80211-based driver for that matter) could tell cfg80211 "the switch is complete" (and possibly a status code to indicate failure). This way cfg80211 would be the one to stop/disconnect interfaces that were on channel X but weren't included in a given channel switch to channel Y. I think this should work with >= 2 reservations including error handling (i.e. failing in the middle). What bothers me here is locking. You can't just use wdev->mtx -- you need a more global lock for protecting this sort of thing. Since the reservation would be accessible from userspace (even implicitly via some existing nl80211 commands) and from cfg80211-based (i.e. mac80211) it might be tricky? But I suppose having channel contexts in cfg80211 would involve this predicament as well. Also currently cfg80211 is oblivious to HT40+/HT40- and It doesn't consider HT40+ @ chan6 and HT40- @ chan6 as different channels, right? Michał -- 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
