Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

The usb_cache_mutex was not correctly released
under all circumstances. Both rt73usb as rt2500usb
didn't release the mutex under certain conditions
when the register access failed. Obviously such
failure would lead to deadlocks.

In addition under similar circumstances when the
bbp register couldn't be read the value must be
set to 0xff to indicate that the value is wrong.
This too didn't happen under all circumstances.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add new rt73usb USB ID for D-Link DWA111
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There was an obvious typo in LED structure
initialization which caused the radio and quality/activity
leds to be incorrectly initialized which resulted in
the leds not being enabled.

Additionally add the rt2x00led_led_activity() handler
that will enable TX/RX activity leds when the radio
is being enabled.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Implement triggers inside rt2x00 itself based
on input from mac80211. This replaces the method
of using the mac80211 trigger events which do
not work for USB drivers due to the scheduling
requirement.

After this patch RT2500USB_LEDS and RT73USB_LEDS
no longer need to be tagged as broken since they
now support LED handling again without having to
check for in_atomic().
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The TO_DS filter does not only depend on the FIF_PROMISC_IN_BSS flag
provided by mac80211, but also on the intf_ap_count count.
This makes sense, since when Master mode is active, we should all frames
that are send to the active AP (the device itself).

This means that when an interface is added we should force the
packet filter to be updated during the next mac80211 call of
configure_filter() to make sure the intf_ap_count field is checked.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt73usb and rt2500usb used in_atomic to determine
if a configuration step should be rescheduled or not.
Since in_atomic() is not a valid method to determine
if sleeping is allowed we should fix the way this is handled
by adding a new flag to rt2x00.

In addition mark LED class support for the drivers broken
since that also uses the broken in_atomic() method but
so far no solution exists to have LED triggers work only
in scheduled context.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The rxdone_entry_desc structure contains 3 fields
which are always 1 or 0. We can safe 8 bytes by
replacing them with a single dev_flags fields which
contain the flags for those settings.

Additionally we can remove the OFDM flag since it
is no longer used since the introduction of the
SIGNAL_PLCP flag.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds the id for Corega CG-WLUSB2GPX.
Signed-off-by: NMasakazu Mokuno <mokuno@sm.sony.co.jp>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After sampling hundreds of RX frame descriptors,
the results were conclusive:
- The Ralink documentation regarding the SIGNAL and RSSI are wrong.

It turns out that of the 5 BBR registers, we should not use BBR0 and BBR1
for SIGNAL and RSSI respectively, but actually BBR1 and BBR2.
BBR0 does show values, but the exact meaning remains unclear,
but they cannot be translated into a SIGNAL or RSSI field.
BBR3, BBR4 and BBR5 are always 0, so their meaning is unknown.

As it turns out, the reported SIGNAL is the PLCP value, this
in contradiction to what was expected looking at rt2500pci which
only reported the PLCP values for OFDM rates and bitrate values
for CCK rates.

This means we should let the driver raise the flag about the contents
of the SIGNAL field so rt2x00lib can always do the right thing based
on what the driver reports.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Whatever mode we are in, according to the legacy drivers
we should always enable TSF ticking/counting.
We should also always enable the TBCN/TBTT field,
this field is only disabled during beacon regeneration.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rename config_preamble() to config_erp() and cleanup argument
list by putting it all into a single structure.
This will make the function more meaningful and easier to
expand later. This second option is mostly intended to make
the patch "mac80211: proper short-slot handling" from Johannes Berg
easier to apply for rt2x00.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2x00lib should filter SW diversity out before sending any configuration
changes to the driver. When rt2x00lib fails to do this, it is important
that such events are reported because it _must_ be fixed.
So upgrading the error level to a BUG_ON() which will make sure
this bug gets noticed whenever it happens.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2x00lib depended on 2 crc algorithms because rt61/rt73
use a different algorithm then rt2800. This means that
even when only 1 algorithm was needed, the dependency was
still present for both.
By moving the checksum generation to the driver we can clean
up 2 annoying flags (which indicated which checksum was required)
and move the dependency to where it belongs: the driver.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix trivial log message.
Signed-off-by: NLuis Correia <luis.f.correia@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should not write 0 to the beacon sync register during
config_intf() since that will clear out the beacon interval
and forces the beacon to be send out at the lowest interval.
(reported by Mattias Nissler).

