We changed the timeout for the interrupt coealescing for
calibration, but that wasn't effective since we changed
that value back before loading the firmware. Since
calibrations are notification from firmware and not Rx
packets, this doesn't change anyway - the firmware will
fire an interrupt straight away regardless of the interrupt
coalescing value.
Also, a HW issue has been discovered in 7000 devices series.
The work around is to disable the new interrupt coalescing
timeout feature - do this by setting bit 31 in
CSR_INT_COALESCING.
This has been fixed in 7265 which means that we can't rely
on the device family and must have a hint in the iwl_cfg
structure.

Cc: stable@vger.kernel.org [3.10+]
Fixes: 99cd4714 ("iwlwifi: add 7000 series device configuration")
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

7265 is a very similar device to 7260, so just add
the definitions based on 7260 for it.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add some new PCI IDs to the table for 6000, 6005 and 6235 series.

Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the NIC is expected to operate in high temperature,
it is advisable to put more aggresive thermal throttling
parameters, in order to prevent CT-kill.
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>

In newest NICs (7000 family and up), L1 is supported, so
avoid to disable it.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

1x1 products will need a special LUT.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The older devices (pre-7000/3000 series) all only work with the
DVM opmode due to firmware availability, while newer ones will
only work with the MVM opmode for the same reason.

When building a driver that only has one of MVM or DVM, there's
no reason to build the device support and have the PCIe IDs for
all devices since they can't be used anyway, so avoid that.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There are a number of parameters that aren't really hardware
specific but rather define how the DVM firmware is used.
Move these into the DVM configuration.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add new device IDs and configurations to support
all the devices.
Signed-off-by: NOren Givon <oren.givon@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Newer devices can work on different buses. This means that
their configuration can be shared between different buses.
Hence the configuration structures should exported to all
the buses and not only to PCIE. Change this.

Note that this requires all the fields to be the same
amongst the buses. If differences will appear, we can always
define a part that is bus dependent. Today, this is not
needed.
Signed-off-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>

Add configuration and detection code for the new
7000 series, with 7260 and 3160 devices.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Update Copyright notices to 2013.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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>

Functions that implement the transport API are prefixed by
iwl_trans_pcie_, the others by iwl_pcie_.
Signed-off-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>

Commit 7c5ba4a8 ("iwlwifi: move queue
watchdog into transport") introduced the named constant
'IWL_WATCHHDOG_DISABLED'. Rename it to 'IWL_WATCHDOG_DISABLED'.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The EEPROM reading/parsing code is all mixed in
the driver today, and the EEPROM is parsed only
when we access data from it. This is problematic
because the NVM needs to be parsed and that is
independent of reading it. Also, the NVM format
for new devices will be different and probably
require a new parser.

Therefore refactor the reading and parsing and
create two independent components. Reading the
EEPROM requires direct hardware accesses and
therefore access to the transport, but parsing
is independent and can be done on an NVM blob.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no need to dynamically fill the HT40
band bitmap as it's a device parameter, just
put it into the HT configuration.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a debugging log when using shadow
registers. Also fix a minor typo in this
connection.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since they're used in the config, they
should be declared in iwl-config.h.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since they're used in the config, they
should be declared in iwl-config.h.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since they're used in the config, they
should be declared in iwl-config.h.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Having the pointer to lib_ops in the config
makes it impossible to split the driver into
different modules. Determine the ops based on
the device family enumeration to get rid of
the direct pointer.

Also move all the opmode specific code from
the iwl-[1256]000.c files into a new file
iwl-agn-devices.c so that the former only
have configuration data now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This will later be used to dynamically bind
the configuration data for DVM and MVM.

For now, we can use it to get rid of the
additional_nic_config() hook.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The iwl-shared.h header file will be going away
soon. There isn't much left in it that we keep,
other than the device configuration declarations.
Move those out now to a new iwl-config.h header.
iwl-cfg.h seemed like a possible alternative but
those declarations will later live in the PCIe
transport code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The whole code around eeprom is distributed
across whole bunch of different files, most
of which belong to the to-be-DVM code. As a
result, it is currently very hard to split
out the EEPROM code to be generic. However,
it is also quite unlikely that the current
EEPROM code will be needed by the MVM code
as that has different mechanisms to query
the EEPROM (it does so through the uCode.)

So, at least temporarily, move everything
into priv. If it becomes necessary to use
the code from MVM, we will have to split it
out, but then it's also easier since we'll
know what pieces we need.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This defaults to false, and we don't recommend
to use it anywhere, so just remove it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The hw_params are mostly values that are
derived from the actual hardware config.
As such, while it is possible that MVM
will require similar ones, it makes more
sense -- at least for now -- to put them
into the DVM struct.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This removes one of the two sources of device
restarts in the upper layer -- those are a bit
inconvenient because normal restarts originate
in the transport. By moving the watchdog down
it can be treated the same.

Also rewrite the watchdog logic. Timers are
much more efficient when they never fire, so
instead firing a timer every 500ms set up a
timer for each TX queue and fire it only when
the queue is really stuck. This avoids the CPU
waking up when everything is working well.

While at it, remove the wd_disable config item
and replace it by simply setting wd_timeout to
IWL_WATCHHDOG_DISABLED (0).
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

That way it isn't needed in hw_params, which
is shared data. It also isn't really what we
should configure in the transport, that is
better just 4k/8k, so configure a bool and
derive the page order in the transport. This
also means the transport doesn't need access
to the module parameter any more.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With error logging now completely handled in
the op_mode, the transport layer does not
need to know information about the loaded
firmware.

Remove this state information from the
iwl_shared data structure.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This variable holds the ucode currently
running on the device; which is determined by
op_mode, so move this parameter there.

Also, the name of the variable is a bit
misleading, so rename it to cur_ucode.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Error log reporting does not belong to the
transport layer, but to the op_mode loading
the ucode, as it is the entity which knows
about the ucode loaded, and what the error
information means.

Move device logging pointers from the
transport layer to op_mode.

With this change, transport layer only
reports an error to the op_mode, which will
figure out what to do with the error. This
causes the driver to now dump out error logs
when the command queue is stuck as well.

Also, move the debugfs entry for event logs
out of the transport layer and into op_mode.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

No other component is accessing it any more,
so it can move to the correct place in priv.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The queue mapping is not only dynamic, it
is also dependent on the uCode, as we can
already see today with the dual-mode and
non-dual-mode being different.

Move the queue mapping out of the transport
layer and let the higher layer manage it.
Part of the transport configuration is how
to set up the queues.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is not (no longer?) used by any device
so just remove it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is used only by 2000 class devices, but
they all use it so remove the configuration
parameter and hard-code the programming.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There's no device using this mechanism.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It talks about treating different uCode APIs
as different pieces of hardware which really
isn't how we handle things.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>