When beacons get stuck in AP mode, the most likely cause is interference.
Such interference can often go on for a while, and too many consecutive
beacon misses can lead to connected clients getting dropped.

Since connected clients might not be subjected to the same interference
if that happens to be very local, the AP should try to deal with it as
good as it can. One way to do this is to trigger an NF calibration with
automatic baseband update right after the beacon miss. In my tests with
very strong interference, this allowed the AP to continue transmitting
beacons after only 2-3 misses, which allows a normal client to stay
connected.

With some of the newer - really sensitive - chips, the maximum noise
floor limit is very low, which can be problematic during very strong
interference. To avoid an endless loop of stuck beacons -> nfcal ->
periodic calibration -> stuck beacons, the beacon miss event also sets
a flag, which allows the calibration code to bypass the chip specific
maximum NF value. This flag is automatically cleared, as soon as the
first NF median goes back below the limits for all chains.

In my tests, this allowed an ath9k AP to survive very strong interference
(measured NF: -68, or sometimes even higher) without losing connectivity
to its clients. Even under these conditions, I was able to transmit
several mbits/s through the interface.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Stuck beacons are a useful indicator for debugging various PHY
issues such as calibration. Putting them on the same debug level
as the other beacon stuff makes it hard to spot them in huge amounts
of spam.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Only the IBSS manager, ie. the station that sent
the IBSS beacon last, should be replying to probe
responses. This requires implementing the mac80211
tx_last_beacon callback, which we can do thanks to
the ucode beacon notification.
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>

iwl_set_hw_params() only used by _agn, make it static
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Log the information after reading the PCI_REVISION_ID
from pci config space,
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwl_hw_detect() only used by _agn, make it static
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Split some long lines to make checkpatch.pl happy. ;-)
Signed-off-by: NThomas Klute <thomas2.klute@uni-dortmund.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NThomas Klute <thomas2.klute@uni-dortmund.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We do not need export iwl_bg.*scan.*() functions just for initialize
workqueue in other module. Making that functions static helps with
iwl-scan.c code review a bit.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Bring back the comment about FW v5 status codes from the pre-cfg80211
driver, and let through status codes that aren't remapped by the
firmware.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Make it a bit easier to debug scan results in the future.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This helps us debug channel changes better.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This function was exiting early if the existing diversity settings
were unchanged.  Unfortunately, in some cases the antenna configuration
is not initialized at all.

https://bugzilla.kernel.org/show_bug.cgi?id=14751Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>

...and unregistration to core shutdown.  Previously, the driver
remained registered even when the hardware was shutdown.  That
causes the driver to return -ENODEV if the b43 device is IFF_DOWN.
This change causes the driver to disappear in that case, allowing
/dev/hwrng to still function if another hwrng device is available.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/iwmc3200wifi/rx.c: In function 'iwm_ntf_wifi_if_wrapper':
drivers/net/wireless/iwmc3200wifi/rx.c:1198: warning: comparison is always true due to limited range of data type

This is, of course, because the value of WIFI_IF_NTFY_MAX is 0xff and
hdr->oid is a u8.  This is obviously an attempt to verify the range on
an input value, but since it has no effect it can simply be removed.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NSamuel Ortiz <samuel.ortiz@intel.com>

drivers/net/wireless/ipw2x00/ipw2100.c: In function 'ipw2100_tx_send_commands':
drivers/net/wireless/ipw2x00/ipw2100.c:3063: warning: cast to pointer from integer of different size

This changes the cast and the conversion to match other usage of the
same value in calls to IPW_DEBUG_TX.
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some iwlwifi devices inexplicably disconnect themselves from the PCI-E
bus causing the predictable failures.  This seems to disappear if ASPM
is disabled.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes the information available through ethtool...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes the information available through ethtool...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>

This makes the information available through ethtool...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes the information available through ethtool...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes the information available through ethtool...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Atheros PCIe wireless cards handled by ath5k do require L0s disabled.
For distributions shipping with CONFIG_PCIEASPM (this will be enabled
by default in the future in 2.6.36) this will also mean both L1 and L0s
will be disabled when a pre 1.1 PCIe device is detected. We do know L1
works correctly even for all ath5k pre 1.1 PCIe devices though but cannot
currently undue the effect of a blacklist, for details you can read
pcie_aspm_sanity_check() and see how it adjusts the device link
capability.

It may be possible in the future to implement some PCI API to allow
drivers to override blacklists for pre 1.1 PCIe but for now it is
best to accept that both L0s and L1 will be disabled completely for
distributions shipping with CONFIG_PCIEASPM rather than having this
issue present. Motivation for adding this new API will be to help
with power consumption for some of these devices.

