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

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2010-07-21T01:25:24+00:00

Conflicts:
	drivers/vhost/net.c
	net/bridge/br_device.c

Fix merge conflict in drivers/vhost/net.c with guidance from
Stephen Rothwell.

Revert the effects of net-2.6 commit 573201f36fd9c7c6d5218cdcd9948cee700b277d
since net-next-2.6 has fixes that make bridge netpoll work properly thus
we don't need it disabled.

Signed-off-by: David S. Miller

rt2x00: Fix lockdep warning in rt2x00lib_probe_dev()

2010-07-16T17:57:59+00:00

The rt2x00dev->intf_work workqueue is never initialized when a driver is
probed for a non-existent device (in this case rt2500usb). On such a
path we call rt2x00lib_remove_dev() to free any resources initialized
during the probe before we use INIT_WORK to initialize the workqueue.
This causes lockdep to get confused since the lock used in the workqueue
hasn't been initialized yet but is now being acquired during
cancel_work_sync() called by rt2x00lib_remove_dev().

Fix this by initializing the workqueue first before we attempt to probe
the device. This should make lockdep happy and avoid breaking any
assumptions about how the library cleans up after a probe fails.

phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60
Call Trace:
 [] register_lock_class+0x152/0x31f
 [] ? usb_control_msg+0xd5/0x111
 [] __lock_acquire+0xce/0xcf4
 [] ? trace_hardirqs_off+0xd/0xf
 [] ?  _raw_spin_unlock_irqrestore+0x33/0x41
 [] lock_acquire+0xd1/0xf7
 [] ? __cancel_work_timer+0x99/0x17e
 [] __cancel_work_timer+0xd0/0x17e
 [] ? __cancel_work_timer+0x99/0x17e
 [] cancel_work_sync+0xb/0xd
 [] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib]
 [] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib]
 [] ? __raw_spin_lock_init+0x31/0x52
 [] ? T.676+0xe/0x10 [rt2x00usb]
 [] rt2x00usb_probe+0x121/0x15e [rt2x00usb]
 [] usb_probe_interface+0x151/0x19e
 [] driver_probe_device+0xa7/0x136
 [] __driver_attach+0x4a/0x66
 [] ? __driver_attach+0x0/0x66
 [] bus_for_each_dev+0x54/0x89
 [] driver_attach+0x19/0x1b
 [] bus_add_driver+0xb4/0x204
 [] driver_register+0x98/0x109
 [] usb_register_driver+0xb2/0x173
 [] ? rt2500usb_init+0x0/0x20 [rt2500usb]
 [] rt2500usb_init+0x1e/0x20 [rt2500usb]
 [] do_one_initcall+0x6d/0x17a
 [] sys_init_module+0x9c/0x1e0
 [] system_call_fastpath+0x16/0x1b

Signed-off-by: Stephen Boyd 
Signed-off-by: John W. Linville

rt2x00: Use pretbtt irq for fetching beacons on rt2800pci

2010-07-12T20:05:35+00:00

Updating the beacon on pre tbtt instead of beacondone allows much lower
latency in regard to TIM updates. Hence, use the pre tbtt interrupt for
updating the beacon in rt2800pci (older devices don't provide a pre tbtt
interrupt).

Also, add a new driver flag to indicate if a driver has pre tbtt support
or not and implement the according behavior in rt2x00lib.

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

rt2x00: Implement broad- and multicast buffering

2010-07-12T20:05:35+00:00

Although mac80211 buffers broad- and mutlicast frames for us in AP mode
we still have to send them out after a DTIM beacon. Implement this
behavior by sending out the buffered frames when the beacondone
interrupt is processed.

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

rt2x00: Allow beacon update without scheduling a work

2010-07-12T20:05:34+00:00

Since all rt2x00 PCI drivers use threaded interrupts now we don't need
to schedule a work just to update the beacon. The only place where the
beacon still gets updated in atomic context is from the set_tim
callback. Hence, move the work scheduling there.

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

rt2x00: Convert rt2x00 to use threaded interrupts

2010-07-12T20:05:34+00:00

Use threaded interrupts for all rt2x00 PCI devices.

This has several generic advantages:
- Reduce the time we spend in hard irq context
- Use non-atmic mac80211 functions for rx/tx

Furthermore implementing broad- and multicast buffering will be
much easier in process context while maintaining low latency and
updating the beacon just before transmission (pre tbtt interrupt)
can also be done in process context.

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

rt2x00: Implement watchdog monitoring

2010-07-12T20:05:34+00:00

Implement watchdog monitoring for USB devices (PCI support can
be added later). This will determine if URBs being uploaded to
the hardware are actually returning. Both rt2500usb and rt2800usb
have shown that URBs being uploaded can remain hanging without
being released by the hardware.
By using this watchdog, a queue can be reset when this occurs.
For rt2800usb it has been tested that the connection is preserved
even though this interruption.

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

rt2x00: Move common txdone handling to rt2x00lib_txdone.

2010-06-30T19:00:50+00:00

Now that the write_tx_data functions are merged, also merge the relevant
parts of the txdone handling into common code, rather than {usb,pci}
specific code.

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

rt2x00: Implement tx mpdu aggregation

2010-06-30T19:00:48+00:00

In order to implement tx mpdu aggregation we only have to implement
the ampdu_action callback such that mac80211 allows negotiation of
blockack sessions.

The hardware will handle everything on its own as long as the ampdu
flag in the TXWI struct is set up correctly and we translate the tx
status correctly.

For now, refuse requests to start rx aggregation.

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

rt2x00: Fix tx status reporting when falling back to the lowest rate

2010-06-15T20:00:50+00:00

In some corner cases the reported tx rates/retries didn't match the really
used ones.

The hardware lowers the tx rate on each consecutive retry by 1 (but won't
fall back from MCS to legacy rates) _until_ it reaches the lowest one.

In case the frame wasn't sent succesful the number of retries is 7 and if
a rate index <7 was used the previous code reported negative rate indexes
which were then ignored by the rate control algorithm and mac80211.

Instead, report the remaining number of retries to have happened with
the lowest rate (index 0). This should give the rate control algorithm
slightly more accurate information about the used tx rates/retries.

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