For 6x00 2x2 NIC, two types of Power Amplifier are available.
In order for uCode to apply correct tx power,
driver needs to program the CSR_GP_DRIVER_REG register and
let uCode know the type of PA.
If driver do not program CSR_GP_DRIVER_REG register (default to 0),
then it is uCode's decision for tx power

2x2 Hybrid card: use both internal and external PA
2x2 IPA(Internal Power Amplifier) card: internal PA only
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Resolve an issue in which out-dated fields in iwl_cmd_meta
could be used for later hardware commands.
Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is a private flag, internal to cfg80211. cfg80211
will set orig_* stuff internally upon wiphy registration,
drivers do not need to muck with it.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Acked-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Even with the split into iwlcore/agn/3945 not all symbols
that cross file boundaries are needed in other modules, a
few are only used within iwlcore, for example.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add debugfs file to enable/disable HT40(40MHz) channel support.
By default, 40MHz is supported if AP can support the function.

By echo "1" to "disable_ht40" file, iwlwifi driver will disable the
40MHz support and only allow 20MHz channel.

Because the information exchange happen during association time,
so enable/disable ht40 channel only can be performed when it is not
associated with AP.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

C [M]  drivers/net/wireless/iwlwifi/iwl-core.o
drivers/net/wireless/iwlwifi/iwl-core.c:1341: warning:
‘iwl_dump_nic_error_log’ defined but not used
Reported-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit "iwlwifi: Handle new firmware file with ucode build number
in header" introduced new ucode header parsing routines, but
neglected to initialize these routines for 1000. The system thus goes
into infinite loop trying to load ucode, failing every time with a null
pointer exception as it tries to parse the header.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

IWLWIFI_LEDS option should certainly have help comment, and should
default to y.
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix incorrect name for HT MPDU Density.
default set to 4 uSec
Reported-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This data is more useful to debugging that the receive
buffer contents.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

No existing callbacks use anything other than the return
value 1, which means that the caller should free the
reply skb, so it seems safer in terms of not introducing
memory leaks to simply remove the return value and let
the caller always free the skb.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The current command sending in iwlwifi is a bit of a mess:
 1) there is a struct, iwl_cmd, that contains both driver
    and device data in a single packed structure -- this
    is very confusing
 2) the on-stack data and the command metadata share a
    structure by embedding the latter in the former, which
    is also rather confusing because it leads to weird
    unions and similarly odd constructs
 3) each txq always has enough space for 256 commands,
    even if only 32 end up being used

This patch fixes these things:
 1) rename iwl_cmd to iwl_device_cmd and keep track of
    command metadata and device command separately, in
    two arrays in each tx queue
 2) remove the 'meta' member from iwl_host_cmd and only
    put in the required members
 3) allocate the cmd/meta arrays separately instead of
    embedding them into the txq structure
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add debugfs function to display current thermal throttling status for
both Legacy and Advance Thermal Throttling Management
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Part 2 of Thermal Throttling Management -

Thermal Throttling feature is used to put NIC into low power state when
driver detect the Radio temperature reach pre-defined threshold

Two Thermal Throttling Management Methods; this patch introduce the
Advance Thermal Throttling:
TI-0: system power index, no tx/rx restriction, HT enabled
TI-1: power index 5, 1 spatial stream Tx, multiple spatial stream Rx, HT
enabled
TI-2: power index 5: 1 spatial stream Tx, 1 spatial stream Rx, HT
disabled
TI-CT-KILL: power index 5, no Tx, no Rx, HT disabled

For advance Thermal Throttling, CT_KILL_ENTER threshold and CT_KILL_EXIT
threshold are different; uCode will not stay awake until reach
CT_KILL_EXIT threshold.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Part 1 of Thermal Throttling Management -

Thermal Throttling feature is used to put NIC into low power state when
driver detect the Radio temperature reach pre-defined threshold

Two Thermal Throttling Management Methods; this patch introduce the
Legacy Thermal Management:
   IWL_TI_0: normal temperature, system power state
   IWL_TI_1: high temperature detect, low power state
   IWL_TI_2: higher temperature detected, lower power state
   IWL_TI_CT_KILL: critical temperature detected, lowest power state

Once get into CT_KILL state, uCode go into sleep, driver will stop all
the active queues, then move to IWL_TI_CT_KILL state; also set up 5
seconds timer to toggle CSR flag, uCode wake up upon CSR flag change,
then measure the temperature.
If temperature is above CT_KILL exit threshold, uCode go backto sleep;
if temperature is below CT_KILL exit threshold, uCode send Card State
Notification response with appropriate CT_KILL status flag, and uCode
remain awake, Driver receive Card State Notification Response and update
the card temperature to the CT_KILL exit threshold.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If advance thermal throttling is used the driver need to pass both
"enter" and "exit" temperature to uCode.