The side effect of the same bug was that while working with
multiple virtual AP interfaces a change for any of those
interfaces would disable beaconing untill an beacon update
was provided.

This is resolved by only updating the TSF_SYNC value during
config_intf(). In update_beacon() we disable beaconing
temporarily to prevent fake beacons to be transmitted.
Finally kick_tx_queue() will enable beaconing again.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rxdesc->size is unitialized before the desriptor has been read.
Move the truncation of the sk buffer to the moment all variables
have been initialized.
Signed-off-by: NMattias Nissler <mattias.nissler@gmx.de>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

skbdesc->desc_len is uninitialized at the start
of the function. So it is a _bad_ idea to use it...
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some architectures give problems when reading
RX frame descriptor words when the descriptor
is not aligned on a 4 byte boundrary.

Due to optimalizations for the ieee80211 payload
4 byte alignment, it is no longer guarenteed
that the descriptor is placed on the 4 byte
boundrary (In fact, for rt73usb it is absolutely
never aligned to 4 bytes, for rt2500usb it depends
on the length of the payload).

This will copy the descriptor to a 4 byte aligned
location before it is read for the first time.
This will also move the payload data alignment
in rt2x00usb (instead of inside the driver) where
it has always belonged.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On rt73 and rt61 disabling reception of multicast packets also disables
broadcast traffic which we never want to do. Therefore we should never
disable multicast.
Signed-off-by: NAdam Baker <linux@baker-net.org.uk>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The async vendor requests are a ugly hack which is not working correctly.
The proper fix for the scheduling while atomic issue is finding out why
we can't use led classes for USB drivers and fix that.

Just replace all async calls with the regular ones and print an
error for the disallowed LED configuration attempts. That will
help in determining which led class is causing the problem.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don't wildly pass any number for num_rates to rt2x00lib,
instead pass which type of rates are supported (CCK, OFDM).
Same for num_modes but then for the 2GHZ and 5GHZ band.

This makes the interface look much nicer and makes
extending it later easier.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Specifications indicate the TSF registers are read-only,
so there is no point in writing 0 to those registers.

As far as I know there isn't another way to reset the
TSF registers. So removing these callbacks will notify
mac80211 about the lack of support.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ACK_CTS frame is a control frame, this means
dropping the frame depends on the FIF_CONTROL flag
for filtering.

This also fixes an obvious typo in register definition.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds a new flag for the skb_frame_desc structure which is used to tag
rts/cts frames that are generated by the driver. Through the tag we can
recognize frames we have generated ourselves, so we don't report their tx
status to mac80211.

This patch is based on the original patch by
Mattias Nissler <mattias.nissler@gmx.de>.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 sends the txpower to use during config(),
we already store it in the rt2x00_dev structure.
When writing the descriptor correctly initialize
the txpower field with this value to make sure
all frames are send out with the correct tx power.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

skbdesc->data_len was not initialized correctly
in rt2x00pci, rt2x00usb, rt2500usb and rt73usb.

The value was set to queue->data_size which
means that the incorrect frame size was pased
to the upper layers.

Correctly base the value on either the skb->len,
or the rx frame size passed to the driver by the
device.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The second eeprom recovery message is about
the RSSI offset for ieee802.11 A.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the debug messages regarding initialization from
EEPROM. The values are vendor specific, and are not really
needed for debug purposes. If they ever become usefull we
still have access to them through debugfs which also
prints the exact same values...
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add kerneldoc for vendor request functions in rt2x00usb.
Add asynchroneous vendor request function in rt2x00usb.

With the availability of the asynchroneuous vendor request
we can now enable LED class support for rt2500usb and rt73usb.
Since LED handling is not important, it doesn't really matter
if a register call fails (This solution is better then no
LED class support at all).
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Make use of the led triggers provided by mac80211 to control
the led status. This can be enabled through a per-driver
configuration option which will automatically enable the
generic handler in rt2x00lib.

