On Wed, 2014-05-07 at 14:38 +0200, Johannes Berg wrote: > On Wed, 2014-05-07 at 15:20 +0300, Luca Coelho wrote: > > On Wed, 2014-05-07 at 14:13 +0200, Johannes Berg wrote: > > > On Wed, 2014-05-07 at 15:08 +0300, Luca Coelho wrote: > > > > > > > I was thinking about the case where you you need to involve 3 contexts. > > > > Let's say you have 2 vifs in the same context and after the switch you > > > > need to split them into 2 new ones (for instance, if there is some > > > > incompatibility in the new chandefs). > > > > > > > > With the generic transactions you could do: > > > > - new chanctx2 > > > > - new chanctx3 > > > > - switch vif1 chanctx1->chanctx2 > > > > - switch vif2 chanctx1->chanctx3 > > > > - del chanctx1 > > > > > > This isn't an interesting case, because it means you have a spare, so > > > you might as well do > > > > > > new chanctx3 > > > switch vif2 chanctx1->chanctx3 > > > switch_transaction(chanctx1, chanctx2, vif1) > > > > Couldn't this potentially break the combinations temporarily again? > > I don't see why? You had a spare channel context to start with, > otherwise you'd never have accepted this situation. Therefore, you can > use the spare one before actually doing the proposed > switch_vif_chanctx(). It's not about the spare, it's about having this temporarily: chanctx3-vif2 chanctx1-vif1 Can we be sure that chanctx1 with vif1 is compatible with chanctx3 with vif2? We only check chanctx2 with vif1 and chanctx3 with vif2, which is our final goal. I'm not sure this is even possible, but it was something like this I had in mind. -- Luca. > > Ultimately, what I'm trying to say is that instead of the proposed > switch_vif_chanctx(), we need to have this: > > enum ieee80211_chanctx_switch_mode - as before > > (*switch_vif_chanctx)(struct ieee80211_hw *hw, > struct ieee80211_vif **vifs, int n_vifs, > struct ieee80211_chanctx_conf *old_ctx, > struct ieee80211_chanctx_conf *new_ctx, > enum ieee80211_chanctx_switch_mode mode); > > > 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
