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.
In fact, I'd argue that you shouldn't even have the
create/destroy/bind/unbind stuff listed here since that makes it more
difficult for the driver - having this whole "swap()" thing should be
easier to implement.
> 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.
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
