The patch
rt2x00: Optimize register access in rt2800pci
from Helmut Schaa missed one register call, namely
the rt2800_register_multiwrite which should be changed
to rt2x00pci_register_multiwrite.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add recycling functionality to rt2x00usb_register_read_async.
When the callback function returns true, resubmit the urb to
read the register again.
This optimizes the rt2800usb driver when multiple TX status reports
are pending in the register, because now we don't need to allocate
the rt2x00_async_read_data and urb structure each time.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When no TX status was available, the default timeout
of 20ms is a bit high. The frame is highly likely already
send out, so the TX status should be available within
only a few milliseconds.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If an interface type changes from a type that is
only supported on the PAN context (e.g. P2P GO)
to a type that is supported on the BSS context,
and the BSS context is not in use, then we need
to use the BSS context instead of changing the
device type within the context. To achieve this,
refuse the type change, which causes a down/up
cycle that will allocate the BSS context for the
interface.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The current RXON checking doesn't verify that
the channel is valid (or at least non-zero),
so add that. Also, add a WARN() so we get a
stacktrace, and capture a bitmask of errors
in order to capture all necessary information
in the warning itself (in case the previous
messages are snipped off.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This header file isn't used, and if we ever need
these definitions they shouldn't be added to a
driver but rather to the common 802.11 include
file that has all frame definitions. Thus, just
remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
All agn devices use the same eeprom semaphore and calib version routines.
Delete the indirection and move the semaphore routines to where they are
used and make static.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
All agn devices use the same module parameter structure. Delete the
indirection and access the structure diretly.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
New microcode versions use the good CRC threshold
field differently, as a flag, and in that case we
should set it to 1/0 instead of 1/65535 for an
active/passive scan.
The new behaviour is advertised by the uCode with
a feature flag.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
No functional changes, separate the connect and disconnect sequences in
RXON commit function, easier to read and understand.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The WoWLAN resume code will have to essentially
do a restart, but without going through the work
struct. To support that, refactor the restart by
splitting out the preparation code into a new
function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
There are a few cases like the WoWLAN support
I'm writing that require attempting to access
the NIC when it is known that it might not be
accessible, e.g. after the system woke up and
the platform might have reset the device.
To avoid messages in this case, introduce the
new function iwl_grab_nic_access_silent(), it
will only return an error status.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
If a device error happens while the uCode is
being loaded or initialised, we will attempt
to restart the device (which will likely fail
again, but that's not the issue here). During
this new restart, we turn off the device, but
as the uCode failed to initialise it already
is turned off. As a consequence, grabbing NIC
access will fail and cause excessive messages
and hangs.
To fix this issue, introduce a new status bit
and only attempt to reprogram the device when
it isn't already disabled.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The tx_headroom required for mwl8k driver is 32 bytes and it
can use the space for 802.11 header received from mac80211.
mwl8k considers the smallest 802.11 frame (CTS2self of 10
bytes) that can be received from mac80211 to compute the
extra_tx_headroom as 22 (32 - 10) bytes.
When the wireless interface is part of bridge, this
extra_tx_headroom requirement results in a memcpy in
mac80211 (in function pskb_expand_head) for all the data
frames needing L2 forwarding/bridging, when NET_SKB_PAD is
defined as 32. This patch reduces the extra_tx_headroom by
8 bytes so that memcpy of data frames in mac80211 is
avoided in this case.
The resize will be required in driver for frames with 802.11
header size of less than 18 bytes.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove all the convoluted hacks in the driver and simplify things
by making use of mac80211's LED triggers.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We now use priv->mutex to serialize sync command, remove old
priv->sync_cmd_mutex and add assertion that priv->mutex must be locked.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check status bits with mutex taken, because when we wait for mutex
unlock, status can change. Patch should also make remaining sync
commands be send with priv->mutex taken. That will prevent execute
these commands when we are currently reset firmware, what could
possibly cause troubles.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We mark command as huge by using meta->flags from other (non huge) command,
but flags can be possibly overridden, when non huge command is enqueued,
what can lead to:
WARNING: at lib/dma-debug.c:696 dma_debug_device_change+0x1a3/0x1f0()
DMA-API: device driver has pending DMA allocations while released from device [count=1]
To fix introduce additional CMD_MAPPED to mark command as mapped and
serialize iwl_enqueue_hcmd() with iwl_tx_cmd_complete() using
hcmd_lock. Serialization will also fix possible race conditions,
because q->read_ptr, q->write_ptr are modified/used in parallel.
Do not change callback, I did (and fixed) that mistake in iwlagn.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
struct iwl_queue is not part of firmware interface, so __packed is not
needed. Remove it since is may affect performance.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We never set STATUS_SCANNING in softwre scanning mode, disable_hw_scan
check is unneeded. Correct debug message while at it.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't need to use conditional as ch->band is already assigned to
IEEE80211_BAND_5GHZ or IEEE80211_BAND_2GHZ
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add two below iwlwifi commits to iwlegacy:
commit 554d1d027b
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Thu Dec 23 12:38:21 2010 +0100
iwlagn: enable only rfkill interrupt when device is down
commit 3dd823e6b8
Author: Don Fry <donald.h.fry@intel.com>
Date: Sun Feb 6 09:29:45 2011 -0800
iwlagn: Re-enable RF_KILL interrupt when down
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since
commit f844a709a7
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Fri Jan 28 16:47:44 2011 +0100
iwlwifi: do not set tx power when channel is changing
we set device tx power during initialization to priv->tx_power_next,
which itself is initialized to minimum power. That changed
default behaviour of driver. Previously we initialized device to
transmit at maximum available power by default. Patch change again
to previous behaviour and cleanup tx power initialization.
Fortunately this is not critical fix, as mac80211 layer setup
tx power lately to 14dB, hence device does not operate at minimal
transmit power all the time.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/p54/eeprom.o
drivers/net/wireless/p54/eeprom.c: In function ‘p54_parse_rssical’:
drivers/net/wireless/p54/eeprom.c:494:8: warning: ‘freq’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/mwifiex/join.o
drivers/net/wireless/mwifiex/join.c: In function ‘mwifiex_cmd_802_11_associate’:
drivers/net/wireless/mwifiex/join.c:119:8: warning: ‘tsf_val’ may be used uninitialized in this function
drivers/net/wireless/mwifiex/join.c:103:12: note: ‘tsf_val’ was declared here
Looks like a copy-n-paste error, identical lines are a few lines below
the ones removed, with an actual memcpy to tsf_val in between...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/b43/phy_n.o
drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_set_channel’:
drivers/net/wireless/b43/phy_n.c:3848:47: warning: ‘tabent_r2’ may be used uninitialized in this function
drivers/net/wireless/b43/phy_n.c:3849:47: warning: ‘tabent_r3’ may be used uninitialized in this function
drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_poll_rssi.clone.14’:
drivers/net/wireless/b43/phy_n.c:2270:6: warning: ‘save_regs_phy$7’ may be used uninitialized in this function
drivers/net/wireless/b43/phy_n.c:2270:6: warning: ‘save_regs_phy$8’ may be used uninitialized in this function
FWIW, the usage of these variables is goverened by checks that match
their initializations. So, I think these are actually false warnings.
Still, I would rather avoid the warning SPAM...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/ath/ath5k/reset.o
drivers/net/wireless/ath/ath5k/reset.c: In function ‘ath5k_hw_init_core_clock’:
drivers/net/wireless/ath/ath5k/reset.c💯51: warning: ‘txf2txs’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since timestamp in beacon buffer keeps changing all the time,
the memcmp check in mwifiex_save_curr_bcn() is redundant.
Remove that memcmp check and also avoid freeing and allocation
of buffer if required beacon buffer size is same as previous one.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
1) Initialise HT capabilities in cfg80211 properly.
2) Cfg80211 stack may modify "sband->ht_cap" to disable
40Mhz operation in 2.4GHz band (after recent patch
"cfg80211: module_param to disable HT40 in 2.4GHz band")
Therefore read "sband->ht_cap" instead of an adapter variable
"hw_dot_11n_dev_cap" to get HT capabilities.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are some SD8787 cards which don't support 5GHz band.
Therefore initialise 5GHz band parameters only if hardware
supports the band.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AFAICT, this driver is claiming that 24 bits of rate info fit into a
16-bit field in the Tx descriptor. Anyway, the use of bitfields is
frowned-upon for a variety of well-documented reasons...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This callback is used to set the minimum rate for management
frames.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds WMI_BITRATE_MASK_CMDID which can be
used by the set_bitrate_mask() handler.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bump the firmware version to 1.2
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Convert all libertas/ files to use kernel-doc notation instead
of whatever it was (doxygen?).
Add or fix function parameters in several places.
Use expected style for multi-line comments in lots of places.
Remove erroneous /** in multiple places.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In AP mode we register for the MAX_TX_RETRY and INACTIVE_STA events.
Both are reported to the upper layers as a TX failure in the offending
stations.
In STA mode we register only for the MAX_TX_RETRY event. A TX failure is
interpreted as a loss of connection.
Support for IEEE80211_HW_REPORTS_TX_ACK_STATUS has been removed to avoid
the inherent race condition of a mac80211 TX failure counter in addition
to the FW counter.
This patch depends on "mac80211: allow low level driver to report packet
loss"
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
