This fixes a "BUG: unable to handle kernel paging request"
bug in rt73usb which was caused by killing the guardian_urb
while it had never been allocated for rt73usb.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2x00lib_beacondone() is called from interrupt context,
this means we cannot use the mac80211 interface iterator
that uses the rtnl lock (since that uses a mutex which can sleep).
Instead we should use the atomic mac80211 interface iterator.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the antenna configuration has changed we should reset
the antenna RSSI value. Otherwise the value will be influenced
by the previous configuration quality which in turn will affect
the antenna diversity.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Link quality estimation became quite low for all rt2x00 drivers
because the number of retries it took to send the frame were
counted as failure.
This does not correspond to the legacy driver link quality calculation,
by not counting it we will send somewhat more optimistic values to
mac80211.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the tx() handler runs while the device has disapeared,
we did return NETDEV_TX_OK but didn't free the skb.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When, for some reason, the rt2x00pci module fails to allocate DMA memory for
the queues, it tries to undo the complete initialization of the PCI device,
including freeing of the irq. This results in the following error in dmesg, as
the irq hadn't been requested yet:

[  78.123456] Trying to free already-free IRQ 17

Fix this by implementing proper error handling code, instead of just using the
full uninitialization function.
Signed-off-by: NGertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During initialization the initialize() callback function
in rt2x00pci and rt2x00usb will cleanup the mess they made.

rt2x00lib shouldn't call uninitialize because the callback function already
cleaned up _and_ the DEVICE_INITIALIZED isn't set which causes the
rt2x00lib_uninitialize() to halt directly anyway. All that is required
to be cleaned up by rt2x00lib is the queue, and that can be done by
calling rt2x00queue_uninitialize() directly.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2x00pci allocates DMA for descriptor and data,
rt61pci doesn't use this for the beacon, but it can
use the descriptor part as temporary buffer instead
of using pskb_expand_head().
Using this temporary buffer is obviously much better
then reallocating the skb buffer...

At the same time we can set the data length for the
beacon queue at 0, to make sure no DMA is allocated for
data (but just for the descriptor).
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>

The timing settings for 1MBs should exclude
the short preamble bit since that only applies
to 2MBs, 5.5MBs and 11MBs.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In rt2x00lib_intf_scheduled_iter() we use the hw->beacon_update()
callback function. This means that it should behave similarly as mac80211
when that uses the function.

This means that the skb should only be freed when beacon_update() has failed,
otherwise the driver is the owner and is responsible for freeing the buffer.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The layer above will free the skb in an error case.
Signed-off-by: NDaniel Wagner <wagi@monom.org>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now rt2x00lib handles the initial configure_filter() command, we can
directly call lib->config_filter() in scheduled context since the
called function will no longer check if anything has changed (which is
now handled in rt2x00lib as well).

This fixes a endless loop with USB drivers where the config_filter
command was scheduled time and time again without sending any command
to the device.
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>

Invert the check for scheduling the packet_filter configuration.
When DRIVER_REQUIRE_SCHEDULED is not set we should immediately
configure the the filter.

This fixes the 'infinite calls to rt2x00mc_configure_filter'
bug reported by Bas Hulsken.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These small changes restore the rt2x00 sources to the way Ivo intended.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some hardware never seem to accept the "goto sleep" command, since the legacy
drivers don't have suspend and resume handlers the entire code for it was
basically a educated guess (based on the "enable radio" code).
This patch will only print a warning when the "goto sleep" command fails, and
just continues as usual. Perhaps that means the device will not reach a sleep
state and consumes more power then it should, but it is equally possible it
simply needs some seconds longer to sleep. Anyway, by making the command
non-fatal it will not block the rest of the suspend procedure.
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>

It has been observed on rt2500pci hardware that some
frames received with signal 0x0C do not have the OFDM
flag set.

Signals can have 2 meanings:
 1) The PLCP value
 2) The bitrate * 10

For rt2500pci (1) is for frames received with a OFDM rate,
and (2) is for frames received with a CCK rate.
But 0x0C is a invalid bitrate value but is a valid PLCP
value for 54Mbs (obvious OFDM rate).
This means that it is possible that the hardware does not
set the OFDM bit correctly under all circumstances.
This results in rt2x00 failing to detect the rate and
mac80211 triggering a WARN_ON() and dropping the frame.

To bypass this, print a warning when such a frame is received,
and reset the rate to the lowest supported rate for the current band.
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>

Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Only rt2400pci can have the preamble bit set in the PLCP value,
for all other drivers it should not be cleared since that will
conflict with the plcp values for OFDM rates.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Version bump to 2.1.4
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>

Due to a terrible typo the RX DMA base address
was initialized to the beacon base address.
Obviously bad things happen with bugs like that....
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The basic rate which is configured in the register
should not match all supported rates, but only the _basic_ rates.

