kernel/git/stable/linux.git/net/mac80211/offchannel.c, branch linux-3.6.y

mac80211: fix remain-on-channel (non-)cancelling

2012-12-10T19:13:11+00:00

commit 6bdd253f635f7b2ef027d116933a6c9ec148b87f upstream. Felix Liao reported that when an interface is set DOWN while another interface is executing a ROC, the warning in ieee80211_start_next_roc() (about the first item on the list having started already) triggers. This is because ieee80211_roc_purge() calls it even if it never actually changed the list of ROC items. To fix this, simply remove the function call. If it is needed then it will be done by the ieee80211_sw_roc_work() function when the ROC item that is being removed while active is cleaned up. Reported-by: Felix Liao Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mac80211: fix use after free

2012-07-13T14:15:54+00:00

roc is destroyed then roc->started is referenced. Keep a local cache. Signed-off-by: Alan Cox Signed-off-by: Johannes Berg

cfg80211: use wdev in mgmt-tx/ROC APIs

2012-07-09T12:51:47+00:00

The management frame and remain-on-channel APIs will be needed in the P2P device abstraction, so move them over to the new wdev-based APIs. Userspace can still use both the interface index and wdev identifier for them so it's backward compatible, but for the P2P Device wdev it will be able to use the wdev identifier only. Signed-off-by: Johannes Berg

mac80211: rename driver-trace file

2012-06-24T09:32:38+00:00

This file will contain more soon, so rename it to just trace. Signed-off-by: Johannes Berg

mac80211: fix double-start of remain-on-channel

2012-06-20T18:12:12+00:00

When a remain-on-channel item is deleted, we remove it from the list and then start the next item. However, if it wasn't actually the first item then calling ieee80211_start_next_roc() is wrong as it will start the first item -- even if that was already started. Fix the two places that do this and add a warning to prevent the problem from reoccurring. Reported-by: Eliad Peller Signed-off-by: Johannes Berg

mac80211: cleanup offchannel_ps_enable argument

2012-06-20T08:53:34+00:00

The 'tell_ap' argument is always true. So that remove it and simplify the function. Signed-off-by: Rajkumar Manoharan Signed-off-by: Johannes Berg

mac80211: remove unneeded ieee80211_run_deferred_scan()

2012-06-11T15:01:17+00:00

Ilan pointed out to me that ieee80211_start_next_roc() already calls ieee80211_run_deferred_scan() if the list of ROC items is empty, so there's no need to call it again after calling ieee80211_start_next_roc(). Reported-by: Ilan Peer Signed-off-by: Johannes Berg

mac80211: unify SW/offload remain-on-channel

2012-06-06T19:31:18+00:00

Redesign all the off-channel code, getting rid of the generic off-channel work concept, replacing it with a simple remain-on-channel list. This fixes a number of small issues with the ROC implementation: * offloaded remain-on-channel couldn't be queued, now we can queue it as well, if needed * in iwlwifi (the only user) offloaded ROC is mutually exclusive with scanning, use the new queue to handle that case -- I expect that it will later depend on a HW flag The bigger issue though is that there's a bad bug in the current implementation: if we get a mgmt TX request while HW roc is active, and this new request has a wait time, we actually schedule a software ROC instead since we can't guarantee the existing offloaded ROC will still be that long. To fix this, the queuing mechanism was needed. The queuing mechanism for offloaded ROC isn't yet optimal, ideally we should add API to have the HW extend the ROC if needed. We could add that later but for now use a software implementation. Overall, this unifies the behaviour between the offloaded and software-implemented case as much as possible. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: do remain-on-channel while idle

2012-06-06T19:20:33+00:00

The IDLE handling in HW off-channel is broken right now since we turn off IDLE only when the off-channel period already started. Therefore, all drivers that use it today (only iwlwifi!) must support off-channel while idle, so playing with idle isn't needed at all. Off-channel in general, since it's no longer used for authentication/association, shouldn't affect PS, so also remove that logic. Also document a small caveat for reporting TX status from off-channel frames in HW remain-on-channel. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: clean up remain-on-channel on interface stop

2012-06-04T19:25:26+00:00

When any interface goes down, it could be the one that we were doing a remain-on-channel with. We therefore need to cancel the remain-on-channel and flush the related work structs so they don't run after the interface has been removed or even destroyed. It's also possible in this case that an off-channel SKB was never transmitted, so free it if this is the case. Note that this can also happen if the driver finishes the off-channel period without ever starting it. Cc: stable@kernel.org Reported-by: Nirav Shah Signed-off-by: Johannes Berg Signed-off-by: John W. Linville