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>
Rename "frame" folder to "queue" folder,
add extra file to this folder which contains
statistics about all hardware queues. This will
help debugging and spotting problems in the
queue indexing system.
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>
Store the queue idx inside structure data_ring
Store the entry idx inside structure data_entry
This saves us a few calls to ARRAY_INDEX() which is now unused.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Initialize blob->data before moving the data pointer
Initialize blob->size based on blob->data size
This fixes the empty chipset file in debugfs.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds TX/RX frame dumping capabilities through debugfs.
The intention is that with this approach debugging of rt2x00 is
simplified since _all_ frames going in and out of the device
are send to debugfs as well along with additional information
like the hardware descriptor.
Based on the patch by Mattias Nissler.
Mattias also has some tools that will make the dumped frames
available to wireshark: http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The chipset debugfs entry already indicates it is about the chipset,
it only makes sense to also display the chipset version in there.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cleanup debugfs interface by moving the csr/bbp/rf/eeprom value/offset
entries into the "register" folder.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
DRV_NAME was always set to the KBUILD_MODNAME value,
lets clean everything up by removing DRV_NAME and just
use KBUILD_MODNAME directly.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Loosely based on the patch by Matthijs Kooijman,
this will add the dev_flags entry into debugfs which
will display rt2x00dev->flags.
This will allow easier debugging of flag handling.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ivo van Doorn