Store appropriate desc length which will be used by the
ath9k module while duplicating tx desc.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR9003 hardware family now initializes hardware by block
components and into stages: pre, core and init.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The initvals.h file is over 7000 lines now, so instead of adding
AR9003 initvals to it instead lets split the current initvals.h by
hardware family: AR5008, AR9001, AR9002
The AR9003 family will have its own initval file later.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Also, no need for the udelay(2) on AR9003 hardware.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR9003 family requires a change on the loop and can also skip
testing the PHY timing registers. This chip test can now be used
by all Atheros hardware families, including legacy. We can
eventually move this out to the generic ath module.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Set rx buf size in register 0x60
* Set rxdp on the respective hw rx queue (HP and LP queues)
* Process rx descriptor
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
HP & LP queue depth and rx status length.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9003 supports extended DMA (EDMA), this comes with some
bells and whistles on top of the legacy DMA that we are used
to. Mark AR9003 and later chips EDMA capable.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ANI is still being debugged on AR9003 by our systems team
so it should not yet be enabled yet. When ANI will be
enabled all ANI functionality is expected to be enabled
so fill the ANI functionality to all for AR9003 for now
as well.
Cc: Enis Akay <Enis.Akay@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This allows us to add SREV checks on these helpers.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This add stubs for PHY support for the AR9003 hardware family.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Also, clean up and reorganize the AR9287 macro to have better
ordering. We won't add the PCI ID to the supported device list
until we have some functional code for it.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The PLL control computation used to program the AR_RTC_PLL_CONTROL
register varies between our harware so just add a private callback for it.
AR9003 will use its own callback.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is not required for the AR9003 family.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The PHY split is easier done in a few steps. First move
the RF ops to the private ops and rename them accordingly.
We split PHY stuff up first for the AR5008 and AR9002
families. There are some callbacks that AR9002 share
with the AR5008 familiy so we set those first, if AR9002
has some different callbacks it will override them upon
hardware init.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is used only once by ath9k_hw_process_ini() to
write an array of phy registers through REG_WRITE_ARRAY(),
but we already call REG_WRITE_ARRAY() multiple times
on the same caller so just remove this pointless wrapper.
We'll eventually just move the ath9k_hw_process_ini()
caller as an callback to abstract away between different
hardware families.
Although this change is subtle I should note that this
does change the delay pattern on writing the next series
of registers. REG_WRITE_ARRAY() uses a counter for each
register write and does a udelay(1) every 64 writes. By
removing this call it means that the counter is processed
for all the iniBB_RfGain registers and is incremented
on ath9k_hw_process_ini(), before this the after the call
ath9k_hw_write_regs() was made the register counter was
kept at the same index number prior to the call.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9003 does not have a reset control for AHB.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is not a stable code fix as this register is not used anywhere.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9300 will be the first device supported of the AR9003
family. AR9300 1.0 hardware exists but it is not going to
be sold anywhere so we completely skip its support.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k supports the AR5008, AR9001 and AR9002 family of Atheros
chipsets, all 802.11n. The new breed of 802.11n chips, the
AR9003 family will be supported as well soon. To help with its
support we're going to add a few callbacks for hardware routines
which differ considerably instead of adding branch checks for
the revision at runtime.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Davinci platforms apparently need more time in-between helper firmware
blocks. Even though this is an increased delay, we only take this hit
once at initialization time.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Consolidate a bunch of C&P code that waits for the firmware to be ready.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In preparation for new rtl818x devices, move the existing rtl818x configuration
into the rtl818x directory.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
wl1251 is embedded chip that can be connected using SDIO bus, and is not
an actual SDIO card. For this reason there is a need to pass some board
specific data, like 'EEPROM is attached' flag or power control callback.
However currently there is no way to pass this data through SDIO subsystem,
so this patch registers dummy platform_device to allow that, until we
have a better solution to this.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a bug which was just recently introduced by
("p54pci: prevent stuck rx-ring on slow system").
make M=drivers/net/wireless/p54 C=2 CF=-D__CHECK_ENDIAN__
CHECK drivers/net/wireless/p54/p54pci.c
drivers/net/wireless/p54/p54pci.c:143:11: warning: cast to restricted __le32
CC [M] drivers/net/wireless/p54/p54pci.o
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2800pci used the callback write_tx_desc to write the tx descriptor but
also to update the txwi which is part of the dma mapped skb. Since the
memory was already DMA mapped _before_ the call to write_tx_desc the
device didn't get the txwi data at all or only sporadically.
The call order is basically as follows (from rt2x00queue.c):
1) write_tx_data
2) rt2x00queue_map_txskb
3) write_tx_desc
Hence, we shouldn't touch the skb in write_tx_desc anymore.
To fix this issue create a new rt2800pci_write_tx_data callback and use it
for updating the txwi _before_ the memory gets DMA mapped.
The tx descriptor is still written (as before) in write_tx_desc.
This patch allows basic TX on an rt305x soc device but I'm pretty sure
that it will fix pci based cards as well. I can associate just fine with
an AP now but I wasn't able to get a wpa secured connection working yet.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Extend the write_tx_data callback with a txdesc parameter to allow
access to the tx desciptor while preparing the tx data.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some wl1251 hardware configurations (like in WG7210 module) have
EEPROM attached where NVS data is kept, which includes MAC address.
In such configurations, let's read default MAC address from EEPROM,
instead of using random one.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds the following 5 entries to the usbid device table:
* Netgear WNA1000
* Proxim ORiNOCO Dual Band 802.11n USB Adapter
* 3Com Dual Band 802.11n USB Adapter
* H3C Dual Band 802.11n USB Adapter
* WNC Generic 11n USB dongle
CC: <stable@kernel.org>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If EEPROM is used, NVS data is now loaded but ignored.
Stop loading it to avoid need of dummy NVS file for modules with EEPROM.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In ath9k-htc register out path, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.
This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In ath9k-htc register in path, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.
This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In ath9k_hif_usb_alloc_rx_urbs, ath9k-htc will pass skb->data into
usb hcd and usb hcd will do dma mapping and unmapping to the buffer
pointed by skb->data, so we should pass a cache-line aligned address.
This patch replace __dev_alloc_skb with alloc_skb to make skb->data
pointed to a cacheline aligned address simply since ath9k-htc does not
skb_push on the skb and pass it to mac80211, also use kfree_skb to free
the skbs allocated by alloc_skb(we can use kfree_skb safely in hardirq
context since skb->destructor is NULL always in the path).
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We get RXORN interrupts when all receive buffers are full. This is not
necessarily a fatal situation. It can also happen when the bus is busy or the
CPU is not fast enough to process all frames.
Older chipsets apparently need a reset to come out of this situration, but on
newer chips we can treat RXORN like RX, as going thru a full reset does more
harm than good, there.
The exact chip revisions which need a reset are unknown - this guess
AR5K_SREV_AR5212 ("venice") is copied from the HAL.
Inspired by openwrt 413-rxorn.patch:
"treat rxorn like rx, reset after rxorn seems to do more harm than good"
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
resulted in high bitrates, which i think is what we want anyways. Cleared the
confusion and added some documentation.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add RT3390 specific register initializations to rt2x00, based on the latest
Ralink rt3390 vendor driver.
Untested as I don't actually own an RT3390 based device, but given experiences
on rt3070/rt3071 very hopeful that this will actually work..
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add RT3090 specific register initializations to rt2x00, based on the latest
Ralink rt3090 vendor driver.
Untested as I don't actually own an RT3090 based device, but given experiences
on rt3070/rt3071 very hopeful that this will actually work..
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add RT3071 specific register initializations to rt2x00, based on the latest
Ralink rt3070 vendor driver.
With this patch my RT3071 based devices start showing a sign of life.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00 had preliminary support for RT3070 based devices, but the support was
incomplete.
Update the RT3070 register initialization to be similar to the latest Ralink
vendor driver.
With this patch my rt3070 based devices start showing a sign of life.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Align the rt2800 register initializations with the latest versions of the
Ralink vendor driver.
This patch is also preparation for the addition of support for RT3070 /
RT3071 / RT3090 / RT3390 based devices.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The rt2800 version constants are inconsistent, and the version number don't
mean a lot of things anyway. Refactor the constants to have some more
meaningful names, and introduce and use some new helpers to check these
chipset revisions. At the same time rename to revision, as they are more
revision numbers rather than version numbers.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Only include definitions for RT chipsets that are also used inside the
Ralink vendor drivers.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Definitions taken from the latest rt2860 / rt2870 / rt3070 / rt3090 Ralink
vendor drivers.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It seems that the distinction between RF channel switch method is solely based
on the RF chipset that is used.
Refactor the channel switch decision to just take the RF chipset into account,
thereby greatly simplifying the check.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes an old problem, which - under certain
circumstances - could cause the device to become
unresponsive.
most of p54pci's rx-ring management is implemented in just
two distinct standalone functions. p54p_check_rx_ring takes
care of processing incoming data, while p54p_refill_rx_ring
tries to replenish all depleted communication buffers.
This has always worked fine on my fast machine, but
now I know there is a hidden race...
The most likely candidate here is ring_control->device_idx.
Quintin Pitts had already analyzed the culprit and posted
a patch back in Oct 2009. But sadly, no one's picked up on this.
( https://patchwork.kernel.org/patch/53079/ [2 & 3] ).
This patch does the same way, except that it also prioritize
rx data processing, simply because tx routines *can* wait.
Reported-by: Sean Young <sean@mess.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=11386
Reported-by: Quintin Pitts <geek4linux@gmail.com>
Signed-off-by: Quintin Pitts <geek4linux@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We used to free all the Tx queues memory when interface is brought
down and reallocate them again in interface up. This requires
order-4 allocation for txq->cmd[]. In situations like s2ram, this
usually leads to allocation failure in the memory subsystem. The
patch fixed this problem by allocating the Tx queues memory only at
the first time. Later iwl_down/iwl_up only initialize but don't
free and reallocate them. The memory is freed at the device removal
time. BTW, we have already done this for the Rx queue.
This fixed bug https://bugzilla.kernel.org/show_bug.cgi?id=15551
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Check return code on iwl_send_cmd_pdu() to get rid of compiler warning.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Fixes:
CC [M] drivers/net/wireless/iwlwifi/iwl-agn-rs.o
drivers/net/wireless/iwlwifi/iwl-agn-rs.c: In function ‘rs_get_rate’:
drivers/net/wireless/iwlwifi/iwl-agn-rs.c:2419: warning: unused variable ‘priv’
CC [M] drivers/net/wireless/iwlwifi/iwl-sta.o
drivers/net/wireless/iwlwifi/iwl-sta.c: In function ‘iwl_send_add_sta’:
drivers/net/wireless/iwlwifi/iwl-sta.c:197: warning: unused variable ‘sta_id’
drivers/net/wireless/iwlwifi/iwl-3945.c: In function ‘iwl3945_rx_reply_rx’:
drivers/net/wireless/iwlwifi/iwl-3945.c:601: warning: unused variable ‘rx_stats_noise_diff’
drivers/net/wireless/iwlwifi/iwl-3945.c:600: warning: unused variable ‘rx_stats_sig_avg’
drivers/net/wireless/iwlwifi/iwl-3945-rs.c: In function ‘rs_get_rate’:
drivers/net/wireless/iwlwifi/iwl-3945-rs.c:650: warning: unused variable ‘priv’
Reported-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
REPLY_TX_LINK_QUALITY_CMD was used by 4965, 5000 series and up
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Update to include additional tx command response status for "_agn"
devices.
The following status indicate the transmission was postponed:
TX_STATUS_POSTPONE_DELAY
TX_STATUS_POSTPONE_FEW_BYTES
TX_STATUS_POSTPONE_BT_PRIO
TX_STATUS_POSTPONE_QUIET_PERIOD
TX_STATUS_POSTPONE_CALC_TTAK
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
When sys assert happen, driver will dump the error table information
provided by uCode. There are more information available but is not being
display by the driver; adding program counter and last host command the
to log to help uCode debugging.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
The last_phy_res[100] variable is used in an odd
way. The first byte of it is used as a flag, and
the rest as the data. Thus, the array need only
be 61 bytes, since it is just the flag and a
struct iwl_rx_phy_res (which is 60 bytes).
Clean this up by splitting the variable into two:
last_phy_res and last_phy_res_valid, using correct
types for both (struct and bool). While doing all
this also move the variables to the _agn part of
the hw-specific union since they only apply to
A-MPDUs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
lq->sta_id cannot be invalid here since this
function will only be called after the station
has been added properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Simplify the WEP group key check by checking the
sta pointer instead of the sta_id we calculate
with it; also clean up the comment formatting.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Default WEP keys and regular keys are not allocated
from the same space in the firmware, so we shouldn't
use the same bits to indicate in use.
For default WEP keys, however, mac80211 won't allow
using the same key index twice, so the check is not
necessary at all -- add/remove are perfectly nested
due to those checks.
Other keys are allocated in the device in a global
array that only has a certain number of slots, so
for that we need to keep the allocation bitmap; but
the 802.11 key index isn't relevant there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
The firmware clears default WEP keys on
transitions to !associated, so we need
to restore them just like stations. This
is rather implicit as part of sending a
station right now, which is odd. Make it
explicit instead and only for agn since
3945 doesn't use hw crypto for WEP.
Due to that, iwl_send_static_wepkey_cmd
is now only used in iwl-sta.c and can be
static.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Size of event log is determined by uCode which is different per NICs.
Set the maximum event log size per device to better match uCode
configuration.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
This patch will add support for connection quality monitoring by configuring
rssi triggers to the firmware, and enabling the firmware rssi trigger
functionality.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Allow the wl1271 go to ELP mode also in idle. This will reduce current
consumption remarkably in idle mode (~12mA -> ~0.2mA)
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 sends RTS threshold configuration request even if the wl1271 interface
state is WL1271_STATE_OFF. This leads to failures during pm tests.
This patch leaves the configuration function, if the interface is
going down.
Signed-off-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 sends configuration requests even if the wl1271 interface
state is WL1271_STATE_OFF. This creates warnings from mac80211.
This patch leaves the configuration functions, if the interface is
going down.
Signed-off-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes some memory leaks occurring during driver init/de-init.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Resolution of a merge conflict upstream accidentally removed a hunk of
"ath5k: IQ calibration for AR5211 is slightly different", so restore it.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For 4965, need to check it is valid qos frame before free, only valid
QoS frame has the tid used to free the packets.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Simple pre-scan and scan complete callbacks, this at least shows
to me that mac80211 will issue two scans at the same time on the
same wiphy.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We check the bounds on pdadc once when correcting for
negative curves but not when we later copy values from
from the pdadc_tmp array, leading to a potential overrun.
Although we shouldn't hit this case in practice, let's
be consistent.
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As pointed out by Benoit Papillault, there is a potential
race condition between the host and the hardware in reading
the next link in the transmit descriptor list:
cpu0 hw
tx for buf completed
raise tx_ok interrupt
process buf
buf->ds_link = 0
read buf->ds_link
This change checks txdp before processing a descriptor
(if there are any subsequent descriptors) to see if
hardware moved on. We'll then process this descriptor on
the next tasklet.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Review spotted a couple of strange invocations to
ieee80211_wake_queues that could potentially cause problems:
- queues are awakened in the calibration tasklet before
phy calibration, and then again after calibration
- queues are awakened inside reset when we're trying to
drain the ath5k transmit queues, and again after
reset is completed (in callers to ath5k_reset_wake).
In both cases the first wake is unnecessary, so remove it.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These channels aren't selectable anyway, but our calculations
for 2.5 mhz frequencies are incorrect. The value is supposed to
be:
(frequency - reference) * (10/25)
i.e., divide by 2.5, but we were instead doing:
(10 * frequency - reference) / 25.
Additionally, the check for (frequency % 5 == 2) had an extra
subtraction that wasn't in madwifi HAL.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2872 needs the same rf register setup as rt3070 and rt3090, hence
use rt2800_config_channel_rt3x instead of rt2800_config_channel_rt2x.
This change allows me to actually switch channels and hence scan all
configured channels on the RT305x SoC platform (which uses a rt2872)
here.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Tested-by: Luis Correia <luis.f.correia@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't modify ah->iniModes, it's supposed to be constant. Instead, apply
the fixup when the data is written to the registers.
Change ath9k_hw_init_eeprom_fix() to only determine whether the fixup is
needed.
This allows similteneous support for AR9220 cards that need AR_AN_TOP2
fixup (such as Ubiquiti SR71-12) and those that don't need it (D-Link
DWA-552 rev A2).
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Messages that are generated by the HTC layer
don't have any TX callback endpoints assigned to them.
Consequently, the allocated SKBs are never freed.
Fix this issue by handling this case in the HTC layer
itself.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
hif_usb_regout_cb() frees the given URB, which is
borked by design. Use an anchor to simplify URB
management.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The maximum number of packets in a single buffer in
stream mode is 10. The driver currently uses 8 - which
caused stack corruption, in the absence of any kind
of OOB checking.
Fixing this to the correct value of 10 fixes the module
unload issue.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Tested-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RX URBs are automatically freed when the reference
count drops to zero - this currently doesn't happen when
usb_kill_anchored_urbs() is called during unload.
Fix this by dropping the reference count by one during
initial submission.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use a spin lock to prevent concurrent access
to variables dealing with RX stream mode handling.
Currently, no protection is implemented - which
causes problems in RX.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Vasanthakumar Thiagarajan