While scanning the link tuner must be disabled. Otherwise
it will interfere with receiving all beacons for each channel
due to changing sensitivity levels.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rename CONFIG_DISABLE_LINK_TUNING to DRIVER_SUPPORT_LINK_TUNING
Link tuning support is not only based on EEPROM decisions, but
also if the device actually supports it.
Currently only rt2500usb doesn't support link tuning because
of hardware problems. But rt2800usb is also suspected of having
problems with link tuning.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that the write_tx_data functions are merged, also merge the relevant
parts of the txdone handling into common code, rather than {usb,pci}
specific code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that rt2x00pci_write_tx_data and rt2x00usb_write_tx_data are similar
we can merge them in a single function in rt2x00queue.c.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of fiddling with the skb->data pointer and thereby risking
out of bounds accesses, properly reserve the space needed in an
skb for descriptors.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Not all the devices require a TX descriptor to be written (i.e. rt2800
device don't require them). Push down the creation of the TX descriptor
to the device drivers so that they can decide for themselves whether
a TX descriptor is to be created.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
(Based on a patch created by Ondrej Zary)
In some circumstances the Ralink devices do not properly go to sleep
or wake up, with timeouts occurring.
Fix this by retrying telling the device that it has to wake up or
sleep.
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 handling of tx descriptors for beacons can be simplified by updating
write_tx_desc implementations of each driver to write directly to the
queue entry descriptor instead of to a provided memory area.
This is also a preparation for further clean ups where descriptors are
properly reserved in the skb instead of fiddling with the skb data
pointer.
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>
Where possible, write the tx descriptor words from start to end, to
follow a logical ordering of words.
Where this is not possible (in rt2400pci, rt2500pci and rt61pci) add
a comment as to why word 0 needs to be written last.
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>
Preparation to fix rt2800 beaconing.
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>
All of the driver's kick_tx_queue callback functions treat the TX queue
for beacons in a special manner.
Clean this up by integrating the kicking of the beacon queue into the
write_beacon callback function, and let the generic code no longer call
the kick_tx_queue callback function when updating the beacon.
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>
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>
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>
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>
The recent rt2800 devices are no longer really identified by their PCI
ID's, but rather by the contents of their CSR0 register. Also for the
other chipsets is the contents of this CSR0 register important.
Change the chipset determination logic to be more aligned with the rt2800
model.
Preparation for the support of rt3070 / rt3090 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>
Don't set the RT chipset for a device from within the generic PCI/SOC code,
but rather from the individual drivers, so that individual drivers have
more control over what RT chipset is set.
Preparation for chip handling updates for rt2800 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>
get_tx_stats() will be removed from mac80211.
Compile-tested only.
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
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>
Use DEFINE_PCI_DEVICE_TABLE() so we get place PCI ids table into correct section
in every case.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Let each of them take a struct rt2x00_dev pointer as argument instead of
a mixture of struct rt2x00_chip and struct rt2x00_dev pointers.
Preparation for further clean ups in the rt2x00 chip handling, especially
for rt2800 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>
Set the value of extra_tx_headroom in a central place, rather than in each
of the drivers. This is preparatory for taking alignment space into account
in the TX headroom requested by rt2x00.
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>
Clean up the use of whitespace in the initialization of the rt2x00_ops
structures. This is preparatory for a later patch that adds members
to that structure, which require different whitespace alignment.
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>
Some drivers (rt2800* most notably) cannot set the RF and RT chipset in
the correct order to have the information logging in rt2x00_set_chip
be correct.
Fix this by decoupling the setting of the chipset information from the
logging of the chipset information so that drivers can determine
themselves when all information is set.
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>
As mentioned on the linux-wireless mailing list, the current copyright
statements in the rt2x00 are meaningless, as the rt2x00 project is
not even a formal legal entity. Therefore it is better to replace
the existing copyright statements with copyright statements for the
people that actually wrote the code.
Note: Updated to the best of my knowledge with respect to who
contributed considerable amounts of code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
CC: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The calculated values for the ACK timeout and ACK
consume time are different then the values as
used by the Legacy drivers.
After testing from James Ledwith it appeared that
the calculated values caused a high amount of TX
failures, and the values from the Legacy drivers
were the most optimal to prevent TX failure due to
excessive retries.
The symptoms of this problem:
- Rate control module always falls back to 1Mbs
- Low throughput when bitrate was fixed
Possible side-effects (not confirmed but highly likely)
- Problems with DHCP
- Broken connections due to lack of probe response
This should fix at least:
Kernel bugzilla reports: [13362], [13009], [9273]
Fedora bugzilla reports: [443203]
but possible some additional bugs as well.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When beacon is being updated to refresh TIM (AP mode), beacon frames are
de-synchronizing (i.e. two neighbor beacon frames - before and after
update - are being transmitted with a wrong time interval).
That is because xxx_write_beacon should disable beacon generation only
while beacon data are being uploaded to the device, but it should not
disable the beacon clock.
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Implement set_tim callback for all rt2x00 drivers, this makes the
device wake up powersaving stations properly while in AP mode.
The only way to update the beacon is by simply calling mac80211 and
requesting the new beacon. This means the set_tim() event is mostly the
same as a beacon_done() event which was already defined in rt2x00lib.
Signed-off-by: Stefan Steuerwald <salsasepp@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove the input_polldev from rt2x00 and replace it with
the rfkill interface offered by the wiphy structure. This
simplifies the entire rfkill handling in rt2x00 and allows
us to remove the CONFIG_RT2X00_LIB_RFKILL option and always
enables rfkill capabilities.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes the last usage of beacon_int inside the iee80211_config
structure from rt2x00. The attempt is a bit hackish, and subject to
change in the future when the entire rt2x00_dev structure is
cleaned up and restructured.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
IEEE80211_CONF_CHANGE_BEACON_INTERVAL was deprecated a month ago,
it is about time to remove all usage from the rt2x00 drivers and
use the correct beacon interval configuration through the bss_info
structure.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The config_interface method is a little strange, it contains the
BSSID and beacon updates, while bss_info_changed contains most
other BSS information for each interface. This patch removes
config_interface and rolls all the information it previously
passed to drivers into bss_info_changed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
pci_dev->irq and pci_name(pci_dev) access should be limited
to rt2x00pci only. This is more generic and allows a rt2x00 pci
driver to be controlled as PCI device but also as platform driver
(needed for rt2800pci SoC support).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The only way rf_write() can be called with word 0 is
when the user sends the wrong word index through debugfs.
However the values which are send through debugfs are
validated using the RF_BASE and RF_SIZE macro values,
the most logical solution is to increase RF_BASE with 4
and decrease RF_SIZE with 4 (RF_SIZE has always been
1 word too big)
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
provide rt2x00lib the possibility to kill a particular TX queue.
This can be useful when disabling the radio, but more importantly
will allow beaconing to be disabled when mac80211 requests this
(during scanning for example)
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the led mode is asus, the activity led mode must
be registered otherwise the second LED will not be enabled.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add a check for LED_MODE_DEFAULT so that we use the link LED for rt2400
and rt2500 devices.
Signed-off-by: Andrew Price <andy@andrewprice.me.uk>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This modifies hardware flags for powersave to support three different
flags:
* IEEE80211_HW_SUPPORTS_PS - indicates general PS support
* IEEE80211_HW_PS_NULLFUNC_STACK - indicates nullfunc sending in software
* IEEE80211_HW_SUPPORTS_DYNAMIC_PS - indicates dynamic PS on the device
It also adds documentation for all this which explains how to set the
various flags.
Additionally, it fixes a few things:
* a spot where && was used to test flags
* enable CONF_PS only when associated again
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The flag ENTRY_TXD_OFDM_RATE isn't flexible enough
to indicate which rate modulation should be used for
a frame. This will become a problem when 11n support
is added.
Remove the flag and replace it with an enum value which
can better indicate the exact rate modulation.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Restrict drivers to only access link_qual structure during
link tuning. The contents of these fields are for the drivers
and all fields are allowed to be changed to values the driver
considers correct.
This means that some fields need to be moved outside of this
structure to restrict access only to rt2x00link itself.
This allows some code to be moved outside of the rt2x00.h header
and into rt2x00link.c.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The link_tuner() function will always call bbp_read()
at the start of the function. Because this is an
indirect register access has some costs attached
to it (especially for USB hardware).
We already store the value read from the register
into the vgc_level value inside the link structure.
Instead of reading from the register we can read that
field directly and base the tuner on that value.
This reduces the time the registers are locked with
the csr_mutex and speeds up the link_tuner processing.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Listen to IEEE80211_CONF_PS to determine if the device
should drop into powersaving mode. This feature depends
on the dynamic power save functionality in mac80211.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All code which accessed indirect registers was similar
in respect to the for-loop, the given timeout, etc.
Move it into a seperate function, which for PCI drivers
can be moved into rt2x00pci.
This allows us to cleanup the cleanup the code further
by removing the goto statementsand making the codepath
look a bit nicer.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Indirect registers require multiple calls to the CSR
register in order to access the indirect registers.
This must be protected under a lock to prevent race
conditions which could cause invalid data to
be returned when reading from the indirect register or silent
failures when writing data to the indirect register.
USB drivers where already protected under a mutex,
so rename the mutex and make PCI drivers use the mutex
as well.
This now means that BBP and RF registers are no longer
accessible in interrupt context. That is not a bad
situation since the slow behavior of accessing
those registers means we don't _want_ to access them
in interrupt context either.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We can optimize get_duration and get_duration_res
by making them a macro. They are really simple
calculation handlers so this doesn't matter much.
Often (especially in rt2400pci and rt2500pci,
the arguments are hardcoded, and the result value
is passed into other hardcoded values.
By making the functions a macro GCC can
optimize the entire thing much better.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
