Emmanuel Grumbach wrote: > I still think it does not match the original intent of mgd_prepare_tx(). > The way I see it, mgd_prepare_tx() ensures that the Tx *will* happen > in cases the driver has no specific reason to be on channel, mainly > because the context is not associated yet. Note that after association > mac80211 does not interfere with the context switches. The driver is in > charge of all this - why would it be different in this case? > flush() makes sure that the Tx *has* happened before destroying things. > The context switches from association until destruction are under the driver's > responsibility. > > At least this is the way I see it. > We (Intel) will not break if you add this call, but in my eyes this does not > comply with the design. I guess you can always send a patch to add it and > see what others will say, but Johannes is away right now. > If you choose to do that, please add a reason as a parameter to > mgd_prepare_tx() > so that we can ignore it when it is called before sending a frame that > is flush()'ed. > I still prefer to rely on flush(). And I agree that flush() isn't a > trivial implementation.
I can see your point and agree that the original intention of the mgd_prepare_tx() callback is as described in the documentation. But with multiple active contexts, flush() becomes a big hammer rather than a simple emptying of the queues. :-) I think we can extend the intention of the API and use mgd_prepare_tx() for deauth/disassoc too. And this was done in the original patch, anyway. This would greatly reduce driver complexity. I'll send a patch including your suggestion about adding a parameter to mgd_prepare_tx() which iwlwifi can use. Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
