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: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Frames that failed PLCP error checks are most likely
microwave transmissions (well, maybe not ...) and
don't have a proper rate detected, so ignore it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John 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: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

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

When running in client mode and associating to an AP, the channel
change is usually performed with the offchannel flag still set.
However after the assoc is complete, the following channel change event
is suppressed because the run time channel is already set to the operating channel.
Fix this by sending channel change notifications to the driver even if
only the offchannel flag changes.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: John W. Linville <linville@tuxdriver.com>
Acked-by: Ivo 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: John 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: John W. Linville <linville@tuxdriver.com>
Acked-by: Samuel 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John 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: John W. Linville <linville@tuxdriver.com>

This provides a little more flexibility for human users, and it allows
us to use isalpha rather than the custom is_alpha_upper.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

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

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

This patch implement basic infrastructure to support use of NAPI by
mac80211-based hardware drivers.

Because mac80211 devices can support multiple netdevs, a dummy netdev
is used for interfacing with the NAPI code in the core of the network
stack.  That structure is hidden from the hardware drivers, but the
actual napi_struct is exposed in the ieee80211_hw structure so that the
poll routines in drivers can retrieve that structure.  Hardware drivers
can also specify their own weight value for NAPI polling.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

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

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

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

This makes the information available through ethtool...
Signed-off-by: John 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: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch handles the firmware loading properly
for device ID 7015.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John 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: Yuri Ershov <ext-yuri.ershov@nokia.com>
Signed-off-by: Yuri Kululin <ext-yuri.kululin@nokia.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John 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: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John 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: Rajkumar Manoharan <rmanoharan@atheros.com>
Cc: stable@kernel.org
Signed-off-by: John 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: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on
the default L2CAP MTU.  That default MTU is calculated from the size
of two DH5 packets, minus ACL and L2CAP b-frame header overhead.

ERTM is used with newer basebands that typically support larger 3-DH5
packets, and i-frames and s-frames have more header overhead.  With
clean RF conditions, basebands will typically attempt to use 1021-byte
3-DH5 packets for maximum throughput.  Adjusting for 2 bytes of ACL
headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes
of payload.

This PDU size imposes less overhead for header bytes and gives the
baseband the option to choose 3-DH5 packets, but is small enough for
ERTM traffic to interleave well with other L2CAP or SCO data.
672-byte payloads do not allow the most efficient over-the-air
packet choice, and cannot achieve maximum throughput over BR/EDR.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

remote_tx_win is intended to be set on receipt of an L2CAP
configuration request.  The value is used to determine the size of the
transmit window on the remote side of an ERTM connection, so L2CAP
can stop sending frames when that remote window is full.

An incorrect remote_tx_win value will cause the stack to not fully
utilize the tx window (performance impact), or to overfill the remote
tx window (causing dropped frames or a disconnect).

This patch removes an extra setting of remote_tx_win when a
configuration response is received.  The transmit window has a
different meaning in a response - it is an informational value
less than or equal to the local tx_win.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The L2CAP specification requires that the ERTM retransmit timeout be at
least 2 seconds for BR/EDR connections.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Incoming configuration values must be converted to native CPU order
before use.  This fixes a bug where a little-endian MPS value is
compared to a native CPU value.  On big-endian processors, this
can cause ERTM and streaming mode segmentation to produce PDUs
that are larger than the remote stack is expecting, or that would
produce fragmented skbs that the current FCS code cannot handle.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

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: 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>

Accesses to "wdev->current_bss" must be
locked with the wdev lock, which action
frame transmission is missing.

Cc: stable@kernel.org [2.6.33+]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John 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: Ben Greear <greearb@candelatech.com>
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John 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: John W. Linville <linville@tuxdriver.com>

Adds documentation for the igbvf (igb virtual function driver).

  v2:
   - Removed trailing white space
   - Removed Ethtool version info
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add documentation for the igb networking driver.

  v2:
   - Removed trailing white space
   - Removed Ethtool version info
   - Removed LRO kernel version info
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>