The Mandriva patch seems to stem from 2.6.14, so much for their
upstreaming effort.
Didn't find another Linux reference of it, just an omnious
"USB\VID_1044&PID_8004" from GigabyteZD1201U.INF for
Gigabyte GN-WLBZ101 802.11b USB Adapter, which matches the
Mandriva patch comment.
Aboves file also lists an "USB\VID_1044&PID_8006", which I have
kept appart as this "Gigabyte GN-WBZB-M 802.11b USB Adapter"
didn't show up in googling.
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Current 8187B initialization misses anaparam registers restore after
8187 reset. This causes ANAPARAM register to stay zeroed out (ANAPARAM2
kept its value on my tests). To avoid this, call rtl8187_set_anaparam
right after chip reset (to be on the safe side, as it makes sure we
restore all ANAPARAM registers).
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: seno <senada@t-online.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Usually you set RTL818X_CONFIG3_ANAPARAM_WRITE when you are going to
change/write ANAPARAM registers. But in current initialization of
RTL8187B there is a place where ANAPARAM_WRITE bit is set without any
ANAPARAM register being written, without reason, so remove it.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: seno <senada@t-online.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are repeated calls for anaparam on/off sequence in the code.
Consolidate the common code in rtl8187_set_anaparam and use it where
needed.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The GNTSel bit should only concern pci devices by looking at RTL8180
spec, which is not the case of 8187B. Also testing shows that trying to
set this bit fails, a subsequent read from the register after trying to
set it shows that the bit isn't set, seems the hardware ignores it,
which makes sense. This setting was a left over from Realtek sources.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On 8187B start, comment about pll reset, and move it out of ANAPARAM
write sequence, so that code is more readable.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The table with misc register initialization was setting it, and later
on we would set it again with a explicity call to rtl818x_iowrite16_idx.
Remove duplicate initialization from the register table.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We were using wrong address for BRSR (Basic Rate Set Register) while
initializing its value, comparing with Realtek sources, for 8187B case.
Also, the same register is initialized in rtl8187b_reg_table, so remove
the duplicate initialization from the table.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On 8187B path, we set a initial value for beacon interval and atim
window on initialization. But this isn't needed, since same setup is
done on rtl8187_config.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes redundant write to Auto Rate Fallback Register on RTL8187B.
The same value was being written twice in the same function. Avoid this
removing the duplicate initialization on rtl8187b_reg_table, and also
add comment for this write (information from Realtek source).
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AP firmware uses xmitcontrol to differentiate between AMPDU
and non-AMPDU frames. As the support for AMPDU is not yet
added, set xmitcontrol to non-AMPDU for all tx frames for AP
firmware. This field will be set to indicate ampdu/non-ampdu
frames when tx AMPDU support is added.
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Previously, the beacon rate was fixed to either:
* 1Mb/s [2.4GHz band]
* 6Mb/s [5GHz band]
This limitation has been addressed and now the
beacon rate is selected by ieee80211_tx_info's
rate control info, almost like any ordinary
data frame.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a possible lengthy stall if the device
is operating as an experimental 11n AP and an STA
[during heavy txrx action] suddenly signalized to go
off-channel (old NetworkManager), or (sleep - which is
unlikely, because then it wouldn't be *active* at all!?).
Because the driver has to manage the BA Window, the
sudden PSM transition can leave active uplink BA
sessions to the STA in a bad state and a proper
cleanup is needed.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RX Stress tests of unidirectional bulk traffic with
bitrates of up to 220Mbit/s have revealed that the
fatal-event recovery logic [which was solely triggered
by an out-of-rx-buffer situation] is too aggressive.
The new method now "pings" the device and then
decides - based on the response - whenever
a restart is needed or not.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch changes the initial aMPDU density and
factor settings to match those of Otus.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch imports all shared header changes
from carl9170fw.git.
* add some strategic __aligned(4).
This allows the compiler generate optimized code for
architectures which can't access (unaligned/packed)
data efficiently.
("ath9k_hw: optimize all descriptor access functions")
* add a forgotten __CARL9170FW__ ifdef around
a private firmware-internal struct.
* GET_VAL macro helper
Very useful for extracting data out of the
bit-packed PHY registers.
* cosmetic changes
e.g.: _CCA_MINCCA_ to just _CCA_MIN_.
* version bump 1.8.8.3 -> 1.9.0.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Up to now mac80211_hwsim has been reporting an rssi of -50. This patch
improves the model slightly by returning txpower-50. This makes it
easy to stimulate tests that need to see a varying rssi.
Signed-off-by: Blaise Gassend <blaise@willowgarage.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Clearing the per packet TX AGC for the RTL8187B device appears to
increase its overall TX power. This allows the device to associate and a
connection to be established using APs a little further away.
This is in accordance to what is done for RTL8187L devices and also what
Realtek drivers do.
Tested-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: linux-wireless@vger.kernel.org
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Rogerio Luz Coelho <rogluz.news@gmail.com>
Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: Hin-Tak Leung <hintak.leung@gmail.com>
Cc: seno <senada@t-online.de>
Tested-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
unmask the WL1271_ACX_INTR_WATCHDOG interrupt.
when getting it - enqueue a recovery work and bail out.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
set wl->vif to the newly created interface only after the firmware booted
successfully. on the way - make the function flow more clear.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Check the state of the interface on op_* function so we don't try to access
the hardware in when its off.
The mac80211 may call these in some corner cases related, for instance, to
the hardware recovery procedure. These accesses cause a kernel crash on at
least some SDIO devices, because the bus is not properly claimed in that
scenario.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
In scan_complete_work, because the mutex is released before accessing the
scan->failed flag, it is possible for unfounded hardware recovery rounds
to be executed.
Fix this.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
The wl1271_rx function loops through packets in an aggregated buffer. Each
packet in the buffer is handled by a call to wl1271_rx_handle_data, which will
fail if skb memory allocation fails or production mode is enabled. These
failures currently prevent the rx counters to be incremented, thus causing the
rx loop to run forever.
Fix this by ignoring error codes reported wl1271_rx_handle_data function.
This essentially means that frames will be dropped in production mode, which
is the intetion, and frames will be dropped if memory allocation fails, which
is a decent way to recover from that situation.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Tested-by: Tuomas Katila <ext-tuomas.2.katila@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
wl1271_ps_elp_sleep() is void and cannot return a value.
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
This bug was being triggered by a call to acx_rate_policies in tx_work
without calling ps_elp_wakeup first. If we have full PSM enabled, this
happens rather often, immediately after association.
Reported-by: Tuomas Katila <ext-tuomas.2.katila@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Tested-by: Tuomas Katila <ext-tuomas.2.katila@nokia.com>
While scanning, it is possible that beacon and probe response frames are
received on other band than configured to the driver. In rx status
handling this has caused "Unsupported RX rate from HW" warnings. This
patch changes the wl1271_rate_to_index function to take the band of the
received frame as a parameter instead of using value configuret to
wl->band.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Add 11n ability in scan, connection and using MCS rates.
The configuration is temporary due to the code incomplete and
still in testing process. That plans to be remove in the future.
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Added ACX command to the FW for 11n support.
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
The number of entries in the TX queue is compared to the low watermark
value each time TX completion interrupts are handled.
However, the fact that a TX completion arrived does not necessarily mean
there are any less skbs in the TX queue.
In addition, a TX completion interrupt does not necessarily mean that there
are any new available TX blocks. Thus, queuing TX work when the low
watermark is reached might not be needed.
Fix this by moving the low watermark handling to the TX work function,
and avoid queuing TX work in this case.
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
On each TX descriptor allocation, a free entry is found by traversing the TX
descriptors array.
Improve this by holding a bitmap of all TX descriptors, and using efficient
bit operations to search for free entries.
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
While wl1271_irq_work handles RX directly (by calling wl1271_rx), a different
work is scheduled for transmitting packets. The IRQ work might handle more than
one interrupt during a single call, including multiple TX completion
interrupts. This might starve TX, since no packets are transmitted until all
interrupts are handled.
Fix this by calling the TX work function directly, instead of deferring
it.
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
In case the aggregation buffer is too small to hold all available packets,
the buffer is transferred to the FW and no more packets are aggregated.
Although there may be enough available TX blocks, no additional packets will
be handled by the current TX work.
Fix this by flushing the aggregation buffer when it's full, and continue
transferring packets as long as there are enough available TX blocks.
Signed-off-by: Ido Yariv <ido@wizery.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
For 130 series device, 6000g2b uCode will be used, no need to
have additional defines for 130 devices, so remove those.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adding description to Kconfig to indicate more devices
are being supported by iwlagn
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While BT is on and doing iscan and/or pscan, BT is in listen
mode which will impact WiFi throughput, we need to
enable dynamic smps in order to improve the rx throughput.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Implement switching the interface while an
interface is up in iwlwifi. Interfaces have
to stay on the context they were created on.
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>
My previous patch to clean up all RXON handling
inadvertently broke IBSS because it failed to
take into account that unlike in AP mode, IBSS
requires beacons to be sent only after setting
the RXON assoc.
Fix this, clean up the code a bit, improve the
error checking around this, and also react to
beacon changes in IBSS mode from mac80211.
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>
In order to simplify the flow, and make new
enhancements easier, separate out the RXON
processing for modern AGN (5000 and newer)
from RXON processing for the older 3945 and
4965 devices. Avoid changing these old ones
to avoid regressions and move their code to
a new file (iwl-legacy.c). 4965 gets the
commit_rxon that used to be common for all
AGN devices, but with removed PAN support.
The new RXON processing is more central and
does more work in committing, so that it is
easier to follow.
To make it more evident what is split out
for legacy, split the necessary operations
for that into a new struct iwl_legacy_ops.
Those parts that still exist in the new AGN
code don't need to be parametrized.
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>
Resending RXON timing here caused issues with
dual-mode under certain circumstances, so avoid
doing it here right now.
This effectively reverts b01efe434b
and partially 2491fa42d9. The next
patch will make all this cleaner for just the
devices that need it.
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>
In the future, 4965 and modern AGN devices will
need to have different mac80211 callbacks since
they have different capabilities. Prepare for
that by making the mac80211 operations a device
config.
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>
This helps align resets / RX enable & disable / TX stop / start.
Locking around the PCU is important to ensure the hardware doesn't
get stale data when working with DMA'able data.
This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Tested-by: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The PCU lock should be used to contend TX DMA as well,
this will be done next.
This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Tested-by: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The new PCU lock is better placed so we can just contend
against that when trying to reset hardware.
This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Tested-by: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rafał Miłecki