Fix this by adding a new flag to the rt2x00_rate structure
and whenever the mode is changed, loop over all available rates
for that band to get the basic rate mask.
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>

rt2x00dev isn't interested in the rt2x00leds_register() value
anyway. So lets make it return void to even prevent people from
assuming there is anybody interested in the returnvalue.
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>

When mac sets the IEEE80211_TXCTL_SEND_AFTER_DTIM flag, we should
check if the ATIM queue is available in the driver and put the
frame in that queue for proper behavior (send frame after beacon interval).
Unfortunately not all drivers have this ATIM queue, and will lack
this feature for now.
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>

The queue->lock could be grabbed from interrupt context,
which could lead to lockdep panic like this:

kernel: ======================================================
kernel: [ INFO: soft-safe -> soft-unsafe lock order detected ]
kernel: 2.6.25-0.95.rc4.fc9 #1
kernel: ------------------------------------------------------
kernel: rt2500pci/1251 [HC0[0]:SC0[1]:HE1:SE0] is trying to acquire:
kernel:  (&queue->lock){--..}, at: [<ffffffff88213339>] rt2x00queue_get_entry+0x5a/0x81 [rt2x00lib]
kernel:
kernel: and this task is already holding:
kernel:  (_xmit_IEEE80211){-...}, at: [<ffffffff8122e9a3>] __qdisc_run+0x84/0x1a9
kernel: which would create a new lock dependency:
kernel:  (_xmit_IEEE80211){-...} -> (&queue->lock){--..}
kernel:
kernel: but this new dependency connects a soft-irq-safe lock:
kernel:  (_xmit_ETHER){-+..}
kernel: ... which became soft-irq-safe at:
kernel:   [<ffffffffffffffff>] 0xffffffffffffffff
kernel:
kernel: to a soft-irq-unsafe lock:
kernel:  (&queue->lock){--..}
kernel: ... which became soft-irq-unsafe at:
kernel: ...  [<ffffffff810545a2>] __lock_acquire+0x62d/0xd63
kernel:   [<ffffffff81054d36>] lock_acquire+0x5e/0x78
kernel:   [<ffffffff812a1497>] _spin_lock+0x26/0x53
kernel:   [<ffffffff88212f98>] rt2x00queue_reset+0x16/0x40 [rt2x00lib]
kernel:   [<ffffffff88212fd4>] rt2x00queue_alloc_entries+0x12/0xab [rt2x00lib]
kernel:   [<ffffffff88213091>] rt2x00queue_initialize+0x24/0xf2 [rt2x00lib]
kernel:   [<ffffffff88212036>] rt2x00lib_start+0x3b/0xd4 [rt2x00lib]
kernel:   [<ffffffff88212609>] rt2x00mac_start+0x18/0x1a [rt2x00lib]
kernel:   [<ffffffff881b9a4b>] ieee80211_open+0x1f3/0x46d [mac80211]
kernel:   [<ffffffff8121d980>] dev_open+0x4d/0x8b
kernel:   [<ffffffff8121d41e>] dev_change_flags+0xaf/0x172
kernel:   [<ffffffff81224fc2>] do_setlink+0x276/0x338
kernel:   [<ffffffff81225198>] rtnl_setlink+0x114/0x116
kernel:   [<ffffffff812262fc>] rtnetlink_rcv_msg+0x1d8/0x1f9
kernel:   [<ffffffff8123649a>] netlink_rcv_skb+0x3e/0xac
kernel:   [<ffffffff8122611a>] rtnetlink_rcv+0x29/0x33
kernel:   [<ffffffff81235eed>] netlink_unicast+0x1fe/0x26b
kernel:   [<ffffffff81236224>] netlink_sendmsg+0x2ca/0x2dd
kernel:   [<ffffffff812103b3>] sock_sendmsg+0xfd/0x120
kernel:   [<ffffffff812105a8>] sys_sendmsg+0x1d2/0x23c
kernel:   [<ffffffff8100c1c7>] tracesys+0xdc/0xe1
kernel:   [<ffffffffffffffff>] 0xffffffffffffffff

This can be fixed by using the irqsave/irqrestore versions
during the queue->lock handling.
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>

When fixing up the packet alignment, if we had to add 2 bytes to the front of
the skb we need to remember to take them off the end afterwards. This fixes
reception of encrypted packets which were otherwise failing with an invalid
ICV.
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>

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>

In rt2x00lib_write_tx_desc() the skb->data and skb->len fields
were incorrectly used. For USB drivers both of those values
contain invalid data (skb->data points to the device descriptor,
skb->len contains the frame _and_ descriptor length).

Instead of using the skbuffer fields we should use the skbdesc
fields which are correctly initialized and contain all the data
that we need.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>