Implementing this callback function will cause mac80211 refrain from
going to powersave state when there are still untransmitted TX frames
in the queues.
This would exactly mimic the behaviour of the legacy vendor driver which
also doesn't go in powersave mode if there are still TX frames that are not
transmitted.
This should make powersaving and rt2x00 a better couple.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-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>
The USB drivers don't support automatically waking up when in powersaving mode,
add a work object which will wakeup the device in time to receive the next beacon.
Based on that beacon, we either go back into powersaving mode, or we remain awake
to receive the buffered frames for our station.
Some part of the code, especially rt2x00lib_find_ie and rt2x00lib_rxdone_check_ps
are inspired on the code from carl9170.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Implement the get_antenna and set_antenna callback functions, which will
allow clients to control the antenna for all non-11n hardware (Antenna handling
in rt2800 is still a bit magical, so we can't use the set_antenna for those drivers
yet).
To best support the set_antenna callback some modifications are needed in the
diversity handling. We should never look at the default antenna settings to determine
if software diversity is enabled. Instead we should set the diversity flag when
possible, which will allow the link_tuner to automatically pick up the tuning.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the get_ringparam callback function we can export ring parameters
to ethtool through the mac80211 interface.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Both USB and PCI drivers allow a system administrator to dynamically add
USB/PCI IDs to the device table that a driver supports via the
/sys/bus/{usb,pci,pci_express}/drivers/<driver-name>/new_id files.
However, for the rt2x00 drivers using this method currently crashes the
system with a NULL pointer failure.
This is due to the set-up of rt2x00 where the probe functions require a
rt2x00_ops structure in the driver_info field of the probed device. As
this field is empty for the dynamically added devices this fails for
these devices.
Fix this by introducing driver-specific probe wrappers that do nothing
but calling the bus-specific probe functions with the rt2x00_ops structure
as an argument, rather than depending on the driver_info field.
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>
The number of flags defined for the rt2x00dev->flags field,
has been growing over the years. Currently we are approaching
the maximum number of bits which are available in the field.
A secondary problem, is that one part of the field are initialized only
during boot, because the driver requirements are initialized or device
requirements are loaded from the EEPROM. In both cases, the flags are
fixed and will not change during device operation. The other flags are
the device state, and will change frequently. So far this resulted in the fact
that for some flags, the atomic bit accessors are used, while for the others
the non-atomic variants are used.
By splitting the flags up into a "flags" and "cap_flags" we can put all flags
which are fixed inside "cap_flags". This field can then be read non-atomically.
In the "flags" field we keep the device state, which is going to be read atomically.
This adds more room for more flags in the future, and sanitizes the field access methods.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We can simply check if the driver registered the watchdog callback.
There's no need to have an additional flag for that.
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>
"ifs" is only used by no-HT devices. Move it into the plcp substruct and
fill in the value only for no-HT devices.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-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>
HT and no-HT rt2x00 devices use a partly different TX descriptor.
Optimize the tx desciptor memory layout by putting the PLCP and HT
substructs into a union and introduce a new driver flag to decide which
TX desciptor format is used by the device.
This saves us the expensive PLCP calculation fOr HT devices and the HT
descriptor setup on no-HT devices.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
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>
Newer devices like rt2800* own a hardware sequence counter and thus
don't need to use a software sequence counter at all. Add a new driver
flag to shortcut the software sequence number generation on devices that
don't need it.
rt61pci, rt73usb and rt2800* seem to make use of a hw sequence counter
while rt2400pci and rt2500* need to do it in software.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-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>
Remove STATE_RADIO_IRQ_OFF_ISR and STATE_RADIO_IRQ_ON_ISR as they are
not used anymore.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-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>
This patch allows to dynamically remove beaconing interfaces without
shutting beaconing down on all interfaces.
The only place to start and stop beaconing are now the start- and
stop_queue callbacks. Hence, we can remove some register writes during
interface bring up (config_intf) and only write the correct sync mode
to the register there.
When multiple beaconing interfaces are present we should enable
beaconing as soon as mac80211 enables beaconing on at least one of
them. The beacon queue gets stopped when the last beaconing
interface was stopped by mac80211. Therefore, introduce another
interface counter to keep track ot the number of enabled beaconing
interfaces and start or stop the beacon queue accordingly.
To allow single interfaces to stop beaconing, add a new driver
callback clear_beacon to clear a single interface's beacon without
affecting the other interfaces. Don't overload the clear_entry callback
for clearing beacons as that would introduce additional overhead
(check for each TX queue) into the clear_entry callback which is used
on the drivers TX/RX hotpaths.
Furthermore, the write beacon callback doesn't need to enable beaconing
anymore but since beaconing should be disabled while a new beacon is
written or cleared we still disable beacon generation and enable it
afterwards again in the driver specific callbacks. However, beacon
related interrupts should not be disabled/enabled here, that's solely
done from the start- and stop queue callbacks. It would be nice to stop
the beacon queue just before the beacon update and enable it afterwards
in rt2x00queue itself instead of the current implementation that relies
on the driver doing the right thing. However, since start- and
stop_queue are mutex protected we cannot use them for atomic beacon
updates.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-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>
Add a new command to the queue handlers: "flush",
this moves the flush() callback from mac80211
into rt2x00queue and adds support for flushing
the RX queue as well.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As part of the queue refactoring, change the queue callback
function names to have 3 different actions: start, kick & stop.
We can now also remove the STATE_RADIO_RX_ON/STATE_RADIO_RX_OFF
device_state flags, and replace the usage with using the
start_queue/stop_queue callback functions.
This streamlines the RX queue handling to the
similar approach as all other queues.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As part of the queue refactoring, we now introduce
3 queue commands: start, kick, stop.
- Start: will enable a queue, for TX this will
not mean anything, while for beacons and RX
this will update the registers to enable the queue.
- Kick: This will kick all pending frames to
the hardware. This is needed for the TX queue
to push all frames to the HW after the queue
has been started
- Stop: This will stop the queue in the hardware,
and cancel any pending work (So this doesn't
mean the queue is empty after a stop!).
Move all code from the drivers into the appropriate
functions, and link those calls to the old rt2x00lib
callback functions (we will fix this later when we
refactor the queue control inside rt2x00lib).
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 0204464329 "Check for specific changed
flags when updating the erp config" changed the way in which a new beacon
interval gets handled. However, due to a bug in rt2800usb and rt2800pci the
beacon interval was reset during each scan, thus causing problems in AdHoc
mode.
Fix this by not cleaning up the beacon interval when killing the beacon queue
but just prevent the device from sending out beacons.
Reported-by: Wolfgang Kufner <wolfgang.kufner@gmail.com>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-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>
As part of the queue refactoring, the rt2x00lib_toggle_rx
can be removed and replaced with the call directly to
the set_device_state callback function.
We can remove the STATE_RADIO_RX_ON_LINK and
STATE_RADIO_RX_OFF_LINK, as it was only used for
special behavior inside rt2x00lib rather then the
drivers.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2500usb.c:42: ERROR: do not initialise statics to 0 or NULL
Signed-off-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Implement a basic flush callback function, which simply loops
over all TX queues and waits until all frames have been transmitted
and the status reports have been gathered.
At this moment we don't support dropping any frames during the
flush, but mac80211 will only send 'false' for this argument anyway,
so this is not important at this time.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The tx descriptor values qid, cw_min, cw_max and aifs are directly
accessible through the tx entry struct. So there's no need to copy
them into the tx descriptor and passing them to the indiviual drivers.
Instead we can just get the correct value from the tx entry.
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>
All rt2x00 devices used the same Tx and Rx ring size (24 entries) till
now. Newer devices (like rt2800) can however make use of a larger TX and
RX ring due to 11n capabilities (AMPDUs of size 64 for example).
Hence, bring rt2x00 in sync with the legacy drivers and use the same TX
and RX ring sizes. Also remove the global defines RX_ENTRIES, TX_ENTRIES,
BEACON_ENTRIES and ATIM_ENTRIES and use per driver values.
That is 24 entries for rt2400pci, 32 entries for rt2500pci, rt2500usb,
rt61pci and rt73usb and 128 (RX) and 64 (TX) for rt2800pci and rt2800usb.
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>
Since rt2x00 USB devices have no chance to know when a beacon was sent
out in AP mode currently all broad- and multicast traffic is buffered in
mac80211 but never sent out at all.
Unfortunately we have no chance in sending the traffic out after a
DTIM beacon due to hw limitations. Hence, instead of never sending the
buffered traffic out better send it out immediately.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Reported-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Previously rt2x00 was always updating all erp related config variables
even though mac80211 might only have changed one. Hence, pass the
changed flags to the config_erp driver callback so that the driver
can limit the changes to the correct values.
This fixes an issue in AP mode where the beacon interval is not
initialized (and thus zero) but still sent to the hardware causing an
interrupt storm on rt2800pci hanging the system.
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>
USB devices upload their beacon and then automatically send
it out every beacon interval. However when killing a TX queue
we only kill the URB and not the actual transmission of the beacon.
This will reset the Beacon register to prevent any beacons from
being transmitted.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During initialization each driver reads the default TX power
for each individual channel. However mac80211 only accepts the
maximum value (which is also handled as default value).
As a result, the TX power of the device was being limited to
the default value, which is often quite low compared to the
real maximum acceptable value.
This patch allows each driver to set the maximum value on a
per-channel basis which is forwarded to mac80211. The default
value will be preserved for now, in case we want to update
mac80211 to differentiate between the maximum and default txpower.
This fixes bug complaining about limited TX power values like:
https://bugzilla.kernel.org/show_bug.cgi?id=16358
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
write_tx_desc shouldn't pass a rt2x00dev and skb pointer,
instead it should use the same format as other TX frame
callback functions, which is passing the data_entry pointer
which contains all the information which is needed to work
on a TX frame.
Most callers of the kick_tx_queue and kill_tx_queue already
have the data_queue pointer, so rather then sending the QID
with the given function, when the driver requests a new
pointer to the data_queue, it is more efficient to just
send the data_queue pointer directly.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These changes may be slightly safer in some instances.
There are other kzalloc calls with a multiply, but those
calls are typically "small fixed #" * sizeof(some pointer)"
and those are not converted.
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, mac80211 translates the cfg80211
cipher suite selectors into ALG_* values.
That isn't all too useful, and some drivers
benefit from the distinction between WEP40
and WEP104 as well. Therefore, convert it
all to use the cipher suite selectors.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On our hardware (050d:7050 Belkin Components F5D7050 Wireless G Adapter),
setting any WEP key with non zero index, cause rx frames corruption.
Note: perhaps (I did not check) this can be fixed differently - by using
hw_key_idx the same as true MAC key index. But according to the comment in
rt2x00mac_set_key():
"the hardware requires keys to be assigned in correct order (When key 1
is provided but key 0 is not, then the key is not found by the hardware
during RX)"
this will be quite problematic. Since WEP should not be used, disabling
hardware crypto offload for it will not hurt much. Beside static
one key WEP will still be offloaded.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Without cipher part nullify of TXRX_CSR0 register we can receive
corrupted frames (removed IV or IVC), after reloading rt2500usb module
with nohwcrypt=1 option, if previous some keys were configured into
the hardware.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix rt2500usb hardware encryption broken by commit
96b61bafe2
"rt2x00: Clean up USB vendor request buffer functions"
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use threaded interrupts for all rt2x00 PCI devices.
This has several generic advantages:
- Reduce the time we spend in hard irq context
- Use non-atmic mac80211 functions for rx/tx
Furthermore implementing broad- and multicast buffering will be
much easier in process context while maintaining low latency and
updating the beacon just before transmission (pre tbtt interrupt)
can also be done in process context.
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>
Implement watchdog monitoring for USB devices (PCI support can
be added later). This will determine if URBs being uploaded to
the hardware are actually returning. Both rt2500usb and rt2800usb
have shown that URBs being uploaded can remain hanging without
being released by the hardware.
By using this watchdog, a queue can be reset when this occurs.
For rt2800usb it has been tested that the connection is preserved
even though this interruption.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 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>
HW crypto in rt2500usb does not seem to support keys with different ciphers,
which breaks TKIP+AES mode. Fall back to software encryption to fix it.
This should fix long-standing problems with rt2500usb and WPA, such as:
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834https://bugzilla.redhat.com/show_bug.cgi?id=484888
Also tested that it does not break WEP, TKIP-only and AES-only modes.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is no need to force the separation between a buffer USB vendor
request that does fit the CSR cache and one that doesn't onto the
callers. This is something that the rt2x00usb_vendor_request_buff
function can figure out by itself.
Combine the rt2x00usb_vendor_request_buff and
rt2x00usb_vendor_request_large_buff functions into a single one, as
both of them were equivalent for small buffers anyway.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.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>
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>
