And use it consistently in the chipset drivers.
Preparation for further clean ups.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Inspection of the Ralink vendor driver shows that the TX_BAND_CFG register
and BBP register 3 are about HT40- indication, not about HT40+ indication.
Inverse the meaning of these fields in the code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that RT30xx support is at the same level as RT28xx support we can enable
these devices by default.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
PCI specific code has been remove quite some time ago.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
0x07d1,0x3c17 D-Link Wireless N 150 USB Adapter DWA-125
0x1b75,0x3071 Ovislink Airlive WN-301USB
0x1d4d,0x0011 Pegatron Ralink RT3072 802.11b/g/n Wireless Lan USB Device
0x083a,0xf511 Arcadyan 802.11 USB Wireless LAN Card
0x13d3,0x3322 AzureWave 802.11 n/g/b USB Wireless LAN Card
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update the rfcsr and bbp init code for SoC devices to match with the
latest Ralink driver.
To have better control over which values are used for the register
initialization create a new function rt2800_is_305x_soc which checks
for SoC interface type, the correct RT chipset and the correct RF
chipset. This is based on the assumption that all rt305x SoC devices
use a rt2872 and rf3020/rf3021/rf3022.
In case an unknown RF chipset is found on a SoC device with a rt2872
don't treat it as rt305x and just print a message.
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>
Restore the rfcsr initialization for RT305x SoC devices which was removed
by "rt2x00: Finish rt3070 support in rt2800 register initialization.".
This fixes the rx path on SoC devices.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix a typo in a comment in rt2800.h. Instead of replacing the wrong
hexvalue (0x171c) with the correct one (0x1718) just use the appropriate
readable define.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Get closer to what the ralink driver does by setting the rf register 13
to tx_power2 during channel switch.
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>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Disable HT40 support for now as it causes rx problems with HT40 capable
11n APs (when mac80211 enables HT40, rx is completely disfunctional).
Once the rt2800 HT code is capable of using HT40 we should enable the
flag again.
I only tested this patch with a rt305x SoC device, nevertheless the
patch disables HT40 also on PCI and USB rt2800 devices.
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>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Applied common sense, no info from the manufacturer:
(0x8516, 0x2070) is RT2070
(0x8516, 0x2770) is RT2770
(0x8516, 0x2870) is RT2870
[...]
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.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>
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>
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>
Now that the powersave issues on rt2500usb have been tackled, powersave
can be enabled by default again.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is needed to wake up the device automatically for receiving beacons,
and is required for proper powersave handling.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is needed to wake up the device automatically for receiving beacons,
and is required for proper powersave handling.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In all drivers ensure that auto wakeup is disabled before waking up the device.
This is needed to prevent connection stability issues and problems in waking up
the device.
Based upon a patch from Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (37 commits)
smc91c92_cs: fix the problem of "Unable to find hardware address"
r8169: clean up my printk uglyness
net: Hook up cxgb4 to Kconfig and Makefile
cxgb4: Add main driver file and driver Makefile
cxgb4: Add remaining driver headers and L2T management
cxgb4: Add packet queues and packet DMA code
cxgb4: Add HW and FW support code
cxgb4: Add register, message, and FW definitions
netlabel: Fix several rcu_dereference() calls used without RCU read locks
bonding: fix potential deadlock in bond_uninit()
net: check the length of the socket address passed to connect(2)
stmmac: add documentation for the driver.
stmmac: fix kconfig for crc32 build error
be2net: fix bug in vlan rx path for big endian architecture
be2net: fix flashing on big endian architectures
be2net: fix a bug in flashing the redboot section
bonding: bond_xmit_roundrobin() fix
drivers/net: Add missing unlock
net: gianfar - align BD ring size console messages
net: gianfar - initialize per-queue statistics
...
The ralink SoC platforms do not have an MCU.
Signed-off-by: Luis Correia <luis.f.correia@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Taken from latest ralink linux driver(RT3070_LinuxSTA_V2.3.0.1_20100208)
All of them are RT3070 devices.
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Taken from latest ralink linux driver, it's a RT3593 PCI/PCIe.
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It was removed in the windows inf file by ralink.
And it isn't on ralink linux drivers.
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent bug reports have shown that rt2500usb also suffers from the
powersave problems that the PCI rt2x00 drivers suffer from.
So disable powersaving by default for rt2500usb as well.
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>
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>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
After testing, we found that TX_STA_FIFO_MCS is the last MCS value
tried. If the transmission failed, 8 frames have been transmitted. If the
transmission succeed, we can easily compute the number of retry. This patch fix
the way status is reported to mac80211 rate control. It has 2 bugs :
1. mcs can contain the short preamble flag and it will lead to wrong
computations.
2. minstrel nearly always say that 54 Mbits is the best rate, even if we are
very far from the AP
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: Alban Browaeys <prahal@yahoo.com>
Acked-by: Ivo van Doorn <ivdoorn@gmail.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
John W. Linville