On 8366, bit 6 in the rx descriptor rate field indicates whether the
packet was received on a 20MHz or 40MHz channel, and is not part of
the MCS index.  Handle this properly, which then prevents hitting the
WARN_ON and being dropped in ieee80211_rx().
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When inserting a DMA header into a packet for transmission,
mwl8k_add_dma_header() would blindly zero the addr4 field, which
is not a good idea if the packet being transmitted is actually a
4-address packet.

Also, if the transmitted packet was a 4-address with QoS packet,
the memmove() to do the needed header reshuffling would inadvertently
overwrite the first two bytes of the packet payload with the QoS field.

This fixes both of these issues.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Packets exchanged between the mwl8k driver and the firmware always
have a 4-address header without QoS field.  For QoS packets, the QoS
field is passed to/from the firmware via the tx/rx descriptors.

We were handling this correctly on transmit, but not on receive -- if
a QoS packet was received, we would leave garbage in the QoS field in
the packet passed up to the stack, which is Bad(tm).

Also, if the packet received on the air was a 4-address without QoS
packet, we would forget to skb_pull the 2-byte DMA length prefix off.

This patch adds an argument to the ->rxd_process() receive descriptor
operation to retrieve the QoS field from the receive descriptor, and
extends mwl8k_remove_dma_header() to insert this field back into the
packet if the packet received is a QoS packet.  It also fixes
mwl8k_remove_dma_header() to strip off the length prefix in all cases.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There exist 12 802.11b/g rates, but mwl8k supports two additional
(non-standard) rates, and includes those rates in rate bitmasks and
in its internal rate table that hardware rate indices index.

Commit "mwl8k: report rate and other information for received frames"
added one of the nonstandard rates to the mwl8k_rates table to make
the OFDM rates in the table line up with the rate indices that are
reported in the receive descriptor (so that we can just simply copy
the receive descriptor rate index into ieee80211_rx_status::rate_idx)
and bumped MWL8K_IEEE_LEGACY_DATA_RATES from 12 to 13, but this
screwed up the UPDATE_STADB command struct layout, as it also uses
that define, for its legacy_rates array.

To avoid having to convert rate indices and legacy rate bitmaps (e.g.
ieee80211_bss_conf::basic_rates) between the 12-rate mac80211 format
and the 14-rate mwl8k format, we'll report all 14 rates in our wiphy's
band, but filter out the nonstandard ones e.g. in the case of the
UPDATE_STADB command which only accepts 12 rates.

In the commands that accept 14 rates (SET_AID, SET_RATE), replace the
use of the MWL8K_RATE_INDEX_MAX_ARRAY define in the command struct by
the constant 14, to make it clearer that these commands accept 14 rates.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The MCS bitmaps in the SET_RATE command structure were of the wrong
size, due to use of the wrong define for the array length.  Just
hardcode the lengths as 16, and do the same for the MCS bitmaps in
other command structures.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The bssid can be zero when null data template is set in wl1251_op_config().
It's enough, and especially safe, to set it once after association.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

bssid needs to be copied first in wl1251_op_bss_info_changed(), otherwise
templates will have incorrect bssid and power save will not work
correctly.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There was a warning from wl1251_op_bss_info_changed():

wl1251: WARNING Set ctsprotect failed 0

It was printed always, it's completely false and can be removed.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

CC [M]  drivers/net/wireless/iwlwifi/iwl-tx.o
drivers/net/wireless/iwlwifi/iwl-tx.c: In function ‘iwl_tx_agg_stop’:
drivers/net/wireless/iwlwifi/iwl-tx.c:1356: warning: passing argument 1 of ‘ieee80211_stop_tx_ba_cb_irqsafe’ from incompatible pointer type
include/net/mac80211.h:2128: note: expected ‘struct ieee80211_vif *’ but argument is of type ‘struct ieee80211_hw *’
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When debugging the wifi firmware, we need to disable the wimax core to gain
some memory space. The default value will keep the wimax core enabled.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Wifi and wimax coexistence mode is set by wifi at boot time. There can be
several modes, defined by priority tables. User space components can decide
which one to select by writing to /sys/module/iwmc3200wifi/parameters/wiwi
with this patch, before bringing the interface up.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When sending the wiwi coexistence priority table, we should not tell the LMAC
that we want a response.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This update follows the firmware engineers recommendations.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The driver version number is a remnant from when there was an out-of-tree
iwlwifi driver. Now that the driver forms part of kernel source we do not
need a separate driver version. Instead, we now use the kernel version as
driver version. We maintain the previous tags used to indicate which
components the driver has been compiled with.
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>