Example of issues you'd see:

  - On the Acer Aspire One (AOA150, Atheros Communications Inc. AR5001
    Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well
    with ASPM enabled, the card will eventually stall on heavy traffic
    with often 'unsupported jumbo' warnings appearing. Disabling
    ASPM L0s in ath5k fixes these problems.

  - On the same card you would see a storm of RXORN interrupts
    even though medium is idle.

Credit for root causing and fixing the bug goes to Jussi Kivilinna.

Cc: David Quan <David.Quan@atheros.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tim Gardner <tim.gardner@canonical.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: stable@kernel.org
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch handles the firmware loading properly
for device ID 7015.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use appropriate command (CMD_TRIGGER_SCAN_TO) instead of scan command
(CMD_SCAN) to configure trigger scan timeout.

This was broken in commit 3a98c30f.

This fix address the bug reported here:

https://bugzilla.kernel.org/show_bug.cgi?id=16554

Cc: stable@kernel.org
Signed-off-by: NYuri Ershov <ext-yuri.ershov@nokia.com>
Signed-off-by: NYuri Kululin <ext-yuri.kululin@nokia.com>
Acked-by: NKalle Valo <kvalo@adurom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some APs advertise that they may be HT40 capable in the capabilites
but the current operating channel configuration may be only HT20.
This causes disconnection as ath9k_htc sets WLAN_RC_40_FLAG despite
the AP operating in HT20 mode.
Hence set this flag only if the current channel configuration
is HT40 enabled.

Cc: stable@kernel.org
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This should fix the oops which occurs during the packet injection
on monitor interface.

EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc]
 [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211]
 [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc]
 [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211]
 [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211]
 [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211]
 [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211]
 [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210
 [<c04b97c2>] ? __alloc_skb+0x52/0x130
 [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170
 [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0
 [<c0567e1e>] ? packet_snd+0x21e/0x250
 [<c05684a2>] ? packet_sendmsg+0x32/0x40
 [<c04b4c63>] ? sock_aio_write+0x113/0x130
 [<c0207934>] ? do_sync_write+0xc4/0x100
 [<c0167740>] ? autoremove_wake_function+0x0/0x50
 [<c02f4414>] ? security_file_permission+0x14/0x20
 [<c0207ad4>] ? rw_verify_area+0x64/0xe0
 [<c01e6458>] ? handle_mm_fault+0x338/0x390
 [<c0207cd5>] ? vfs_write+0x185/0x1a0
 [<c058db20>] ? do_page_fault+0x160/0x3a0
 [<c0208512>] ? sys_write+0x42/0x70
 [<c01033ec>] ? syscall_call+0x7/0xb
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is necessary to call pm_qos_add_request prior to calling
pm_qos_update_request.  It was revealed that ipw2100 has been
doing this wrong since "pm_qos: Get rid of the allocation in
pm_qos_add_request()" (commit 82f68251)
added a WARN that results in the following backtrace:

WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x5e/0x70()
pm_qos_update_request() called for unknown object
Call Trace:
[<c1024088>] ? warn_slowpath_common+0x78/0xb0
[<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
[<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
[<c1024153>] ? warn_slowpath_fmt+0x33/0x40
[<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
[<f89fe15f>] ? ipw2100_up+0x3f/0xf10 [ipw2100]
[<c11961c9>] ? vsnprintf+0xc9/0x530
[<f89ff36c>] ? ipw2100_net_init+0x2c/0x1c0 [ipw2100]
[<c12f542d>] ? register_netdevice+0x7d/0x3c0
[<f89f9b00>] ? ipw2100_irq_tasklet+0x910/0x9a0 [ipw2100]
[<c12f579f>] ? register_netdev+0x2f/0x40
[<f89fd471>] ? ipw2100_pci_init_one+0xd21/0x1060 [ipw2100]
[<c11a5ebb>] ? local_pci_probe+0xb/0x10
[<c11a6d49>] ? pci_device_probe+0x69/0x90
[<c1224704>] ? driver_probe_device+0x74/0x180
[<c10dd15a>] ? sysfs_create_dir+0x6a/0xb0
[<c1224889>] ? __driver_attach+0x79/0x80
[<c1224810>] ? __driver_attach+0x0/0x80
[<c1223fa2>] ? bus_for_each_dev+0x52/0x80
[<c1224586>] ? driver_attach+0x16/0x20
[<c1224810>] ? __driver_attach+0x0/0x80
[<c122395f>] ? bus_add_driver+0x17f/0x250
[<c11a5ec0>] ? pci_device_shutdown+0x0/0x20
[<c11a6c80>] ? pci_device_remove+0x0/0x40
[<c1224b13>] ? driver_register+0x63/0x120
[<c11a6f96>] ? __pci_register_driver+0x36/0xa0
[<f84f9048>] ? ipw2100_init+0x48/0x67 [ipw2100]
[<c1001122>] ? do_one_initcall+0x32/0x170
[<c1087078>] ? __vunmap+0xb8/0xf0
[<f84f9000>] ? ipw2100_init+0x0/0x67 [ipw2100]
[<c10510c1>] ? sys_init_module+0x161/0x1000
[<c108f847>] ? sys_close+0x67/0xe0
[<c13647c1>] ? syscall_call+0x7/0xb

This patch moves pm_qos_add_request prior to pci_register_driver in
ipw2100 in order to avoid this problem.
Reported-by: NChristoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the driver will try to protect all frames,
which leads to a lot of odd things like sending an
RTS with a zeroed RA before multicast frames, which
is clearly bogus.

In order to fix all of this, we need to take a step
back and see what we need to achieve:
 * we need RTS/CTS protection if requested by
   the AP for the BSS, mac80211 tells us this
 * in that case, CTS-to-self should only be
   enabled when mac80211 tells us
 * additionally, as a hardware workaround, on
   some devices we have to protect aggregated
   frames with RTS

To achieve the first two items, set up the RXON
accordingly and set the protection required flag
in the transmit command when mac80211 requests
protection for the frame.

To achieve the last item, set the rate-control
RTS-requested flag for all stations that we have
aggregation sessions with, and set the protection
required flag when sending aggregated frames (on
those devices where this is required).

Since otherwise bugs can occur, do not allow the
user to override the RTS-for-aggregation setting
from sysfs any more.

Finally, also clean up the way all these flags get
set in the driver and move everything into the
device-specific functions.

Cc: stable@kernel.org [2.6.35]
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>

  CC [M]  drivers/net/wireless/libertas/cfg.o
/home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c: In function ‘lbs_scan_worker’:
/home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: ‘TASK_NORMAL’ undeclared (first use in this function)
/home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: (Each undeclared identifier is reported only once
/home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: for each function it appears in.)
/home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c: In function ‘lbs_cfg_connect’:
/home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
/home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: implicit declaration of function ‘signal_pending’
/home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: implicit declaration of function ‘schedule_timeout’
Reported-by: NBen Greear <greearb@candelatech.com>
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit 5f7aebd8.

Apparently, that PCI ID data was incorrectly taken from the subsystem
information.  The actual ID matches another already known ID.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Based on patches from Sonny Rao and Milton Miller...

Combined the patches to fix up clean_tx_irq and clean_rx_irq.

The PowerPC architecture does not require loads to independent bytes
to be ordered without adding an explicit barrier.

In ixgbe_clean_rx_irq we load the status bit then load the packet data.
With packet split disabled if these loads go out of order we get a
stale packet, but we will notice the bad sequence numbers and drop it.

The problem occurs with packet split enabled where the TCP/IP header
and data are in different descriptors. If the reads go out of order
we may have data that doesn't match the TCP/IP header. Since we use
hardware checksumming this bad data is never verified and it makes it
all the way to the application.

This bug was found during stress testing and adding this barrier has
been shown to fix it.  The bug can manifest as a data integrity issue
(bad payload data) or as a BUG in skb_pull().

This was a nasty bug to hunt down, if people agree with the fix I think
it's a candidate for stable.

Previously Submitted to e1000-devel only for ixgbe

http://marc.info/?l=e1000-devel&m=126593062701537&w=3

We've now seen this problem hit with other device drivers (e1000e mostly)
So I'm resubmitting with fixes for other Intel Device Drivers with
similar issues.

CC: Milton Miller <miltonm@bga.com>
CC: Anton Blanchard <anton@samba.org>
CC: Sonny Rao <sonnyrao@us.ibm.com>
CC: stable <stable@kernel.org>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Building ixgbe without DCB_CONFIG and FCOE_CONFIG will cause
a build error.  This resolves the build error by wrapping
the fcoe.up in CONFIG_IXGBE_DCB ifdefs.

Also frames were being priority VLAN tagged even without DCB
enabled.  This fixes this so that 8021Q priority tags are
only added with DCB actually enabled.
Reported-by: Ndivya <dipraksh@linux.vnet.ibm.com>
Reported-by: NJon Mason <jon.mason@exar.com>
Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
Tested-by: NStephen Ko <stephen.s.ko@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAmit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

spin_is_locked() can return zero on some (UP?)
configurations because locks don't exist, and
that causes an endless amount of warnings. Use
lockdep_assert_held() instead, which has two
advantages:
 1) it verifies the current task is holding
    the lock or mutex
 2) it compiles away completely when lockdep
    is not enabled

Cc: stable@kernel.org [2.6.34+, maybe only parts of patch]
Reported-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The TX tracing code copies with the wrong length,
which will typically copy too little data. Fix
this by using the correct length variable.

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