On Saturday, January 26, 2013 12:16:13 AM Johannes Berg wrote: > On Thu, 2013-01-10 at 10:43 +0200, Vladimir Kondratiev wrote: > > Hi, > > > > There are 2 similar operations in the struct cfg80211_ops: > > remain_on_channel() and mgmt_tx(). Actually, mgmt_tx() when called for > > off-channel operation, is the same as remain_on_channel() except it > > transmits frame at the beginning. > > > > What I am interesting about, is notifications to cfg80211. For > > remain_on_channel(), there are 2: cfg80211_ready_on_channel() when > > channel tuned, and cfg80211_remain_on_channel_expired() when tuned off > > requested channel. In contrast, if mgmt_tx() called for off-channel > > with duration, 2 above notifications are not used. Instead, only > > cfg80211_mgmt_tx_status() called after tx. > > > > My question is why don't mgmt_tx() call cfg80211_ready_on_channel() and > > cfg80211_remain_on_channel_expired() ? It seems logical to notify about > > off-channel status. Otherwise, how can upper layers know when off-channel > > started/finished in context of mgmt_tx()? > > If all they care about is transmitting a frame, why would they want to > know? > > johannes > My understanding is that mgmt_tx() with delay intended for the flows when one expect to rx some frame(s) solicited by original tx. Ex: active scan - one tx probe and waits for probe resp on the same channel; other example may be GO negotiation. So, actually tx_mgmt() is like remain_on_channel() but with initial tx. That's why it is strange to see different notification policy. For practical example, let's see fragmented scan while connected - upper layers issue mgmt_tx() for probe with delay about 10 ms; and use start/end offchannel notification to pause/resume tx. Currently, one can't do this; and need to call remain_on_channel() following mgmt_tx() upon receiving cfg80211_ready_on_channel notification. -- 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
