Get this information from the transport layer.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Get this information from the transport layer.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Get this information from the transport layer which is now in charge
of the APM too.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This handler was called from the transport layer only. Merge it
to the transport's apm_init.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Now there is only one transport function that launch a specific fw:
trans_ops->start_fw. This one replaces trans_ops->start_device and
trans_ops->kick_nic. The code that actually loads the fw to the
device has been moved to the transport specific code.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This is another clean up of the proble flow.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This handler stops the HW and puts it in low power state.
It will allow to clean up the flows in the upper layers.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This is transport related
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Kill the trans_ops->prepare_card_hw which is now useless.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This handler will become thicker, reflect its real role now.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This is transport related
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

From now on, the transport layer in charge of providing access to the
device. So change all the driver to give a pointer to the transport
to all the low level functions that actually access the device.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Most of the accesses to the registers are done from the transport layer.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

All the bus configuration is now done in the transport
allocation fucntion.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Change the way we alloc the transport on the way.
Since the transport is allocated from a bus specific area, we can
give the bus specific parameters (i.e. pci_dev for PCI) to the
transport. This will be useful when the bus layer will be killed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Allocating the shrd area dynamically will allow more agility
while revamping the flows.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

There is no link between the two. Ensure that the NIC is on outside
the code of the EEPROM handling.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This patch connects IDI transport to driver. It does so
by using a number of ifdefs at this stage.
IDI is a new transport that is under development.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Define a new handler in the transport layer API: fw_alive.
Move iwl_reset_ict to this new handler, and move the content
of tx_start to this handler.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into wireless-next

This patch addresses a kernel bugzilla report and two recent mail threads.

The kernel bugzilla report is https://bugzilla.kernel.org/show_bug.cgi?id=42632,
which reports a udev timeout on boot.

The first mail thread, which was on LKML (http://lkml.indiana.edu/hypermail/
linux/kernel/1112.3/00965.html) was for a WARNING that occurs after a
suspend/resume cycle for rtl8192cu.

The scond mail thread (http://marc.info/?l=linux-wireless&m=132655490826766&w=2)
concerned changes in udev that break drivers that delay while firmware is loaded
on modprobe.

This patch converts all rtlwifi-based drivers to use the asynchronous firmware
loading mechanism. Drivers rtl8192ce, rtl8192cu and rtl8192de share a common
callback routine. Driver rtl8192se needs different handling of the firmware,
thus it has its own code.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

channelFlags doesn't contain the operating HT mode.
Use IS_CHAN_HT40 to determine if the current channel is
in HT40 mode.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch modifies ath9k_htc to load the needed
firmware in an asynchronous manner, fixing timeouts
that were introduced with the new udev changes.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Whenever the PAN (P2P) context is active, it
has timers in the uCode that prevent sleep,
so scanning can't be out of channel for more
than the beacon interval programmed into the
device.

Before this patch, a full scan including any
passive channels when P2P was active would
stall forever because it wouldn't find time
to execute the passive requests (for default
beacon intervals of 100 TU.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Led has no use for some platform.
Add additional module parameter option to disable LED
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Fix multiple bugs in event tracing:

1) If you enable uCode tracing with the device down,
   it will still attempt to access the device and
   continuously log "MAC is in deep sleep!" errors.
   Fix this by only starting logging when the device
   is actually alive.

2) Now you can set the flag when the device is down,
   but logging doesn't happen when you bring it up.
   To fix that, start logging when the device comes
   alive. This means we don't log before -- we could
   do that but I don't need it right now.

3) For some reason we read the error instead of the
   event log -- use the right pointer.

4) Optimise SRAM reading of event log header.

5) Fix reading write pointer == capacity, which can
   happen due to racy SRAM access

6) Most importantly: fix an error where we would try
   to read WAY too many events (like 2^32-300) when
   we read the wrap counter before it is updated by
   the uCode -- this does happen in practice and will
   cause the driver to hang the machine.

7) Finally, change the timer to 10ms instead of 100ms
   as 100ms is too slow to capture all data with a
   normal event log and with 100ms the log will wrap
   multiple times before we have a chance to read it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Fix few places of typo
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Unted the assumption that the sta struct is still accessible before the
synchronize_rcu call we should move the num_sta_ps counter decrement
after synchronize_rcu to avoid incorrect decrements if num_sta_ps.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

* Handle MCS masks set by the user.
* Match rates provided by the rate control algorithm to the mask set,
  also in HT mode, and switch back to legacy mode if necessary.
* add debugfs files to observate the rate selection
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Allow to set mcs masks through nl80211. We also allow to set MCS
rates but no legacy rates (and vice versa).
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Although the rtlwifi family of devices contains 11 copies of the pr_fmt
macro, the macro is not defined for all routines that need it. By moving
the macro to wifi.h, a single copy is available for all routines.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If the driver blocked this specific STA with the help of
ieee80211_sta_block_awake we won't clear WLAN_STA_PS_STA later but
still decrement num_sta_ps. Hence, the next data frame from this
STA will trigger ap_sta_ps_end again and also decrement num_sta_ps
again leading to an incorrect num_sta_ps counter.

This can result in problems with powersaving clients not waking up
from PS because the TIM calculation might be skipped due to the
incorrect num_sta_ps counter.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When WLAN_STA_PS_DRIVER is set by ieee80211_sta_block_awake the
num_sta_ps counter is not incremented. Hence, we shouldn't decrement
it in __sta_info_destroy if only WLAN_STA_PS_DRIVER is set. This
could result in an incorrect num_sta_ps counter leading to strange side
effects with associated powersaving clients.

Fix this by only decrementing num_sta_ps when WLAN_STA_PS_STA was set
before.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

In the future, when we start notifying drivers,
state transitions could potentially fail. To make
it easier to distinguish between programming bugs
and driver failures:
 * rename sta_info_move_state() to
   sta_info_pre_move_state() which can only be
   called before the station is inserted (and
   check this with a new station flag).
 * rename sta_info_move_state_checked() to just
   plain sta_info_move_state(), as it will be
   the regular function that can fail for more
   than just one reason (bad transition or an
   error from the driver)

This makes the programming model easier -- one of
the functions can only be called before insertion
and can't fail, the other can fail.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This reverts commit f1e3be15.

Johannes Berg <johannes@sipsolutions.net> thinks that this patch is
incorrect.  I'll defer to his judgment.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The device seems to survive the issue, so no need to flood the logs
about it...
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Whenever the PAN (P2P) context is active, it
has timers in the uCode that prevent sleep,
so scanning can't be out of channel for more
than the beacon interval programmed into the
device.

Before this patch, a full scan including any
passive channels when P2P was active would
stall forever because it wouldn't find time
to execute the passive requests (for default
beacon intervals of 100 TU.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Led has no use for some platform.
Add additional module parameter option to disable LED
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>