Since we will have several forms of NVM (EEPROM, OTP, etc.)
and they will have different layouts, make the parsed data
more generic. This allows functional code to be independent
of a specific layout.

Also change some variables and function names from having
"eeprom" to "nvm" in their name.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When software crypto is enabled, it isn't safe
to enable MFP since the firmware interprets some
management packets, and with MFP it would do so
without proper validation.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NAssaf Krauss <assaf.krauss@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no reason to print these all the time,
the messages aren't all that interesting. Leave
them as DEBUG_INFO though, just in case.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

People tend not to set the fields they want to leave as 0.
So make sure the struct is zeroed properly.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The ALIVE response of new fw inclues the base address of
the SCD in SRAM. Until we read it from a prph register,
which was set by the fw. Since the fw might well stop
updating the prph register, add a WARN when there is an
inconsitency between the ALIVE response and the register
to catch any change in the behavior.
Reviewed-by: NGregory Greenman <gregory.greenman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The flush_control parameter to iwlagn_txfifo_flush
is passed as an internal value (context flags) and
then sent to the device, that can't be right.

Fix the confusion by removing the parameter, always
use IWL_DROP_ALL that is redefined according to the
firmware API in the flush control.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no reason to clear the CTL_AMPDU flag on
transmitted frame status, it's not used by the
driver here and mac80211 only uses it for some
rate statistics.

Also remove a stray space in the function.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The flush command really flushes queues, not
FIFOs, and the first 32 bits indicate the
queues to flush, not FIFOs. Change the command
accordingly.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When we unregister from mac80211 it will down the device anyway.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

No HCMD can be sent while RFKILL is asserted. If a SYNC
command is running while RFKILL is asserted the fw will
silently discard it. This means that the driver needs to
wake the process that sleeps on the CMD_SYNC.

Since the RFKILL interrupt is handled in the transport layer
and the code that sleeps in CMD_SYNC is also in the transport
layer, all this logic can be handled there.
This simplifies the work of the op_mode.

So the transport layer will now return -ERFKILL when a CMD
is sent and RFKILL is asserted. This will be the case even
when the CMD is SYNC. The transport layer will return
-ERFKILL straight away.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Remove the Kconfig option CONFIG_IWLWIFI_EXPERIMENTAL_MFP,
if the firmware doesn't support MFP then the user shouldn't
have the option to enable it as it won't work correctly.
Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Once in bus enumeration is enough, no need to print it
again when the op_mode loads.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Remove a number of variables that are assigned, but not used.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When tracing in iwlwifi, we get all data. Most of
the time, we don't need it, and it just takes up
a lot of extra space in the trace.

Make this optional by recording the data into two
separate trace events if it is needed. Without it,
record only the content of non-data and EAPOL TX
frames.

As a result, tracing without the data tracepoints
will record meta information including the 802.11
headers for all frames but will not record the
contents of data frames to reduce trace overhead.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Before Emmanuel's change to use a copy of the command
("iwlwifi: get the correct HCMD in the response handler")
the iwl_add_sta_callback() function would have used a
random pointer to somewhere when processing responses
to an async command, while that wasn't valid data it
was at least a valid pointer. Now, the pointer will be
NULL in this case, thus crashing.

Fix this by exiting the function early if no command
is passed back which means it was sent asynchronously.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of memcpy() from a static array, just use
the new helper function eth_broadcast_addr().
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of allocating one big chunk of DMA-coherent
memory for the firmware and keeping it around, only
vmalloc() the firmware and copy it into a single
page of DMA-coherent memory for the upload.

The advantage is that we don't need DMA memory for
the firmware image that is stored while the driver
is operating, we only need it while uploading.

This will make it easier for the driver to work if
the system has fragmented memory.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since the firmware will give us an A-MPDU bit and
only a single PHY information packet for all the
subframes in an A-MPDU, we can easily report the
minimal A-MPDU information for radiotap.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The device only supports a maximum of three
antennas, and only three bits are used, the
fourth bit is the A-MPDU indicator.

The only consequence of this is reporting
invalid information in radiotap, so this
isn't an important change.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the device is not started, we can't read its
SRAM and attempting to do so will cause issues.
Protect the debugfs read.

Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When unregistered with mac80211, we can't call its functionality
for FW restart, so avoid it and prevent automatic FW restart for
the init firmware.
Signed-off-by: NAmit Beka <amit.beka@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's a bug that causes the rate scaling to get stuck
when it has to use single-stream rates with a peer that
can do GF and SGI; the two are incompatible so we can't
use them together, but that causes the algorithm to not
work at all, it always rejects updates.

Disable greenfield for now to prevent that problem.

