linux.git/drivers/net/wireless/rt2x00/rt2x00dev.c, branch v2.6.37

mac80211/rt2x00: add ieee80211_tx_status_ni()

2010-12-20T18:48:04+00:00

All rt2x00 drivers except rt2800pci call ieee80211_tx_status() from
a workqueue, which causes "NOHZ: local_softirq_pending 08" messages.

To fix it, add ieee80211_tx_status_ni() similar to ieee80211_rx_ni()
which can be called from process context, and call it from
rt2x00lib_txdone().  For the rt2800pci special case a driver
flag is introduced.

https://bugzilla.kernel.org/show_bug.cgi?id=24892

Signed-off-by: Johannes Stezenbach 
Signed-off-by: John W. Linville

rt2x00: Fix URB error handling

2010-10-11T19:04:26+00:00

kill_urb guarentees that when the function returns, the URB has
been fully killed. This means we don't need the extra sleeping
after the call to kill_urb.

kill_urb can however also guarentee the submit_urb to fail, as
a result, we must catch the return value from submit_urb an
correctly mark the entry as owned by the driver, and the
status as broken.

Signed-off-by: Ivo van Doorn 
Signed-off-by: John W. Linville

rt2x00: Fix dead queue when skb allocation failed

2010-10-11T19:04:26+00:00

When the RX skb allocation failed, we should recycle
the previously allocated skbuffer. By calling return
we would kill the RX queue completely since the
entry would be invalidated.

Signed-off-by: Ivo van Doorn 
Acked-by: Helmut Schaa 
Signed-off-by: John W. Linville

rt2x00: Validate MCS on RX path

2010-10-11T19:04:25+00:00

Similar to the PLCP signal and bitrates values,
we should validate the MCS value from the RX descriptor
before sending it to mac80211.

Signed-off-by: Ivo van Doorn 
Acked-by: Helmut Schaa 
Signed-off-by: John W. Linville

rt2x00: Simplify Queue function arguments

2010-10-11T19:04:25+00:00

A lot of functions accept a struct rt2x00_dev combined with
either a struct queue_entry or struct data_queue argument.
This can be simplified by only passing on the queue/entry
argument.

In cases where rt2x00_dev and a sk_buff are send together,
we can send the queue_entry instead.

rt2x00usb_alloc_urb and rt2x00usb_free_urb have a bit
of vague naming. Instead they allocate all the data which
belongs to a rt2x00 data queue entry.

Signed-off-by: Ivo van Doorn 
Acked-by: Helmut Schaa 
Signed-off-by: John W. Linville

rt2x00: Fix oops caused by error path in rt2x00lib_start

2010-10-05T17:35:29+00:00

When rt2x00lib_enable_radio fails to enable the radio, rt2x00lib_start
will call rt2x00queue_uninitialize to uninitialize the queues. Since,
the queues are not initialized here but already in rt2x00lib_initialize
we shouldn't uninitialize the queues here. Otherwise, a consecutive call
to rt2x00lib_start will oops (see below) because it assumes the queues
are already initialized.