error_event_table_ptr is only set upon receipt of REPLY_ALIVE. Until
then both event log and error log will fail. Add information to indicate
which uCode encounter the failure case.
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>

In the process of improving uCode event logging capability, the new
implementation was introduced without removing the existing
implementation. The event log will be dumped to dmesg twice.
Remove the old implementation to only log the event once upon sys
assert or request by user.
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>

My gcc appears to be able to see past the function
boundary and notices that the variable 'behaviour'
could be used uninitialised:

drivers/net/wireless/b43/leds.c: In function ‘b43_leds_register’:
drivers/net/wireless/b43/leds.c:339: warning: ‘behaviour’ may be used uninitialized in this function
drivers/net/wireless/b43/leds.c: In function ‘b43_leds_init’:
drivers/net/wireless/b43/leds.c:262: warning: ‘behaviour’ may be used uninitialized in this function

because b43_led_get_sprominfo() didn't initialise
it in all cases.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add PCI .shutdown method so that we can disable the device during
shutdown or reboot. Without this, the reboot doesn't work well on
some platforms.

This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2124Tested-by: Npablo <pablolm2005@gmail.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When handling IWM_CMD_PMKID_FLUSH command, the bssid and
pmkid in pmksa are all NULL. Check it before memcpy.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Acked-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently, the 2GHz band is enabled unconditionally, even if the device
does not support it.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On BigEndian gcc complains:

drivers/net/wireless/airo.c: In function ‘sniffing_mode’:
drivers/net/wireless/airo.c:4809: warning: integer overflow in expression

Fix this by doing the bitwise AND on the host-endian value.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While reviewing the l2pad function to align both the header and the payload
on a DMA-capable boundary a bug was discovered where the payload would not
be properly aligned. The header_align value was used where the payload_align
value should have been used.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For PPC architecture with PHY Revision < 3, a read of the register
B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43legacy_status()
returns a value of 2 (B43legacy_STAT_STARTED); however, one finds that
the driver is unable to associate after resuming from hibernation unless
this routine returns 1. To satisfy both conditions, the routine is rewritten
to return TRUE whenever b43legacy_status() returns a value < 2.

This patch fixes the second problem listed in the postings for Red Hat
Bugzilla #538523.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The routine b43_is_hw_radio_enabled() has long been a problem.
For PPC architecture with PHY Revision < 3, a read of the register
B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43_status()
returns a value of 2 (B43_STAT_STARTED) (BUG 14181). Fixing that
results in Bug 14538 in which the driver is unable to reassociate
after resuming from hibernation because b43_status() returns 0.

The correct fix would be to determine why the status is 0; however,
I have not yet found why that happens. The correct value is found for
my device, which has PHY revision >= 3.

Returning TRUE when the PHY revision < 3 and b43_status() returns 0 fixes
the regression for 2.6.32.

This patch fixes the problem in Red Hat Bugzilla #538523.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Tested-by: NChristian Casteyde <casteyde.christian@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Lennert Buytenhek noticed that delBA handling in mac80211
was broken and has remotely triggerable problems, some of
which are due to some code shuffling I did that ended up
changing the order in which things were done -- this was

  commit d75636ef
  Author: Johannes Berg <johannes@sipsolutions.net>
  Date:   Tue Feb 10 21:25:53 2009 +0100

    mac80211: RX aggregation: clean up stop session

and other parts were already present in the original

  commit d92684e6
  Author: Ron Rindjunsky <ron.rindjunsky@intel.com>
  Date:   Mon Jan 28 14:07:22 2008 +0200

      mac80211: A-MPDU Tx add delBA from recipient support

The first problem is that I moved a BUG_ON before various
checks -- thereby making it possible to hit. As the comment
indicates, the BUG_ON can be removed since the ampdu_action
callback must already exist when the state is != IDLE.

