On 8 May 2014 12:06, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> On Wed, 2014-05-07 at 15:03 +0200, Michal Kazior wrote:
>
>> 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.
>
> Yeah, that's just a little complex maybe? And we don't really allow
> *arbitrary* transactions, so we'd have to impose limits on the
> transactions etc.
Yeah. I also get the feeling it's overly complex.
>> 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?
>
> No, we shouldn't do that and assume that the driver would reject that.
Then, if you want to avoid the chanctx overcommit problem, you need to
make switch_vif_chanctx() to act as drv_add_chanctx(old_ctx) and
drv_remove_chanctx(new_ctx) implicitly, i.e.
drv_switch_vif_chanctx(hw, vifs, n_vifs, old_ctx, new_ctx, SWAP);
instead of:
drv_add_chanctx(new_ctx);
drv_switch_vif_chanctx(hw, vifs, n_vifs, old_ctx, new_ctx, SWAP);
drv_remove_chanctx(old_ctx);
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
