Add support for extended command id in notification system.
Extended command id header contains group id in addition to command id.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Since the time-event is sent with the immediate flag set, there is
no need to sample the device time.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In the mvm driver, neither the old command nor the return value
are used, so remove them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

As pointed out by smatch, there's no need for a loop that always
immediately terminates. Use an if statement instead and while at
it clean up the mvmvif initialization.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

commit b112889c ("iwlwifi: mvm: add Aux ROC request/response flow")
added aux ROC flow in addition to the existing ROC flow. While doing
it, it moved the ROC reference release to a common work item, which
is being called for both the ROC and aux ROC flows.

This resulted in invalid reference accounting, as no reference was
taken in case of aux ROC, while a reference was released on completion.

Fix it by adding a reference for the aux ROC as well, and release
only the relevant references on completion (according to the set bits).

While at it, convert cancel_work_sync() to flush_work(), in order
to make sure the references are being cleaned properly.

Fixes: b112889c ("iwlwifi: mvm: add Aux ROC request/response flow")
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The only other way to catch these would have been to monitor
the Tx deauth event, but we can send a deauth when we roam.
So it would have been tricky to make sure we capture the
connection losses only.
Define a separate trigger for the connection losses to make
it easier to catch them.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This will allow to collect data when a time event
notifcation with a certain id and action is coming from
the firmware. This can be very useful to debug various
flows.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Fix spelling error across the driver.
Modified only comments and prints.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This warning is misleading. In many cases, for example P2P ROC time
events, this will happen if the time event is aborted, for example
due to a higher priority time event. This is entirely normal and not
worth warning about.

In other cases, where we actually do act upon this, for example when
trying to connect and this fails, we should instead warn as part of
the disconnect operation.

Change the code to do that, i.e. make the warning a debug message,
and make it more prominent (an error) when we actually disconnect
because of it.

This also fixes confusion in the logs - the warning was mistaken for
something that needed investigation, while in most cases it's just
expected behaviour that occasionally some lower-priority time events
would not complete fully.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If, on a GO, the CSA time event fails to be scheduled, continue the
flow towards mac80211's state machine so it doesn't get stuck, but
report an error later on the post switch which will cause mac80211
to tear down the operation. This ensures nothing gets stuck due to
the scheduling failure.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The code here is a little confusing, the iwl_mvm_te_check_disconnect()
will check that the interface is a station, but going into it after
already having processed the time even end for P2P seems strange at
first look.

Put a switch statement there to distinguish the interface types and
make this more readable.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If this situation ever happens, the mac80211 state machine gets
confused because it never clears csa_active. There was a separate
bug that lead to this happening with a working connection, but it
isn't very robust to try to keep the connection up in this case.

When removing the time event the CSA essentially procedure stops,
so the safest thing to do is to disconnect in this case.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

iwl_mvm_stop_roc removes TE only if running flag is set. This is not correct
since this flag is only set when the TE is started.
This resulted in a TE not being removed, when mac80211 believes that there are
no active ROCs.

Fixes: bf5da87f ("iwlwifi: mvm: add remove flow for AUX ROC time events")
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If setting the CSA time event fails, we must clear the TE data,
otherwise we'll try to remove it when, for instance, a disconnection
occurs, causing a SYSASSERT.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>

We need to call ieee80211_chswitch_done() ourselves just when the
absence TE started, so we perform the actual context switch early
enough.  To do so, add a dummy channel_switch op, which will cause
mac80211 to skip the countdown timer and allow us to call
ieee80211_chswitch_done() to complete the operation.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>

Add an absent time event when pre_channel_switch is called and use the
time event started indication to set the disable_tx bit instead of
doing it in unassign_vif().  This is done so that the firmware queues
are stopped before the actual switch takes place to avoid losing
packets while the AP/GO is performing its actual switch.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>

Add a flow that handles the requests to cancel the roc time event,
that has been triggered via the aux framework.

The roc for bss is different than the roc for p2p devices, and  is done
via the aux framework using the aux queue, thus requires a different flow
to cancel the time event.
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Don't add the time event to the list. We added it several
times the same time event, which leads to an infinite loop
when walking the list.

Since we (currently) don't support more than one ROC for STA
vif at a time, enforce this and don't add the time event
to any list.

We were also missing the locking of the mutex which led to
a lockdep splat - fix that.
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The time event used for CSA GO will also be used by CSA client.
Rename the symbols to something more generic and aligned with the
firmware code.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Our legal structure changed at some point (see wikipedia), but
we forgot to immediately switch over to the new copyright
notice.