This has been enabled for rt2500usb and rt73usb for the moment
since the led class will call set_brightness in irq context which
will not work correctly with the usb drivers who need to sleep.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch creates new cfg80211 wiphy API for channel and bitrate
registration and converts mac80211 and drivers to the new API. The
old mac80211 API is completely ripped out. All drivers (except ath5k)
are updated to the new API, in many cases I expect that optimisations
can be done.

Along with the regulatory code I've also ripped out the
IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
unnecessary if the hardware simply gives us whatever channels it wants
to support and we then enable/disable them as required, which is pretty
much required for travelling.

Additionally, the patch adds proper "basic" rate handling for STA
mode interface, AP mode interface will have to have new API added
to allow userspace to set the basic rate set, currently it'll be
empty... However, the basic rate handling will need to be moved to
the BSS conf stuff.

I do expect there to be bugs in this, especially wrt. transmit
power handling where I'm basically clueless about how it should work.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As Johannes Berg indicated the BEACON and AFTER_BEACON
queue indeces in mac80211 should be removed because they
are too hardware specific. This patch adds the queue index
defines into rt2x00queue.h and removes the dependency of
the defines inside mac80211.h.

Also move rt2x00pci_beacon_update() into rt2400pci and
rt2500pci individually since it is no longer a generic
function since rt61 and rt2800 no longer use that.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt73usb doesn't have a 5th queue, correctly initialize hw->queues
rt61pci had a 5th queue but was removed recently, correctly initialize
hw->queues and remove the last remnants.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rework the interface handling. Delete the interface structure
and replace it with a per-interface structure. This changes the
way rt2x00 handles the active interface drastically.

Copy ieee80211_bss_conf to the this rt2x00_intf structure during
the bss_info_changed() callback function. This will allow us to
reference it later, and removes the requirement for the device flag
SHORT_PREAMBLE flag which is interface specific.

Drivers receive the option to give the maximum number of virtual
interfaces the device can handle. Virtual interface support:
rt2400pci: 1 sta or 1 ap, * monitor interfaces
rt2500pci: 1 sta or 1 ap, * monitor interfaces
rt2500usb: 1 sta or 1 ap, * monitor interfaces
rt61pci: 1 sta or 4 ap, * monitor interfaces
rt73usb: 1 sta or 4 ap, * monitor interfaces

At the moment none of the drivers support AP and STA interfaces
simultaneously, this is a hardware limitation so future support
will be very unlikely.

Each interface structure receives its dedicated beacon entry,
with this we can easily work with beaconing while multiple master
mode interfaces are currently active.

The configuration handlers for the MAC, BSSID and type are
often called together since they all belong to the interface
configuration. Merge the 3 configuration calls and cleanup
the API between rt2x00lib and the drivers. While we are cleaning
up the interface configuration anyway, we might as well clean up
the configuration handler as well.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The driver should select what CRC algorithm is required
when performing a checksum on the firmware.

rt61pci & rt73usb require crc-itu-t
rt2800pci & rt2800usb require crc-ccitt

Legacy 2800pci/usb driver uses crc-itu-t + bit order reversion,
but that is just inefficient especially since the end result is
the same as a different algorithm which is also available as library. ;)
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This introduces a big queue handling overhaul, this also
renames "ring" to "queues".

Move queue handling into rt2x00queue.c and the matching header,
use Kerneldoc to improve rt2x00 library documentation.

Access to the queues is now protected under a spinlock, this
to prevent race conditions which could corrupt the indexing
system of the queue.

Each queue entry allocates x bytes for driver/device specific data,
this cleans up the queue structure significantly and improves
code readability.

rt2500usb no longer needs 2 entries in the beacon queue to correctly
send out the guardian byte. This is now handled in the entry specific
structure.

rt61 and rt73 now use the correct descriptor size for beacon frames,
since this data is written into the registers not the entire TXD
descriptor was used but instead of a subset of it named TXINFO.

Finally this also fixes numerous other bugs related to incorrect
beacon handling or beacon related code.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds 2 new states which both are used to toggle
the RX. These new states are required for usage
inside the link tuner thread, because the normal
RX toggling will stop the link tuner thread.
While it is possible that the link tuner thread itself
is the caller of the RX toggle (when using software
antenna diversity).
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>