On 7 May 2014 14:53, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> On Wed, 2014-05-07 at 14:44 +0200, Michal Kazior wrote:
>
>> > 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.
>
> I thought this was what you were proposing :)
I think Luca and I have something like this in mind:
drv_chanctx_update(hw,
{ .type = CHANCTX_NEW_CHANCTX,
.chanctx = ctx2,
},
{
.type = CHANCTX_BIND,
.vif = vif1,
.chanctx_old = ctx1,
.chanctx_new = ctx2,
},
{ 0 });
The driver would be free to re-order this internally to fulfill the
entire update request.
>> 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).
>
> That I don't understand again - what do you mean by "chanctx
> allocations"?
Chanctx lifecycle is:
drv_add_chanctx()
drv_assign_vif_chanctx()
// .. more assign/unassign .. possibly drv_change_chanctx()
drv_unassign_vif_chanctx()
drv_remove_chanctx()
What I meant by "chanctx allocations" is drv_add_chanctx.
In particular when I write "chanctx overcommit" I refer to
drv_add_chanctx() being called when in-driver chanctx count is already
at peak for given interface combinations.
Or should we just simply assume this isn't a problem and drivers
should *always* accept empty chanctx? Why bother with a return value
then?
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