BUG: unable to handle kernel NULL pointer dereference at 00000010
IP: [] :rt2800pci:rt2800pci_clear_entry+0x1/0x40
*pde = 00000000
Oops: 0000 [#1] SMP
Modules linked in: ... rt2800pci ...

Pid: 5995, comm: hostapd Not tainted (2.6.27.8 #1)
EIP: 0060:[] EFLAGS: 00210246 CPU: 3
EIP is at rt2800pci_clear_entry+0x1/0x40 [rt2800pci]
EAX: 00000000 EBX: f698863c ECX: 00200296 EDX: f8d2dee0
ESI: f6988600 EDI: f5b6f000 EBP: 00000000 ESP: f6d75e4c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process hostapd (pid: 5995, ti=f6d74000 task=f6ce2300 task.ti=f6d74000)
Stack: f698863c fa00eaec 00000000 f5b6f000 00000000 f7b67000 f5b6e280 fa00c629
      f5b6f000 00000000 fa00ca3d f7b67480 00000001 fa177d4c 01b6e890 f7b67000
      00000000 f7b67000 00000001 00001003 00001002 c066c366 f7b67000 c0668ad0
Call Trace:
 [] rt2x00queue_init_queues+0x5c/0x90 [rt2x00lib]
 [] rt2x00lib_enable_radio+0x29/0xa0 [rt2x00lib]
 [] rt2x00lib_start+0x5d/0xd0 [rt2x00lib]
 [] ieee80211_do_open+0x21c/0x510 [mac80211]
 [] dev_open+0x56/0xb0
 [] dev_set_rx_mode+0x20/0x40
 [] dev_change_flags+0x7f/0x190
 [] devinet_ioctl+0x515/0x690
 [] __dev_get_by_name+0x74/0x90
 [] sock_ioctl+0xd0/0x240
 [] sock_ioctl+0x0/0x240
 [] vfs_ioctl+0x2b/0x90
 [] do_vfs_ioctl+0x25b/0x2a0
 [] sys_ioctl+0x56/0x70
 [] syscall_call+0x7/0xb
 [] add_card+0xad0/0xba0
 =======================
Code: 83 78 08 0e 74 14 8b 02 8b 48 04 85 c9 0f 99 c0 0f b6 c0 c3 8d b6
      00 00 00 00 8b 02 8b 40 04 85 c0 0f 99 c0 0f b6 c0 c3 66 90 53 <8b>
      48 10 8b 58 08 8b 40 04 83 78 08 0e 74 15 8b 11 83 c2 04 8b
EIP: [] rt2800pci_clear_entry+0x1/0x40 [rt2800pci] SS:ESP 0068:f6d75e4c
---[ end trace cff9a5c094bb8837 ]---

Reported-by: Joshua Smith 
Signed-off-by: Helmut Schaa 
Signed-off-by: Ivo van Doorn 
Signed-off-by: John W. Linville

rt2x00: rework tx status handling in rt2800pci

2010-10-05T17:35:26+00:00

This patch changes the way tx status reports are handled by rt2800pci.
Previously rt2800pci would sometimes lose tx status reports as the
TX_STA_FIFO register is a fifo of 16 entries that can overflow in case
we don't read it often/fast enough. Since interrupts are disabled in the
device during the execution of the interrupt thread it happend sometimes
under high network and CPU load that processing took too long and a few
tx status reports were dropped by the hw.

To fix this issue the TX_STA_FIFO register is read directly in the
interrupt handler and stored in a kfifo which is large enough to hold
all status reports of all used tx queues.

To process the status reports a new tasklet txstatus_tasklet is used.
Using the already used interrupt thread is not possible since we don't
want to disable the TX_FIFO_STATUS interrupt while processing them and
it is not possible to schedule the interrupt thread multiple times for
execution. A tasklet instead can be scheduled multiple times which
allows to leave the TX_FIFO_STATUS interrupt enabled while a previously
scheduled tasklet is still executing.

In short: All other interrupts are handled in the interrupt thread as
before. Only the TX_FIFO_STATUS interrupt is partly handled in the
interrupt handler and finished in the according tasklet.

One drawback of this patch is that it duplicates some code from
rt2800lib. However, that can be cleaned up in the future once the
rt2800usb and rt2800pci tx status handling converge more.

Using this patch on a Ralink RT3052 embedded board gives me a reliable
wireless connection even under high CPU and network load. I've
transferred several gigabytes without any queue lockups.

Signed-off-by: Helmut Schaa 
Signed-off-by: Ivo van Doorn 
Signed-off-by: John W. Linville

rt2x00: Split watchdog check into a DMA and STATUS timeout

2010-08-31T18:22:25+00:00

The watchdog for rt2800usb triggers frequently causing all URB's
to be canceled often enough to interrupt the normal TX flow.
More research indicated that not the URB upload to the USB host
were hanging, but instead the TX status reports.

To correctly detect what is going on, we introduce Q_INDEX_DMA_DONE
which is an index counter between Q_INDEX_DONE and Q_INDEX and indicates
if the frame has been transfered to the device.

This also requires the rt2x00queue timeout functions to be updated
to differentiate between a DMA timeout (time between Q_INDEX and
Q_INDEX_DMA_DONE timeout) and a STATUS timeout (time between
Q_INDEX_DMA_DONE and Q_INDEX_DONE timeout)

All Q_INDEX_DMA_DONE code was taken from the RFC from
Helmut Schaa  for the implementation
for watchdog for rt2800pci.

Signed-off-by: Ivo van Doorn 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville

rt2x00: Fix max TX power settings

2010-08-25T18:34:55+00:00

During initialization each driver reads the default TX power
for each individual channel. However mac80211 only accepts the
maximum value (which is also handled as default value).

As a result, the TX power of the device was being limited to
the default value, which is often quite low compared to the
real maximum acceptable value.

This patch allows each driver to set the maximum value on a
per-channel basis which is forwarded to mac80211. The default
value will be preserved for now, in case we want to update
mac80211 to differentiate between the maximum and default txpower.

This fixes bug complaining about limited TX power values like:
https://bugzilla.kernel.org/show_bug.cgi?id=16358

Signed-off-by: Ivo van Doorn 
Acked-by: Helmut Schaa 
Signed-off-by: John W. Linville

rt2x00: Remove ieee80211_rx_status from rt2x00_dev

2010-08-16T19:26:43+00:00

rt2x00 was keeping a copy of ieee80211_rx_status embedded
into the rt2x00_dev structure. For each RX frame, this structure
was copied into the skb->cb where mac80211 would handle it further.

However at the moment only the fields current band, and frequency
were updated. Whereas the band was already provided directly within
the rt2x00_dev structure. Save a memcpy action, and reduce memory
a bit, by adding a curr_freq field to rt2x00_dev, and completely
remove the ieee80211_rx_status structure from rt2x00_dev.

Signed-off-by: Ivo van Doorn 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville