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: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn 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: NGertjan van Wingerde <gwingerde@kpnplanet.nl>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn 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: 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>

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: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn 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: 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>

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: NIvo van Doorn <IvDoorn@gmail.com>
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>

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>