Cc: stable@vger.kernel.org
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Tested-by: NCesar Eduardo Barros <cesarb@cesarb.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the control.sta pointer from ieee80211_tx_info to free up
sufficient space in the TX skb control buffer for the upcoming
Transmit Power Control (TPC).
Instead, the pointer is now on the stack in a new control struct
that is passed as a function parameter to the drivers' tx method.
Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: NAlina Friedrichsen <x-alina@gmx.net>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
[reworded commit message]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Due to the way the PAN parameters are set up, the
maximum duration isn't 1000 but much lower, set it
to 500 which is safe (somewhere around 550 might
be possible.)
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Until now, the response handler of a Host Command got the
exact same pointer that was also given to the DMA engine.
We almost never need to the Host Command that was sent while
handling its response, but when we do need it, we see that
the command has been modified.

This mystery has been elucidated. The FH (our DMA engine)
writes its meta data on the buffer in the DRAM. Of course it
copies the buffer to the NIC first. This was known to happen
for Tx command, but as a matter of fact, it happens to all
TFD brought by the FH which doesn't care much about what it
brings from DRAM to internal SRAM.

So copy the Host Command to yet another buffer so that we
can properly pass the buffer that was sent originally to the
fw. Do that only if it was request by the user since very
few flows need to get the HCMD sent in the response handler.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Align the code to inside the WARN_ON() as it should.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The generic part of the driver now creates all debugfs
directories. It creates a root directory directly in
the the root of the debugfs filesystem and within that
directories for each device, named after the device ID
of the devices iwlwifi is attached to.

In the cfg80211/mac80211 directory there's now a link
to the toplevel iwlwifi debugfs directory to make it
easier to find the debugfs files.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If registration with mac80211 fails, stop the thermal
throttling and testmode work that were previously started.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some drivers (iwlegacy, iwlwifi and rt2x00) today use the
bss_conf.last_tsf value. By itself though that value is
completely worthless since it may be ancient. What really
is needed is synchronisation between some device time and
the TSF.

To clarify this, rename bss_conf.last_tsf to sync_tsf and
add sync_device_ts which is obtained from rx_status which
gets a new field device_timestamp for this purpose. This
is intentionally not using the mactime field since that
is used for other things and in IBSS is expected to sync
with the IBSS's TSF which isn't necessarily true for the
device timestamp.

Also, since we have the information and it's useful even
before the connection has been established, give all the
timing details to the driver before authenticating.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Newer devices use 32 bit for boost register,
set the correct value for it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Remove this dead code, it is unused for device newer than
4965.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

'echo 1 > log_event' generates the bogus "MAC is in deep sleep"
or "Timeout waiting for hardware access" log messages when
the interface is down, we should just disallow accessing the
device through debugfs when it is down.
Signed-off-by: NRichard A. Griffiths <richardx.a.griffiths@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The dwell time for scanning is currently limited
so that it fits into the timings inside the ucode
when that is tracking DTIM/beacon periods for the
AP(s) it's connected to.

However, when it's connected to two APs, those
may be in lockstep, for example if they both have
a DTIM interval of 100 TU, then one could be 50
TU after the other, leaving only 50 TU free to
be used by scanning.

Since we can't know how far apart they are the
only option is to restrict to 1/2 of the minium
of the two APs.

In theory, it would be possible to not use 1/2 of
the minimum but take into account that if they
have different intervals then there will be a bit
more time since they can't be in lockstep, but as
they will have 100 TU intervals in practice that
complex calculation will probably just result in
hard-to-find bugs.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since the op_mode defines the queue mapping, let it do it
completely through the API functions.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently when mac80211 asks to change the interface
type, we will accept it for both the BSS and PAN
contexts. This is not terribly complicated today,
but with the addition of the P2P Device abstraction
the PAN context handling will get more complex, so
restrict mac_change_interface to the BSS context.

Also fix a small locking issue and use is_active
instead of the vif pointer to check if the other
context is activated, guarding exclusive interface
types on the BSS context (IBSS) against the PAN
context being used for something else.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the first interface is active, then scanning
on it or the second interface can take a little
longer than 7s (I observed around 8s.) Bump the
timeout to 15s to avoid aborting a scan that is
still running, just taking more time.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

My previous commit to shorten the radio reset time
caused issues as the firmware checks the active
dwell time against the quiet time, asserting that
the dwell is >= quiet time. This isn't really
needed in case of passive scanning like here, but
of course we need to pass that check.

To fix this, override the quiet time to be the
same as the radio reset dwell time.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Now that the eeprom parsing code overrides the sku
field directly with 11n_disable parameters, there's
no longer a need to keep a copy of this field.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The effect of using a short single-channel scan
to reset the radio is that scanning a channel
that isn't in use needs to re-tune the radio.
This means that the dwell time is irrelevant,
so use a shorter time.

While at it, clean up the code for this a bit.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>