On 7 May 2014 14:38, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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(). > > > 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); Yeah. This is another way to do it. It does solve the edge case when you're maxing out on different channels. It doesn't, however, (if you don't do transactions) prevent from chanctx overcommit (i.e. you still can end up with more, albeit "idle", chanctx allocations in driver). 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