The second problem isn't easily exploitable but there's a
race condition due to unconditionally setting the state to
OPERATIONAL when a delBA frame is received, even when no
aggregation session was ever initiated. All the drivers
accept stopping the session even then, but that opens a
race window where crashes could happen before the driver
accepts it. Right now, a WARN_ON may happen with non-HT
drivers, while the race opens only for HT drivers.

For this case, there are two things necessary to fix it:
 1) don't process spurious delBA frames, and be more careful
    about the session state; don't drop the lock

 2) HT drivers need to be prepared to handle a session stop
    even before the session was really started -- this is
    true for all drivers (that support aggregation) but
    iwlwifi which can be fixed easily. The other HT drivers
    (ath9k and ar9170) are behaving properly already.
Reported-by: NLennert Buytenhek <buytenh@marvell.com>
Cc: stable@kernel.org
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We need to implement the PMKSA API for proper WPA2 pre-auth and fast
re-association. Our fullmac device generates all (re-)assoc IEs, and thus it
needs the right PMKIDs. With this implementation we now get them from
wpa_supplicant.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In my setups, ath9k's debugfs files are most of the time much more
useful than the messages generated by enabling CONFIG_ATH_DEBUG along
with the right debug flags.
Since CONFIG_ATH_DEBUG comes with a noticeable overhead on embedded
systems, this patch makes it possible to use the debugfs files without
that option.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This moves mesh initialization, start/stop and rx/tx handling from
into mesh.c.
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mesh.c will be the file where we concentrate all mesh-related
code. This allows us to either add a KConfig entry for mesh and
makes matters easier for the cfg80211 transition.
Signed-off-by: NHolger Schurig <holgerschurig@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Update the beacon queue parameters with best effort queue parameters for
IBSS mode. This reduces the number of beacons generated by ath9k and
ensures a fair beacon distribution when there are multiple IBSS stations.
Also CWmin is quadrupled to achieve the expected percentage of
distribution.
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO
buffer size of that of dual stream devices. Dual stream devices
have a max PCU TX FIFO size of 8 KB while single stream devices
have 4 KB. Single stream devices have an issue though and require
hardware only to use half of the amount of its capable PCU TX FIFO
size, 2 KB and this requires a change in software.

Technically a change would not have been required (except for frame
burst considerations of 128 bytes) if these devices would have been
able to use the full 4 KB of the PCU TX FIFO size but our systems
engineers recommend 2 KB to be used only. We enforce this through
software by reducing the max frame triggger level to 2 KB.

Fixing the max frame trigger level should then have a few benefits:

  * The PER will now be adjusted as designed for underruns when the
    max trigger level is reached. This should help alleviate the
    bus as the rate control algorithm chooses a slower rate which
    should ensure frames are transmitted properly under high system
    bus load.

  * The poll we use on our TX queues should now trigger and work
    as designed for single stream devices. The hardware passes
    data from each TX queue on the PCU TX FIFO queue respecting each
    queue's priority. The new trigger level ensures this seeding of
    the PCU TX FIFO queue occurs as designed which could mean avoiding
    false resets and actually reseting hw correctly when a TX queue
    is indeed stuck.

  * Some undocumented / unsupported behaviour could have been triggered
    when the max trigger level level was being set to 4 KB on single
    stream devices. Its not clear what this issue was to me yet.

Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com>
Cc: Stephen Chen <stephen.chen@atheros.com>
Cc: Shan Palanisamy <shan.palanisamy@atheros.com>
Cc: Paul Shaw <paul.shaw@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Software padding is done on the TX path and software unpadding is done on the
RX path. This patch corrects the position where the padding occurs. A specific
function computes the pad position and this function is used in the TX and RX
path. This patch has been tested by generating every possible 802.11 frames
with every possible frame_control field and a varying length. This patch is
useful for analyzing non standard 802.11 frames going over the air
Signed-off-by: NBenoit Papillault <benoit.papillault@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When mac80211 was telling us to go into Powersave we listened
and immediately turned RX off. This meant hardware would not
see the ACKs from the AP we're associated with and hardware
we'd end up retransmiting the null data frame in a loop
helplessly.

Fix this by keeping track of the transmitted nullfunc frames
and only when we are sure the AP has sent back an ACK do we
go ahead and shut RX off.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NVivek Natarajan <Vivek.Natarajan@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The tx concatenation option works fine now, we no longer need the debugging
option of disabling concatenation.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We add the stopped queue count and display to the tx queue debugfs entry.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>