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>
Some functions have grown rapidly in size over the last time,
some of those functions (like the rt2x00queue_create_tx_descriptor)
will further increase in size soon, so it is best to start cutting
it into logical pieces.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CONFIG_CRYPTO_COPY_IV is a bad name since it is part
of the driver requirements instead of a configuration option.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Mac80211 provides 2 structures to handle bitrates, namely
ieee80211_rate and ieee80211_tx_rate. To determine the short preamble
mode for an outgoing frame, the flag IEEE80211_TX_RC_USE_SHORT_PREAMBLE
must be checked on ieee80211_tx_rate and not ieee80211_rate (which rt2x00 did).
This fixes a regression which was triggered in 2.6.29-rcX as reported by Chris Clayton.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Tested-By: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The short preamble mode was not correctly detected during TX,
rt2x00 used the rate->hw_value_short field but mac80211 is not
using this field that way.
Instead the flag IEEE80211_TX_RC_USE_SHORT_PREAMBLE should be
used to determine if the frame should be send out using
short preamble or not.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move all code which determines the right TX descriptor
fields specific to crypto support into rt2x00crypto.c.
This makes the code in rt2x00queue more simpler and
better concentrates all crypto code into a single location.
With this we can also remove some ifdefs in rt2x00queue.c
since the code inside the ifdef is either very small, or
only calling empty functions (see empty function definitions
in rt2x00lib.h).
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2500usb supports hardware encryption.
rt2500usb supports up to 4 shared and pairwise keys.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Store retry limit values in the rt2x00dev structure.
This allows the removal of the FIXME where we assumed
the long retry is only used when working with RTS frames.
Instead we should check the current retry limit values
and decide if the required retry count for this frame
is a long or short retry.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The callback function write_tx_data() can only fail
when our ENTRY_OWNER_DEVICE_DATA flag on a queue entry
failed to determine the entry was not available and
it is in fact still owned by the hardware.
This means that if that function fails the queue
must be stopped in mac80211.
When rt2x00queue_get_queue() returns NULL in the TX
path, it means mac80211 has passed us an invalid queue,
although this should be impossible, it shouldn't hurt
if we send mac80211 a signal to stop the queue either.
Both issues can simply be resolved by removing their
manual failure handler and making them use the failure path
provided in rt2x00mac_tx().
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>
Merge the callback functions init_txentry() and
init_rxentry(). This makes life in rt2x00lib a
lot simpler and we can cleanup several functions.
rt2x00pci contained "fake" FIELD definitions for
descriptor words. This is not flexible since it
assumes the driver will always have the same field
to indicate if a driver is available or not.
This should be dependent on the driver, and we
should add a callback function for this.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A few changes to reduce checkpatch.pl errors in the rt2x00 driver. For
the most part, I only fixed cosmetic things, and left the actual 'code
flow' untouched (hopefully)!
Diff is against wireless-testing HEAD.
Signed-off-by: John Daiker <daikerjohn@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
So after the previous changes we were still unhappy with how
convoluted the API is and decided to make things simpler for
everybody. This completely changes the rate control API, now
taking into account 802.11n with MCS rates and more control,
most drivers don't support that though.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The hw_key pointer is used (and obviously NULL) after skb->cb is
memset to 0. This patch grabs the iv_len before the memset call.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Stephen Blackheath <tramp.enshrine.stephen@blacksapphire.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Free up 2 bytes in skb->cb to be used for multi-rate retry later.
Move iv_len and icv_len initialization into key alloc.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, virtual interface pointers passed to drivers might be
from monitor interfaces and as such completely uninitialised
because we do not tell the driver about monitor interfaces when
those are created. Instead of passing them, we should therefore
indicate to the driver that there is no information; do that by
passing a NULL value and adjust drivers to cope with it.
As a result, some mac80211 API functions also need to cope with
a NULL vif pointer so drivers can still call them unconditionally.
Also, when injecting frames we really don't want to pass NULL all
the time, if we know we are the source address of a frame and have
a local interface for that address, we can to use that interface.
This also helps with processing the frame correctly for that
interface which will help the 802.11w implementation. It's not
entirely correct for VLANs or WDS interfaces because there the MAC
address isn't unique, but it's already a lot better than what we
do now.
Finally, when injecting without a matching local interface, don't
assign sequence numbers at all.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The txop parameter is supported by rt61pci and rt73usb,
and thus should be written to the register instead
of using the fixed value set during initialization.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If a driver requests additional headroom it should
be mapped to DMA as well because it will be send to
the hardware as well (as form of extra descriptor).
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some of the flags should be accessed atomically to
prevent race conditions. The flags that are most important
are those that can change often and indicate the actual
state of the device, queue or queue entry.
The big flag rename was done to move all state flags to
the same naming type as the other rt2x00dev flags and
made sure all places where the flags were used were changed. ;)
Thanks to Stephen for most of the queue flags updates,
which fixes some of the most obvious consequences of the
race conditions. Among those the notorious:
rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.
rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.
rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.
Signed-off-by: Stephen Blackheath <tramp.enshrine.stephen@blacksapphire.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Various rt2x00 devices support hardware encryption.
Most of them require the IV/EIV to be generated by mac80211,
but require it to be provided seperately instead of within
the frame itself. This means that rt2x00lib should extract
the data from the frame and place it in the frame descriptor.
During RX the IV/EIV is provided in the descriptor by the
hardware which means that it should be inserted into the
frame by rt2x00lib.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The sequence counter can be accessed in IRQ context,
which means the lock protecting the counter should
be irqsave. To prevent making the entire intf->lock irqsave
without reason, create a new lock which only protects
the sequence counter.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the queues are being initialized the entry flags fields must be
reset to 0. When this does not happen some entries might still be
marked as "occupied" after an ifdown & ifup cycle which would trigger
errors when the entry is being accessed:
phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.
Please file bug report to http://rt2x00.serialmonkey.com.
This also fixes the mac80211 warning:
------------[ cut here ]------------
WARNING: at net/mac80211/tx.c:1238 ieee80211_master_start_xmit+0x30a/0x350 [mac80211]()
which was triggered by the queue error.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When IEEE80211_TX_CTL_ASSIGN_SEQ is not set,
the driver should disable hardware sequence counting
to make sure the mac80211 provided counter is used.
This fixes QOS sequence counting, since that is one
of the cases where mac80211 provides a seperate
sequence counter.
By moving the sequence counting code to rt2x00queue
we make sure that _all_ frames get the sequence counter,
including RTS/CTS and Beacon frames.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the new beacon handling from mac80211 we can
reorganize the beacon handling in rt2x00 as well.
This patch will move the function to the TX handlers,
and move all duplicate code into rt2x00queue.c.
After this change the descriptor helper functions
from rt2x00queue.c no longer need to be exported
outside of rt2x00lib and can be declared static.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As soon as an interface is enabled, and that interface is in adhoc or master mode,
the device will start raising beacondone interrupts. But before the first interrupt is
raised, mac80211 will probably not have send any beacons to the device yet, which
results in a NULL pointer error when the skb is being freed.
Note that the "raise beacondone interrupts without a beacon" is also a bug,
and will be addressed later. The more important bug however is preventing
the NULL pointer failt itself, since there might be other conditions that could trigger
it as well.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We only need 4 bytes of headroom for alignment
purposes in the RX frame. It was previously higher
for optimization purposes which are no longer
possible due to DMA mappings.
v2: Fix patch error
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When rt2x00queue_alloc_rxskbs() fails rt2x00queue_unitialize()
will be called which will free all rxskb. So we don't need
to do this in the rt2x00queue_alloc_rxskb() function as well.
rt2x00queue_free_skb() unmaps the DMA but doesn't clear the
allocation flag. Since the code is copied from rt2x00queue_unmap_skb()
anyway (and that function does clear the flag) we might as well
use that function directly.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With a bit of code moving to rt2x00lib within the
TX and RX paths we can now remove a lot of EXPORT_SYMBOL_GPL()
statements. This cleans up the interface between rt2x00lib
and the drivers and has the additional benefit that rt2x00pci
and rt2x00usb are trimmed down in size as well since they
have less to do.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current PCI drivers require a lot of pre-allocated DMA buffers. Reduce this
by using dynamically mapped skb's (using pci_map_single) instead of the pre-
allocated DMA buffers that are allocated at device start-up time.
At the same time move common RX path code into rt2x00lib from rt2x00pci and
rt2x00usb, as the RX paths now are now almost the same.
Signed-off-by: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In preparation of replacing the statically allocated DMA buffers with
dynamically mapped skbs, centralize the allocation of RX skbs to rt2x00queue.c
and let rt2x00pci already use them.
Signed-off-by: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the introduction of the ieee80211 fc handlers
we can now remove the rt2x00.h versions to use the
global versions.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Reviewed-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Replaced by the new helper ieee80211_has_morefrags which is
more consistent with the intent of the function.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When rt2x00pci will be switched over to dynamically mapped skb's
instead of statically allocated DMA buffers, it no longer can handle
alignment of RX packets in a copy step, and needs to implement the
same scheme as rt2x00usb does.
In order to make the patch on dynamically mapped skb's smaller,
already centralize the alignment handling into rt2x00lib. This allows
us to move more code in rt2x00lib, and thus remove code duplication
between rt2x00usb and rt2x00pci.
Signed-off-by: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
TX queues shouldn't be kicked after each frame that is put into the
queue. This could cause problems during RTS and CTS-to-self as well
as with fragmentation. In all those cases you want all frames to be
send out in a single burst. Off course we shouldn't let the queue fill
up entirely, thus we introduce a 10% threshold which, when reached,
will force the frames to be send out regardless of the frame.
In addition we should prevent queues to become full in such a way
that the tx() handler can fail. Instead of stopping the queue when
it is full, we should stop it when it is below the threshold.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The write_tx_data functions in rt2x00pci and rt2x00usb have
a lot in common. This moves that duplicate code into
rt2x00queue_write_tx_frame().
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
qid should be initialized to QID_BEACON and QID_ATIM
for the beacon and atim quue. This makes checking for
a particular queue much saner, and it shouldn't harm,
because the only places where the value is send to
the hardware, we are allowed to send any value we
want since it is only used as argument in the
TX done register.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch converts mac80211 and all drivers to have transmit
information and status in skb->cb rather than allocating extra
memory for it and copying all the data around. To make it fit,
a union is used where only data that is necessary for all steps
is kept outside of the union.
A number of fixes were done by Ivo, as well as the rt2x00 part
of this patch.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch modifies struct ieee80211_tx_control to give band
info and the rate index (instead of rate pointers) to drivers.
This mostly serves to reduce the TX control structure size to
make it fit into skb->cb so that the fragmentation code can
put it there and we can think about passing it to drivers that
way in the future.
The rt2x00 driver update was done by Ivo, thanks.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Split rt2x00lib_write_tx_desc() up into a TX descriptor initializor
and TX descriptor writer.
This split is required to properly allow mac80211 to move its
tx_control structure into the skb->cb array.
The rt2x00queue_create_tx_descriptor() function will read all tx control
information and convert it into a rt2x00 TX descriptor information structure.
After that function is complete, we have all information we needed from the
tx control structure and are free to start writing into the skb->cb array
for our own purposes.
rt2x00queue_write_tx_descriptor() will be in charge of really sending
the TX descriptor to the hardware and kicking the TX queue.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With the integration of the mac80211 multiqueue patches it has become possible that the
mac80211 layer modifies the number of TX queues that is stored inside the ieee80211_hw
structure, especially when multi-queue is not selected.
The rt2x00 drivers are not well suited to handle that situation, as they allocate the
queue structures before mac80211 has modified the number of queues it is going to use,
and also expect the number of allocated queues to match the hardware implementation.
Hence, ensure that rt2x00 maintains by itself the number of queues that the hardware
supports, and, at the same time, making is not dependent on the preservation of contents
inside a mac80211 structure.
Signed-off-by: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the rt2x00 queue enumeration as much as possible,
removing the usage of the mac80211 queue numbering
wherever it is possible.
This makes it easier for mac80211 to change it queue
identification scheme without having to deal with
big changes in the rt2x00 code.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As Adam Baker reported the queue->qid was not initialized
correctly. The QID_AC_BE was assigned to the RX ring.
This will move the queue initialization into a seperate function
and makes sure that all queues are initialized directly with the
correct qids.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When calculating the offset to add to the queue entry base to get the
individual entry's private data area the base address must be treated
as a char * not a struct queue_entry so we can do byte oriented
pointer arithmetic with it.
Signed-off-by: Adam Baker <linux@baker-net.org.uk>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When Q_INDEX is increased, the queue->length should be increased,
only when Q_INDEX_DONE is increased should queue_length be descreased.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ivo van Doorn