defines shouldn't be terminated with a
semicolon, the code using them should
supply it. Luckily these are not used
in a context where it matters.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Since the ibss_beacon variable will only be
filled in the appropriate modes, there's no
reason to be checking the mode again.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Some devices may have multiple MAC
addresses in their EEPROM, read them
and advertise them to cfg80211.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This function is only needed in the same
file it is defined in, i.e. iwl-core.c
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
gcc complains about the firmware loading:
iwl-agn.c: In function ‘iwlagn_load_firmware’:
iwl-agn.c:1860: warning: ‘tlv_len’ may be used uninitialized in this function
iwl-agn.c:1861: warning: ‘tlv_type’ may be used uninitialized in this function
iwl-agn.c:1862: warning: ‘tlv_data’ may be used uninitialized in this function
This is almost correct but we do do break out of the TLV
parsing loop when setting ret. However, the code is hard
to follow, and clearly even the compiler is having issues
with it too.
Additionally, however, the current code is wrong. If there
is a TLV length check error, the code will report
invalid TLV after parsing: ...
because "len" will still be non-zero as we broke out of
the loop.
So to remove the warning and fix that issue, make the code
easier to read by doing length checking with an error label.
As a result, we can completely remove the "ret" variable.
Also, while at it, remove the "fixed_tlv_size" variable
since each TLV type has its own specified length, it just
happens that we have only variable length, flags (0 length)
and u32 TLVs right now. It should still be checked with more
explicit length checks to make it easier to understand.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Different devices have different size of phy calibration table; add
new TLV to specify the size. If the TLV is not part of uCode header, the
default table size will be used to make sure the backward
compatibilities.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
WiFi/BT combo devices has different statistics notification
structure, adding the support here to make sure the structure
align correctly.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Only WiFi/BT combo devices need to use bluetooth version of statistics
notification; adding the flag in .cfg file to indicate the need for
using different data structure.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
If its WiFi/BT combo device, the statistics notification sent by
uCode will include the additional BT related statistics counters.
Adding new data structure to support the new layout.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
CHECK drivers/net/wireless/b43/main.c
drivers/net/wireless/b43/main.c:111:5: warning: symbol 'b43_modparam_pio' was not declared. Should it be static?
CHECK drivers/net/wireless/b43/phy_g.c
drivers/net/wireless/b43/phy_g.c:975:56: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
CHECK drivers/net/wireless/b43/phy_lp.c
drivers/net/wireless/b43/phy_lp.c:2701:6: warning: symbol 'b43_lpphy_op_switch_analog' was not declared. Should it be static?
drivers/net/wireless/b43/phy_lp.c:1148:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
drivers/net/wireless/b43/phy_lp.c:1525:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
drivers/net/wireless/b43/phy_lp.c:1529:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
CHECK drivers/net/wireless/b43/wa.c
drivers/net/wireless/b43/wa.c:385:60: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:403:55: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:405:55: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:415:71: warning: cast truncates bits from constant value (ffff0fff becomes fff)
AFAICT, none of these amount to real bugs. But this reduces warning
spam from sparse w/o significantly affecting readability of the code (IMHO).
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The existing code seemed to be somewhat based on the datasheet, but
varied substantially from the vendor-provided driver. This mirrors the
handling of the rtl8185 case from that driver, but still neglects the
specifics for the rtl8180 hardware. Those details are a bit muddled...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:1541:21: expected restricted __le16 [usertype] result
drivers/net/wireless/mwl8k.c:1541:21: got int
drivers/net/wireless/mwl8k.c:1575:42: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1575:42: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1587:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1587:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1592:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1592:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1845:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1845:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1848:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1851:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1854:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1857:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1860:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:3055:20: expected restricted __le16 [usertype] ht_caps
drivers/net/wireless/mwl8k.c:3055:20: got unsigned short [unsigned] [usertype] cap
At least the last one looks like a real bug...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
CHECK drivers/net/wireless/rt2x00/rt2x00debug.c
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: warning: incorrect type in assignment (different base types)
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: expected restricted __le32 [usertype] chip_rev
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: got restricted __le16 [usertype] <noident>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
CHECK drivers/net/wireless/ipw2x00/libipw_module.c
drivers/net/wireless/ipw2x00/libipw_module.c:65:21: warning: symbol 'libipw_config_ops' was not declared. Should it be static?
drivers/net/wireless/ipw2x00/libipw_module.c:66:6: warning: symbol 'libipw_wiphy_privid' was not declared. Should it be static?
CHECK drivers/net/wireless/ipw2x00/libipw_wx.c
drivers/net/wireless/ipw2x00/libipw_wx.c:415:17: warning: symbol 'ssid' shadows an earlier one
drivers/net/wireless/ipw2x00/libipw_wx.c:324:9: originally declared here
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CHECK drivers/net/wireless/ipw2x00/ipw2100.c
drivers/net/wireless/ipw2x00/ipw2100.c:177:28: warning: symbol 'ipw2100_pm_qos_req' was not declared. Should it be static?
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drivers/net/wireless/ath/ath9k/main.c:282:26: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath9k/main.c:282:26: expected restricted __le16 [usertype] duration_id
drivers/net/wireless/ath/ath9k/main.c:282:26: got int
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ever since
commit e1b3ec1a2a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon Mar 29 12:18:34 2010 +0200
mac80211: explicitly disable/enable QoS
mac80211 is telling drivers, in particular
iwlwifi, whether QoS is enabled or not.
However, this is only relevant for station mode,
since only then will any device send nullfunc
frames and need to know whether they should be
QoS frames or not. In other modes, there are
(currently) no frames the device is supposed to
send.
When you now consider virtual interfaces, it
becomes apparent that the current mechanism is
inadequate since it enables/disables QoS on a
global scale, where for nullfunc frames it has
to be on a per-interface scale.
Due to the above considerations, we can change
the way mac80211 advertises the QoS state to
drivers to only ever advertise it as "off" in
station mode, and make it a per-BSS setting.
Tested-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"Recover from tx stall" function is available for all devices except
4965, here add the functionality to 4965.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Smatch complains that "upriv->read_urb" gets dereferenced before
checking for NULL. It turns out that it's possible for
"upriv->read_urb" to be NULL so I added checks around the dereferences.
Also I remove an "if (upriv->bap_buf != NULL)" check because
"kfree(NULL) is OK.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
An A-MPDU may contain several subframes each containing its own
CRC for the data. Each subframe also has a respective CRC for the
MPDU length and 4 reserved bits (aka delimeter CRC). AR9003 will
ACK frames that have a valid data CRC but have failed to pass the
CRC for the MPDU length, if and only if the subframe is not the
last subframe in an A-MPDU and if an OFDM phy OFDM reset error has
been caught. Discarding those subframes results in packet loss under
heavy stress conditions, an example being UDP video. Since the
frames are ACK'd by hardware we need to let these frames through
and process them as valid frames.
Cc: Tushit Jain <tushit.jain@atheros.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes this sparse complaint:
CHECK drivers/net/wireless/ath/ath9k/htc_drv_main.c
drivers/net/wireless/ath/ath9k/htc_drv_main.c:441:5:
warning: symbol 'ath9k_htc_tx_aggr_oper'
was not declared. Should it be static?
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There were a few places where the sc->rxlink pointer was set to NULL "just in
case". This helps nothing - quite to the contrary it is problematic since it
can create self-linked rx descriptors in the middle of the list of receive
buffers.
Here is an example how this could happen (thanks Bob!):
cpu 0: cpu 1:
ath5k_rx_stop
ath5k_tasklet_rx
sc->rxlink = NULL; /* just in case */
// following doesn't link used
// buffer to prev.
ath5k_rxbuf_setup()
In the case of ath5k_rx_stop() and ath5k_stop_locked() buffers/descriptors are
not changed so rxlink should not be changed as well.
In ath5k_intr() we seem to try to work around a hardware bug, as the comment
(which is copied 1:1 from the HAL) suggests. I don't see how this could help.
Also the HAL does not set rxlink in this case (So where does this code come
from? It has been there since the first import of ath5k). Changed to just
increment a statistics counter.
After this patch rxlink is only set to NULL before we initialize rx descriptors
and updated when the descriptors are linked together.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on a patch from Bruno Randolf, attempting useful
work while we are resetting the chip just leads to interface
lockups and bad descriptor data, and possibly DMAing to
freed buffers. Let's suspend all tasklets while
reprogramming the registers in the card to avoid such
problems.
In the future we can convert the tasklets to threaded
interrupt handlers to simplify things.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We currently trigger a reset via a tasklet when certain error
conditions are detected so that the card will (eventually)
restart. Unfortunately this makes locking complicated since
reset can also be called in process context (e.g. for channel
change). Currently nothing protects against concurrent resets,
which can be the source of corruption bugs.
Reset takes too long to spinlock the whole thing, so this
patch moves deferred resets into the mac80211 workqueue to
enable use of sc->lock mutex.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to documentation, The following chip revisions were never sold:
- AR9280 v1.0
- AR9285 v1.0
- AR9285 v1.1
- AR9287 v1.0
Removing initvals specific to these chip revisions saves around 30k in
binary size (tested on MIPS).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We must call del_airo_dev() before free_netdev() since we call
add_airo_dev() exactly after alloc_netdev().
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The patch 'ath9k: fix a buffer leak in A-MPDU completion' addressed the
issue of running out of buffers/descriptors in the tx path if a STA is
deleted while tx status feedback is still pending.
The remaining issue is that the skbs of the buffers are not reclaimed,
leaving a memory leak.
This patch fixes this issue by running the buffers through
ath_tx_complete_buf(), ensuring that the pending frames counter is also
updated.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
num_sec_wiphy means max secondary wifis that the driver can accomudate.
So cancelling wiphy work should be based on the presence of
secondary wifis.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove tMinCalPower from ath9k_hw_set_def_power_cal_table(), as it's
never used. Remove corresponding arguments of the functions calculating
that value.
Original patch by Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
LED should be ON when the radio is put into FULL SLEEP mode during the idle
unassociated state.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR5008+ and AR9003 currently use two separate implementations of the
ath9k_hw_loadnf function. There are three main differences:
- PHY registers for AR9003 are different
- AR9003 always uses 3 chains, earlier versions are more selective
- The AR9003 variant contains a fix for NF load timeouts
This patch merges the two implementations into one, storing the
register array in the ath_hw struct. The fix for NF load timeouts is
not just relevant for AR9003, but also important for earlier hardware,
so it's better to just keep one common implementation.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Occasionally the hardware can send out tx status information with the wrong
TID. In that case, the BA status cannot be trusted and the aggregate
must be retransmitted.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the receive path gets stuck, a full hardware reset is necessary to
recover from it. If this happens during a scan, the whole scan might fail,
as each channel change bypasses the full reset sequence.
Fix this by resetting the fast channel change flag if stopping the
receive path fails.
This will reduce the number of error messages that look like this:
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x40000020
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
PDADC values were only generated for values surrounding the target
index, however not for the target index itself, leading to a minor
error in the generated curve.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On AR9285, the antenna switch configuration register uses more than just
16 bits. Because of an arbitrary mask applied to the EEPROM value that
stores this configuration, diversity was broken in some cases, leading
to a significant degradation in signal strength.
Fix this by changing the callback to return a 32 bit value and remove
the arbitrary mask.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All callback functions are gathered in rt2x00dev->ops except
for the callback functions which are used in rt2800lib to
acces rt2800pci/usb.
Move the priv pointer from rt2x00dev to rt2x00dev->ops and
rename it to drv to make it obvious that it is the driver callback
structure.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Large parts of the firmware initialization are shared
between rt2800pci and rt2800usb. Move this code into
rt2800lib.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently rt2x00 uses the TSF_SYNC_BEACON mode for all beaconing
interface types. However, TSF_SYNC_BEACON is meant for IBSS networks and
thus implements TSF merging in the hardware. Rename TSF_SYNC_BEACON to
TSF_SYNC_ADHOC to better express its purpose and introduce the missing
TSF sync mode TSF_SYNC_AP_NONE which should be used for beaconing modes
that don't need TSF merging.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Activating the TBTT interrupt when a beacon interval of 0 is configured
results in an interrupt storm causing the machine to hang. Hence,
initialize the beacon interval to a reasonable default of 100TUs.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using the set_tim callback without managing the DTIM count and the
broad- and multicast buffering in hw, fw or the driver results in wrong
DTIM count values being sent out in beacons. Since all PCI drivers
fetch new beacons periodically and hence get an updated TIM we can just
remove the set_tim callback from these.
The rt2x00 USB drivers don't update the beacon periodically and thus
rely on the set_tim callback to get a correct TIM for beacon
transmission. USB devices still suffer from the DTIM count being wrong
under some circumstances but removing the set_tim callback from these
would cause more harm then good.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
