Some CSR registers have to be configured also
in case of suspend/resume with unified image
(which doesn't includes reconfiguration flow).
Reuse the existing d3_suspend/d3_resume trans ops,
while making sure some configurations are a bit
different, according to the wowlan type.
After this change, we no longer need the special
wowlan_d0i3 configurations done in iwl_pci_resume,
as they are already being done in the d3_resume op.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
CQM overwrites a few thresholds in the bf command. On the other hand,
when entering D0i3 the thresholds are set to higher values on purpose,
so ignore CQM in this case.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The slow filtering threshold should be higher in D0i3 case.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
TCP software implementation on the host requires extensive computing
power. Offloading even some of the TCP/IP stack to the NIC might save
a significant overhead. In order to enable this feature on our hw,
we need to configure it first. Once done, we mark this capability,
to be advertised later to the OS via ieee80211_register_hw.
The driver Rx indications for TCP Checksum is integrated within the
standard Rx status. The driver responds to those indications as follows:
If the frame was tested by hw and checksum ok report CHECKSUM_UNNECESSARY.
Otherwise, report CHECKSUM_NONE.
Signed-off-by: Avri Altman <avri.altman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The firmware debug infrastructure allows the user to
provide a firmware that will toggle a few registers to
configure the debugging capabilities.
On certain devices, certain operations are forbidden.
Executing a forbidden operation will cause the hardware to
die in a way that only driver unload / load will bring it
back to life.
Fortunately, there is a way to know in advance if those
operations will be accepted by the device. This is where
the new PRPH_BLOCKBIT operation plays its role. If the bit
X from PRPH register Y is set, then we should prevent any
further register configuration. When that happens, drop a
line in the kernel log since this is really an error state:
the user won't have his device configured as he expected.
Add operations that will be used in the future:
INDIRECT_ASSIGN, INDIRECT_SETBIT, and INDIRECT_CLEARBIT.
Other debugging configurations (such as destination
configuration for the monitor) will take place in any case.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In iwl_mvm_tx_skb_non_sta(), in case of managed interface,
use the AP station for multicast frames instead of the auxiliary
station as otherwise the frames can be sent to an absent P2P GO as
the FW does not block transmissions for the auxiliary station
since it is not associated with the station MAC context.
Note that this is not possible for unicast frames, as a TDLS
discovery response is sent without a station entry, and in this
case the P2P GO NoA should not block transmission to the peer.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Allow the transport layer to return an error upon suspend.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This reverts commit 088070a2f6.
When working in d0i3_on_idle mode, we explicitly go out
of d0i3 on resume (so other potential commands could
be sent).
However, D0I3_DEFER_WAKEUP is currently cleared on
resume complete (which happens only later on), causing
d0i3 exit to timeout.
Since mac80211 was modified to accept incoming frames
once drv_resume was called, we can safely revert this
patch, and handle the pending work on iwl_mvm_resume().
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Existing UMAC commands already use the long header, but are sent
with group 0 and the long header inserted manually. Move them to
the group 1 to take advantage of the header building in the low-
level transport.
Existing firmware ignores the group_id field (it's reserved) and
the first firmware that really supports long command headers can
parse all commands in both group 0 (with short header) and group
1 (with long header.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
As the firmware is slowly running out of command IDs and grouping of
commands is desirable anyway, the firmware is extending the command
header from 4 bytes to 8 bytes to introduce a group (in place of the
former flags field, since that's always 0 on commands and thus can
be easily used to distinguish between the two.
In order to support this most easily in the driver widen the command
command ID used in the command sending functions and encode the new
values (group and version) in the ID. That way existing code doesn't
have to be changed (since the higher bits are 0 automatically) and
newer code can easily use the new ID generation function to create a
value to use in place of just the command ID.
Signed-off-by: Aviya Erenfeld <aviya.erenfeld@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
ToF is a time based method for measurement of the WiFi device
location within a WiFi environment. The driver functionality provided
by this patch is the interface for communication with FW and receiving
location related updates from the FW. The interface provided by this
patch is via debugfs.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
All the supported firmwares support this API.
This includes removing dwell per band, as band is no longer a factor
in calculating the dwell. Only basic dwell is used and FW will calculate
the actual dwell time.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The 'flags' field really has been reserved in the firmware API for a
very long time, probably since 4965. As a consequence, the field is
always 0 and checking for a IWL_CMD_FAILED_MSK flag makes no sense.
Rename the field to 'reserved', get rid of IWL_CMD_FAILED_MSK and
all the code for it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In iwlmvm firmwares, the Byte count written in the scheduler
byte count table is in DWORDs and not in bytes.
We should check that this value fits in the 12 bits and
the value can be either in bits of in DWORD or bytes
depending on the firmware. Check the value after the
translation to DWORDs is done (if needed).
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In a few places, we were disabling interrupts but didn't
make sure that the interrupt handler has finished running.
Add calls to synchronize_irq() to ensure we finish handling
the interrupts before we free resources or other things that
could lead to a crash if the interrupt were to be handled
later.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When the firmware crashes, we can't expect the Tx queues to
progress. Cancel their timer.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel 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: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
With the previous patch series, no opmode continues using the
command or handler_status (i.e. the return value from the RX)
so it can be removed now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel 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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
After the previous patches, the command that's passed in nor the
return value are used any more, so can be removed.
While at it, make some functions static.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This makes the logging a little less useful, but as they're mostly
synchronous commands it won't matter much. It gets rid of the
dependency on the input command, which this is the only user of.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This driver currently has some very confusing ADD_STA response handling
that runs asynchronously in the background for all of the commands, but
is only really necessary for synchronous ones (the really asynchronous
ones can only be done for already existing stations), and for the sync
ones it actually waits for the RX handler to return a status code.
Rework this to keep the debug printing in the handler, but do the code
that's supposed to have an effect only for sync commands in the command
sending function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The current key offset assignment algorithm always uses the lowest
unused key offset, which will potentially lead to issues when the
firmware will change to take the key material for TX from the key
table rather than from the TX command.
In order to avoid those issues (and avoid forgetting about them)
change the key offset allocation algorithm now to avoid reusing key
offsets quickly.
The new algorithm always picks as the next offset the least recently
freed offset, i.e. the offset that has been unused for the longest
amount of time. This is implemented by having a generation counter
for each key offset that is incremented every time a key is deleted,
except for the one that's deleted, which is reset to zero. Thus the
highest counter is the key that's been unused longest.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
During NIC initialization shared HW is reset and this disables the
scheduler. Some HW platforms do not activate the scheduler after it.
Consequently all HCMD sent by the driver stay at the queues which cause
to queue stuck.
Set the scheduler to work on auto active mode so it would be activated upon
change over one of the queues' write pointer.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The stuck queue detection mechanism allows to detect queues
that are stuck. For sleeping clients, a queue may rightfully
be stuck: if a poor client implementation stays asleep for
more than 10s, then we don't want to trigger recovery flows
because of that client.
In order to cope with this, I added a mechanism that
monitors the state of the client: when a client goes to
sleep, the timer of his queues is frozen. When he wakes up,
the timer is reset to the right value so that if a client
was awake for more than 10s and the queues are stuck, only
then, the recovery flow will kick in.
This is valid only on non-shared queues: A-MPDU queues.
There was a bug in case we Tx to a sleeping client that has
an empty A-MPDU queue: the timer was armed to now + 10s.
This is bad, but pretty harmless.
The problem is that when the client wakes up, the timer is
modified to be now + remainder. But remainder is 0 since the
queue was empty when that client went to sleep...
Fix this by checking the state of the client before playing
with the timer when we add a packet to an empty queue.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The code checks the total number of iterations to differentiate
between regular scan and scheduled scan. However, regular scan has
a total of one iteration, not zero. As a result, regular scan will
have lower priority than it should have, and in case scheduled
scan is already running when regular scan is requested, regular scan
will be delayed until scheduled scan is aborted.
Fix that by checking for total iterations number of one as an
identifier for regular scan.
Fixes: 133c8259f8 ("iwlwifi: mvm: rename generic_scan_cmd functions to dwell")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When the card is not owned by the PCIe bus, we need to
acquire ownership first. This flow is implemented in
iwl_pcie_prepare_card_hw. Because of a hardware bug, we
need to disable link power management before we can
request ownership otherwise the other user of the device
won't get notified that we are requesting the device which
will prevent us from acquire ownership.
Same holds for the down flow where we need to make sure
that any other potential user is notified that the driver
is going down.
CC: <stable@vger.kernel.org> [4.1]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When introducing multiple RX queues, a single NAPI struct will not
be sufficient. Instead of trying to store multiple, simply change
the API to have the NAPI struct passed to the RX function. This of
course means that drivers using rx_irqsafe() cannot use NAPI, but
that seems a reasonable trade-off, particularly since only two of
all drivers are currently using it at all.
While at it, we can now remove the IEEE80211_RX_REORDER_TIMER flag
again since this code path cannot have a napi struct anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This fixes the byte order copying in the MAO (Mac Override
Section) section from the PNVM, as the byte swapping is not
required anymore in the 8000 family. Due to the byte
swapping, the driver was reporting an incorrect MAC
adddress.
CC: <stable@vger.kernel.org> [4.1]
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This reverts commit 5f17570354.
This patch introduced a high latency in buffer allocation
under extreme load. This latency caused a firmwre crash.
The same scenario works fine with this patch reverted.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Add preemptive flag to scheduled scan command flags. Without this
flag, all scan requests after scheduled scan was started will be
delayed until scheduled scan stops. As a result, P2P_FIND will be
blocked while scheduled scan is active.
This flag was omitted during refactoring.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Add new 3165 devices support.
Add one new 8000 series device support.
Remove support for 0x0000, 0xC030 and 0xD030 sub-system IDs
in the 8000 series.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The time event is initialized relatively late in interface (mvmvif)
initialization, so it's possible to fail before that happens. As a
consequence, the driver will crash if it ever tries to delete this
time event in case initialization was unsuccessful.
Avoid this by using the time event's vif pointer to indicate validity.
The vif pointer is != NULL whenever the id is != TE_MAX, except for
this special error case where the vif pointer will have the correct
property (as the whole memory is cleared on allocation) whereas the
id is 0, causing a crash in trying to delete the time event from the
list.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
For 8000 series, we need to access the device to know what
firmware to load. Before we do so, we need to prepare the
device otherwise we might not be able to access the
hardware.
Fixes: c278754a21e6 ("iwlwifi: mvm: support family 8000 B2/C steps")
CC: <stable@vger.kernel.org> [4.1]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwl_trans_pcie_alloc needs to return a non-zero value
if it fails. Otherwise the iwl_drv_start will think that
the allocation succeeded.
Remove the duplication of err and ret variable and use ret
which is the name we usually use in other places of the
driver.
Fixes: c278754a21e6 ("iwlwifi: mvm: support family 8000 B2/C steps")
CC: <stable@vger.kernel.org> [4.1]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
While cleanig the access to those hw-dependent registers,
instead of using the product family type, wrong condition was added
mistakenly and enabled 8000 family devices a forbidden access
to HW registers, fix it.
Fixes: 95411d0455 ("iwlwifi: pcie: Control access to the NIC's PM registers via iwl_cfg")
Signed-off-by: Dreyfuss, Haim <haim.dreyfuss@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Sometimes when setting an igtk key the station maybe NULL.
In the of case igtk the function will skip to the end, and
try to print sta->addr, if sta is Null - we will access a
Null pointer.
Avoid accessing a Null pointer when setting a igtk key &
the sta == NULL, and print a default MAC address instead.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When BT is active, we want to avoid the shared antenna for
management frame to make sure we don't disturb BT. There
was a bug in that code because it chose the antenna
BIT(ANT_A) where ANT_A is already a bitmap (0x1). This
means that the antenna chosen in the end was ANT_B.
While this is not optimal on devices with 2 antennas (it'd
disturb BT), it is critical on single antenna devices like
3160 which couldn't connect at all when BT was active.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=97181
CC: <stable@vger.kernel.org> [3.17+]
Fixes: 34c8b24ff2 ("iwlwifi: mvm: BT Coex - avoid the shared antenna for management frames")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This allows to ensure that we don't have races between them.
A user reported that stop_device was called twice upon
rfkill interrupt after suspend. When the interrupts are
enabled, and right after when we directly check the rfkill
state.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The new locking in PCIe transport requires to start_hw
before start_fw. This uncovered a bug in dvm which failed
to do so.
Fix that.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This firmware is not supported anymore - stop loading this firmware.
Remove code handling older versions.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
There's no need to forward RX MPDUs to notification wait tests, nor
do we need to check them for firmware dump triggers, nor could they
be asynchronous. It's thus more efficient to handle them separately,
before going into the regular RX handlers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In scenarios where we haven't converged yet to a specific modulation
and rate it could be better to report to userspace the last tx rate
based on the STA capabilities and RSSI. This is important as sometimes
userspace displays the last tx rate as the link speed.
This avoids being presented with low legacy rates when rs just begins
its search or after an idle period in which it resets itself.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.
This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.
The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Merge back net-next to get wireless driver changes (from Kalle)
to be able to create the API change across all trees properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ath10k:
* qca6174 power consumption improvements, enable ASPM etc (Michal)
wil6210:
* support Wi-Fi Simple Configuration in STA mode
iwlwifi:
* a few fixes (re-enablement of interrupts for certain new
platforms that have special power states)
* Rework completely the RBD allocation model towards new
multi RX hardware.
* cleanups
* scan reworks continuation (Luca)
mwifiex:
* improve firmware debug functionality
rtlwifi:
* update regulatory database
brcmfmac:
* cleanup and new feature support in PCIe code
* alternative nvram loading for router support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJVb1cPAAoJEG4XJFUm622bP0oIAKhUBlC3rtrOJd+9kREAGUJQ
Dk2xZr/p6hdb4dSHHKKroBr5mfryHknSs+AI5akJMph36DoBMD+Mwb4HlcL9cI5J
RXIjIvQEADsK+6ME7cqnw2htWlYsX8aJI96/2Eusveo/zHyAG3+eBC3wkyqWBlBK
EGV5ziClSe5pE5yGWj5tyr9me+qRQiO+dFJK1AoRE3Zq4pjj+5VDZoVQN0GNZGP7
lgeNOzvPxWt+ZseslP8IeCedN5c+NpacD889NnQJyMXaouSp7LmMod000bjnKK8o
9sRHsKxI5qHgC4mUa3Tk3cEnFqVYAo8KKOVaBVtKsMc4XoO/Qov6Z0AtXig5Xnk=
=CM/T
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2015-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
new driver mt7601u for MediaTek Wi-Fi devices MT7601U
ath10k:
* qca6174 power consumption improvements, enable ASPM etc (Michal)
wil6210:
* support Wi-Fi Simple Configuration in STA mode
iwlwifi:
* a few fixes (re-enablement of interrupts for certain new
platforms that have special power states)
* Rework completely the RBD allocation model towards new
multi RX hardware.
* cleanups
* scan reworks continuation (Luca)
mwifiex:
* improve firmware debug functionality
rtlwifi:
* update regulatory database
brcmfmac:
* cleanup and new feature support in PCIe code
* alternative nvram loading for router support
====================
Conflicts:
drivers/net/wireless/iwlwifi/Kconfig
Trivial conflict in iwlwifi Kconfig, two commits adding
the same two chip numbers to the help text, but order
transposed.
Signed-off-by: David S. Miller <davem@davemloft.net>
After the new ciphers CCMP-256 and GCMP-128/256 were implemented,
wpa_supplicant could start negotiating them and use the software
implementation. This, however, breaks D3 behaviour in the driver
since it means that WoWLAN will not be possible.
To avoid breaking that feature, advertise only ciphers that the
hardware supports.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Add DC2DC_CONFIG_CMD (0x83) cmd.
Add IWL_UCODE_TLV_CAPA_DC2DC_CONFIG_SUPPORT tlv.
The command allows the driver get & set the DCDC's frequency tune.
(freq_tune is the divider that is used to calculate the actual DCDC's
clock rate)
The command always returns the current/updated frequency tune values of
the DCDC.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