For files that we have modified in the time since the change,
add the proper copyright notice now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Make sure that when running the TDLS discovery session
protection - the time event that ensures we remain on channel
has been scheduled and started running before leaving.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The Remain On Channel framework added to the firmare is
a bit like time events. It allows the driver to request
the firmware to be on a certain channel for a certain time.
Unlike the time events, the ROC infrastructure doesn't need
a MAC context in the firmware - it uses a generic context
called "auxiliary framework".

This is useful for any offchannel activity that is not bound
to a specific MAC.
The flow is synchronized much like with time events:
1) The driver receives an action frame from the wpa_supplicant
   via nl80211 that requests to be sent offchannel.
2) The driver sends an Aux ROC command (0x53) to the firmware.
3) The firmware responds with the unique id of the time event.
4) When time event starts, the driver puts the frame in the
   Aux queue.

Special care needs to be taken when the time events ends:
the queue needs to be cleaned-up.
Signed-off-by: NAriej Marjieh <ariej.marjieh@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

According to the spec, GO/AP should perform the channel switch just
before "beacon 0". However, since the exact timing isn't defined,
it may result in a sudden GO disappearance from the channel.
Prevent potential packet loss when performing the CS by scheduling
NoA time event and executing the channel switch flow when a notification
from fw is received.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

CMD_SYNC is really 0 which is confusing:

if (cmd.flags & CMD_SYNC) is always false.
Fix this by simply removing its definition.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

All the supported firmwares have this flag set.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Newer firmware support a new bit in the policy  that allows
to request to apply the time event immediately. Add this bit
without removing the workarounds we used until now to support
older firmares.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Take a reference when ROC command is started, and
unref it on completion.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add an inline helper function for getting an RX packet's
length or payload length and use it throughout the code
(most of which I did using an spatch.)

While at it, adjust some code, and remove a bogus comment
from the dvm calibration code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Happy new year!
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Time event notification can have a failure status even if
the time event was scheduled:
* in START notification, this can happen if the time event
  was scheduled later than the requested apply time.
* in STOP notification, this can happen if the time event
  is truncated.

Even if both happened, the offchannel packets sent during
the remain on channel are very likely to have been sent.
Hence, don't WARN when this happens, but rather print a
discrete line in the kernel log.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>

When firmware restart happens, the timers are obviously reset and
the new firmware has no synchronisation with the AP as we program
timings to the pre-restart values. The firmware should attempt to
synchronise by itself, but in multi-channel scenarios this isn't
easy, particularly since it has to try to keep service quality up
for other MACs.

To make it more reliable, give each client MAC some time to catch
beacons when restarting or resuming. Service quality was impacted
anyway (or in resume doesn't really matter much.)
Reviewed-by: NMoshe Island <moshe.island@intel.com>
Reviewed-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Correct spelling typo in printk
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The time event firmware API will change, add the support for that.
Use the new API throughout and convert to the old where needed.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: NGuy Cohen <guy.cohen@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A few places in the code (mac80211 and iwlmvm) use the same
TU_TO_JIFFIES() macro and could use TU_TO_EXP_TIME() that
mac80211 has. Make these available to everyone and use them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If scheduling an important time event fails, or if we get
an unexpected notification from the firmware, there isn't
much we can do to recover, so just drop the connection and
let higher layers retry it.
Reviewed-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The firmware API changed to differentiate between event and
fragment start/end. Change the time-event handling accordingly.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Schedule different time event based on the ROC type
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

7000.c was released as GPL only by mistake: it should be
dual licensed - GPL / BSD.
The file that contains the license in the kernel is COPYING
and not LICENSE.GPL.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Occasionally, we would run into this warning:

  iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left
  iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601
  iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9
  iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9
  iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601
  iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1
  wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3)
  ------------[ cut here ]------------
  WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]()
  Modules linked in: [...]
  Call Trace:
   [<c1046e42>] warn_slowpath_common+0x72/0xa0
   [<c1046e92>] warn_slowpath_null+0x22/0x30
   [<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]
   [<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm]
   [<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm]
   [<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211]

The reason is a problem with asynchronous vs. synchronous
commands, what happens here is the following:
 * TE 0x2601 is removed, the TIME_EVENT_CMD for that is async
 * a new TE (will be 0x2701) is created, the TIME_EVENT_CMD
   for that is sync and also uses a notification wait for the
   response (to avoid another race condition)
 * the response for the TE 0x2601 removal comes from the
   firmware, and is handled by the notification wait handler
   that's really waiting for the second response, but can't
   tell the difference, we therefore see the message
   "TIME_EVENT_CMD response - UID = 0x2601" instead of
   "TIME_EVENT_CMD response - UID = 0x2701".

Fix this issue by making the TE removal synchronous as well,
this means that we wait for the response to that command
first, before there's any chance of sending a new one.

Also, to detect such issues more easily in the future, add
a warning to the notification handler that detects them.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>