Using different critical temperature threshold for legacy and advance
thermal throttling management based on the type of thermal throttling
method is used except 1000.
For 1000, it use advance thermal throttling critical temperature
threshold, but with legacy thermal management implementation until ucode
has the necessary implementations in place.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When performing rate scaling, if detected that the new rate
index is invalid, clear the search_better_tbl flag
so it will not be stuck in the loop.

Since the search table is already set up in uCode,
we need to empty out the the search table;
revert back to the "active" rate and throughput info.
Also pass the "active" table setup to uCode to make
sure the rate scale is functioning correctly.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

tid is bounded (above) by the size of default_tid_to_tx_fifo (17 elements), but
the size of priv->stations[].tid[] is MAX_TID_COUNT (9) elements.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We need to provide a reasonable minimum that will result in a
working setup if used. Set minimum to be 10 to provide for
4 standard TX queues + 1 command queue + 2 (unused) HCCA queues +
4 HT queues (one per AC).

We allow the user to change the number of queues used via a module
parameter and use this minimum value to check if it is valid. Without
this patch a user can select a value for the number of queues that
will result in a failing setup.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Reviewed-by: NTomas Winkler <tomas.winkler@intel.com>
Acked-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I had a problem on 4965 hardware (well, probably other hardware too,
but others don't survive my stress testing right now, unfortunately)
where the driver was sending invalid commands to the device, but no
such thing could be seen from the driver's point of view. I could
reproduce this fairly easily by sending multiple TCP streams with
iperf on different TIDs, though sometimes a single iperf stream was
sufficient. It even happened with a single core, but I have forced
preemption turned on.

The culprit was a queue overrun, where we advanced the queue's write
pointer over the read pointer. After careful analysis I've come to
the conclusion that the cause is a race condition between iwlwifi
and mac80211.

mac80211, of course, checks whether the queue is stopped, before
transmitting a frame. This effectively looks like this:

        lock(queues)
        if (stopped(queue)) {
                unlock(queues)
                return busy;
	}
        unlock(queues)
        ...             <-- this place will be important
			    there is some more code here
        drv_tx(frame)

The driver, on the other hand, can stop and start queues, which does

        lock(queues)
        mark_running/stopped(queue)
        unlock(queues)

	[if marked running: wake up tasklet to send pending frames]

Now, however, once the driver starts the queue, mac80211 can see that
and end up at the marked place above, at which point for some reason the
driver seems to stop the queue again (I don't understand that) and then
we end up transmitting while the queue is actually full.

Now, this shouldn't actually matter much, but for some reason I've seen
it happen multiple times in a row and the queue actually overflows, at
which point the queue bites itself in the tail and things go completely
wrong.

This patch fixes this by just dropping the packet should this have
happened, and making the lock in iwlwifi cover everything so iwlwifi
can't race against itself (dropping the lock there might make it more
likely, but it did seem to happen without that too).

Since we can't hold the lock across drv_tx() above, I see no way to fix
this in mac80211, but I also don't understand why I haven't seen this
before -- maybe I just never stress tested it this badly.

With this patch, the device has survived many minutes of simultanously
sending two iperf streams on different TIDs with combined throughput
of about 60 Mbps.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwl_enable_interrupts is being called inside the interrupt,
change from function call to inline
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rfkill state changes are mostly available through debug messages.
These are significant enough to always make user aware of so
we turn them into warnings.

Also insert a missing newline in some rfkill related debug message.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a hardware error is detected we need to be clear about that
and not create impression that the microcode is able to deal
with it.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Deprecate the "debug50" module parameter used to obtain
  5000 series and up debugging. Replace it with "debug" module
  parameter to match with original driver and be consistent
  between them. The "debug50" module parameter can still be used,
  except that the module parameter is not writable in keeping
  with its previous state. We currently just mark it as "deprecated"
  and do not have it in the feature-removal-schedule. Some more
  cleanup of module parameters needs to be done and can then be
  entered together.

* Only make "debug" module parameters visible if the driver
  is compiled with CONFIG_IWLWIFI_DEBUG. This will eliminate
  a lot of confusion where users think they have set debug flags
  but yet cannot see any debug output.

* Make module parameters writable. This eliminates the need for the
  "debug_level" sysfs file, which can now also be deprecated and
  added to feature-removal-schedule. This file is in significant
  use though with many iwlwifi documents and text referring users
  to it. We can thus not take its removal lightly and keep it around.

With iwlcore shared between iwlagn and iwl3945 we really do not need
debug module parameters for each but can instead have one debug
module parameter for the iwlcore module. The same issue is here as
with the sysfs file - a lot of iwlwifi documentation and text (like
bug reports) rely on iwlagn and iwl3945 having this module parameter,
so changing this to a module parameter of iwlcore will have significant
impact and we do not do this for that reason.

One consequence of this patch is that if a user is running a system
with both 3945 and later hardware then the setting of the one module
parameter will affect the value of the other. The likelihood of this
seems low - and even if this setup is present it does not seem like an
issue for both modules to run with the same debug level.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Wait for REPLY_ALIVE notification from init and runtime uCode.
based on the type of REPLY_ALIVE, different status bit will be set to
wake up the queue:
STATUS_INIT_UCODE_ALIVE for init uCode
STATUS_RT_UCODE_ALIVE for runtime uCode.

If timeout, attempt to download the failing uCode image again. This can
only be done for the init ucode images of all iwlagn devices and the
runtime ucode image of the 5000 series and up. If there is a problem
with the 4965 runtime ucode coming up we restart the interface and thus
trigger a new download of the init ucode also.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

firmware file now contains build number so API needs to be updated.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When deciding NVM type, if the HW type is unknown, report error and exit
with -ENOENT. This check should prevent incorrect behavior by assuming
the wrong NVM type.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For controlling led blinking, counting both tx and rx data traffic; this
will be able to handle traffic in either direction
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adding debugfs file to show current led blinking rate
/sys/kernel/debug/ieee80211/phy0/iwlagn/data/led
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Do all key clearing except sending sommands to device when rfkill
enabled. When rfkill enabled the interface is brought down and will
be brought back up correctly after rfkill is enabled again.

Same change is not needed for iwl3945 as it ignores return code when
sending key clearing command to device.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=13742Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Tested-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Led functions are generic for all the devices except 3945, so remove the
reference to 4965
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adding new API version to account for change to ucode file format.  New
header includes the build number of the ucode.  This build number is the
SVN revision thus allowing for exact correlation to the code that
generated it.

The header adds the build number so that older ucode images can also be
enhanced to include the build in the future.

some cleanup in iwl_read_ucode needed to ensure old header not used and
reduce unnecessary references through pointer with the data is already
in heap variable.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix quality incorrectly reported as signal strength value.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On 1000, there are two Switching Voltage Regulators (SVR). The first one
apply digital voltage level (1.32V) for PCIe block and core. We need to
use this regulator to solve a stability issue related to noisy DC2DC
line in the silicon.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All current rate control algorithms agree to send management and no-ack
frames at the lowest rate. They also agree to do this when sta
and the private rate control data is NULL. We add a hlper to mac80211
for this and simplify the rate control algorithm code.

Developers wishing to make enhancements to rate control algorithms
are for broadcast/multicast can opt to not use this in their
gate_rate() mac80211 callback.

Cc: Zhu Yi <yi.zhu@intel.com>
Acked-by: NReinette Chatre <reinette.chatre@intel.com>
Cc: ipw3945-devel@lists.sourceforge.net
Cc: Gabor Juhos <juhosg@openwrt.org>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwl-agn-rs.c already uses this.

Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: ipw3945-devel@lists.sourceforge.net
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This removes the work around implemented for transmitting on
an unsupported band on iwlwifi. This was added via the patch:

8e1856e82cb8f541e925738bebfbc473420cda68:
iwlwifi: fix rs_get_rate WARN_ON()

Cc: Mohamed Abbas <mohamed.abbas@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwl_dump_nic_error_log can be static and iwl_dump_nic_event_log
doesn't need to be exported.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We need to provide a reasonable minimum that will result in a
working setup if used. Set minimum to be 10 to provide for
4 standard TX queues + 1 command queue + 2 (unused) HCCA queues +
4 HT queues (one per AC).

We allow the user to change the number of queues used via a module
parameter and use this minimum value to check if it is valid. Without
this patch a user can select a value for the number of queues that
will result in a failing setup.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Reviewed-by: NTomas Winkler <tomas.winkler@intel.com>
Acked-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Rename maximum number of queue (TFD_QUEUE_MAX) to IWL39_NUM_QUEUES to
  be consistent with rest of iwlwifi.
* Remove unused defines.
* Fix loops that iterate over number of TX queues to stop when maximum is reached
  (currently it is maximum + 1).
* Remove queues_num module parameter as it is not used.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>