- 01 2月, 2011 4 次提交
-
-
由 Helmut Schaa 提交于
Enable the txstatus tasklet when interrupts are enabled and disable it together with the interrupts. Also make the txstatus tasklet useful even without the tx status FIFO and make use of the generic rt2x00 tasklet initialization macro. Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
No functional changes, just preparation for moving interrupt handling to tasklets. The tasklets are disabled by default. Drivers making use of them need to enable the tasklets when the device state is set to IRQ_ON. Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
Allow the beacondone and pretbtt functions to update the beacon from atomic context by using the beacon update functions with caller locking. This is a preparation for moving the periodic beacon handling into tasklets that require atomic context. Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
This patch allows to dynamically remove beaconing interfaces without shutting beaconing down on all interfaces. The only place to start and stop beaconing are now the start- and stop_queue callbacks. Hence, we can remove some register writes during interface bring up (config_intf) and only write the correct sync mode to the register there. When multiple beaconing interfaces are present we should enable beaconing as soon as mac80211 enables beaconing on at least one of them. The beacon queue gets stopped when the last beaconing interface was stopped by mac80211. Therefore, introduce another interface counter to keep track ot the number of enabled beaconing interfaces and start or stop the beacon queue accordingly. To allow single interfaces to stop beaconing, add a new driver callback clear_beacon to clear a single interface's beacon without affecting the other interfaces. Don't overload the clear_entry callback for clearing beacons as that would introduce additional overhead (check for each TX queue) into the clear_entry callback which is used on the drivers TX/RX hotpaths. Furthermore, the write beacon callback doesn't need to enable beaconing anymore but since beaconing should be disabled while a new beacon is written or cleared we still disable beacon generation and enable it afterwards again in the driver specific callbacks. However, beacon related interrupts should not be disabled/enabled here, that's solely done from the start- and stop queue callbacks. It would be nice to stop the beacon queue just before the beacon update and enable it afterwards in rt2x00queue itself instead of the current implementation that relies on the driver doing the right thing. However, since start- and stop_queue are mutex protected we cannot use them for atomic beacon updates. Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 1月, 2011 1 次提交
-
-
由 Bruno Randolf 提交于
Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping channel numbers in the 2GHz and 5GHz band we can't map from channel to frequency without knowing the band. This is no problem as in most contexts we know the band. In places where we don't know the band (and WEXT compatibility) we assume the 2GHz band for channels below 14. This patch does not implement all channel to frequency mappings defined in 802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz channels as well as 802.11y channels have been omitted. The following drivers have been updated to reflect the API changes: iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx. The drivers have been compile-tested only. Signed-off-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com> Acked-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 1月, 2011 2 次提交
-
-
由 Helmut Schaa 提交于
Instead of protecting delayed_flags with a spinlock use atomic bitops to make the code more readable. Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Stezenbach 提交于
When DRIVER_REQUIRE_TXSTATUS_FIFO is set, intialize the txstatus_fifo, but initialize rt2x00dev->txstatus_tasklet only when both DRIVER_REQUIRE_TXSTATUS_FIFO and rt2x00dev->ops->lib->txstatus_tasklet are set. This allows the txstatus_fifo to be used by rt2800usb which does not use txstatus_tasklet. Signed-off-by: NJohannes Stezenbach <js@sig21.net> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 21 12月, 2010 1 次提交
-
-
由 Johannes Stezenbach 提交于
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=24892Signed-off-by: NJohannes Stezenbach <js@sig21.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 12月, 2010 5 次提交
-
-
由 Ivo van Doorn 提交于
Add a queue entry flag ENTRY_DATA_STATUS_PENDING, which can be used to indicate a queue entry has returned from the hardware and is waiting for status processing. Using this flag we can add some extra sanity checks to prevent queue corruption. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Add the rt2x00_dmastart function to rt2x00lib which marks the queue_entry as "owned by device", and increased the Q_INDEX number. This cleanups up the index handling by rt2x00lib which at until so far used hackish approaches to keep the RX queue index numbering sane. The rt2x00pci.c changes are from Helmut Schaa Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Add a new command to the queue handlers: "flush", this moves the flush() callback from mac80211 into rt2x00queue and adds support for flushing the RX queue as well. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Add wrapper functions in rt2x00queue.c to start & stop queues. This control must be protected using a mutex. Queues can also be paused which will halt the flow of packets between the driver and mac80211. This doesn't require a mutex protection. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
As part of the queue refactoring, change the queue callback function names to have 3 different actions: start, kick & stop. We can now also remove the STATE_RADIO_RX_ON/STATE_RADIO_RX_OFF device_state flags, and replace the usage with using the start_queue/stop_queue callback functions. This streamlines the RX queue handling to the similar approach as all other queues. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 12月, 2010 1 次提交
-
-
由 Johannes Stezenbach 提交于
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. Signed-off-by: NJohannes Stezenbach <js@sig21.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 18 11月, 2010 1 次提交
-
-
由 RA-Jay Hung 提交于
Put the assignment of header_length after pull out extra tx headroom Signed-off-by: NRA-Jay Hung <jay_hung@ralinktech.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 11月, 2010 3 次提交
-
-
由 Ivo van Doorn 提交于
As part of the queue refactoring, the rt2x00lib_toggle_rx can be removed and replaced with the call directly to the set_device_state callback function. We can remove the STATE_RADIO_RX_ON_LINK and STATE_RADIO_RX_OFF_LINK, as it was only used for special behavior inside rt2x00lib rather then the drivers. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mark Einon 提交于
rt2x00dev.c:689: ERROR: spaces required around that '=' (ctx:WxV) Signed-off-by: NMark Einon <mark.einon@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
By not scheduling the TX/RX completion worker threads when Radio is disabled, or hardware has been unplugged, the queues cannot be completely cleaned. This causes crashes when the hardware has been unplugged while the radio is still enabled. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 10月, 2010 4 次提交
-
-
由 Ivo van Doorn 提交于
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: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
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: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
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: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
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: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 06 10月, 2010 2 次提交
-
-
由 Helmut Schaa 提交于
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: [<f8d2d901>] :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:[<f8d2d901>] 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: [<fa00eaec>] rt2x00queue_init_queues+0x5c/0x90 [rt2x00lib] [<fa00c629>] rt2x00lib_enable_radio+0x29/0xa0 [rt2x00lib] [<fa00ca3d>] rt2x00lib_start+0x5d/0xd0 [rt2x00lib] [<fa177d4c>] ieee80211_do_open+0x21c/0x510 [mac80211] [<c066c366>] dev_open+0x56/0xb0 [<c0668ad0>] dev_set_rx_mode+0x20/0x40 [<c066a67f>] dev_change_flags+0x7f/0x190 [<c06b1495>] devinet_ioctl+0x515/0x690 [<c0668d24>] __dev_get_by_name+0x74/0x90 [<c065d3f0>] sock_ioctl+0xd0/0x240 [<c065d320>] sock_ioctl+0x0/0x240 [<c018179b>] vfs_ioctl+0x2b/0x90 [<c0181a5b>] do_vfs_ioctl+0x25b/0x2a0 [<c0181af6>] sys_ioctl+0x56/0x70 [<c0103262>] syscall_call+0x7/0xb [<c0700000>] 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: [<f8d2d901>] rt2800pci_clear_entry+0x1/0x40 [rt2800pci] SS:ESP 0068:f6d75e4c ---[ end trace cff9a5c094bb8837 ]--- Reported-by: NJoshua Smith <jesmith@kaon.com> Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
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: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 9月, 2010 1 次提交
-
-
由 Ivo van Doorn 提交于
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 <helmut.schaa@googlemail.com> for the implementation for watchdog for rt2800pci. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 26 8月, 2010 1 次提交
-
-
由 Ivo van Doorn 提交于
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=16358Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 8月, 2010 3 次提交
-
-
由 Ivo van Doorn 提交于
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: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
At some points, some drivers can't report the full TX status information. This can happen for the UNKNOWN state, or the FAILURE state (in case the URB failed). Add a wrapper function to simplify reporting the empty TX information. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Move all TX and RX completion handling into a work structure, which is handeled on the mac80211 workqueue. This simplifies the code in rt2x00lib since it no longer needs to check if the device is USB or PCI to decide which mac80211 function should be used. In the watchdog some changes are needed since it can no longer rely on the TX completion function to be run while looping through the entries. (Both functions now work on the same workqueue, so this would deadlock). So the watchdog now waits for the URB to return, and handle the TX status report directly. As a side-effect, the debugfs entry for the RX queue now correctly displays the positions of the INDEX and INDEX_DONE counters. This also implies that it is not possible to perform checks like queue_empty() and queue_full() on the RX queue. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 7月, 2010 1 次提交
-
-
由 Stephen Boyd 提交于
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: [<ffffffff8105fe59>] register_lock_class+0x152/0x31f [<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111 [<ffffffff81061bde>] __lock_acquire+0xce/0xcf4 [<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf [<ffffffff81492aef>] ? _raw_spin_unlock_irqrestore+0x33/0x41 [<ffffffff810628d5>] lock_acquire+0xd1/0xf7 [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e [<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e [<ffffffff8104f136>] cancel_work_sync+0xb/0xd [<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib] [<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib] [<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52 [<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb] [<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb] [<ffffffff813468bd>] usb_probe_interface+0x151/0x19e [<ffffffff812ea08e>] driver_probe_device+0xa7/0x136 [<ffffffff812ea167>] __driver_attach+0x4a/0x66 [<ffffffff812ea11d>] ? __driver_attach+0x0/0x66 [<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89 [<ffffffff812e9efd>] driver_attach+0x19/0x1b [<ffffffff812e9b64>] bus_add_driver+0xb4/0x204 [<ffffffff812ea41b>] driver_register+0x98/0x109 [<ffffffff813465dd>] usb_register_driver+0xb2/0x173 [<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb] [<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb] [<ffffffff81000203>] do_one_initcall+0x6d/0x17a [<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0 [<ffffffff8100296b>] system_call_fastpath+0x16/0x1b Signed-off-by: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 7月, 2010 5 次提交
-
-
由 Helmut Schaa 提交于
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: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
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: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
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: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
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: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
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: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 7月, 2010 2 次提交
-
-
由 Gertjan van Wingerde 提交于
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: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
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: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 6月, 2010 2 次提交
-
-
由 Helmut Schaa 提交于
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: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
TXDONE_FALLBACK doesn't express if the frame was sent successful or not. It only tells us that the hw used fallback rates for retries. Hence, don't use TXDONE_FALLBACK as success indicator. Before this patch we reported success to the rate control algorithm which was wrong in a number of cases and might have lead to improper tx rate selections. Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 03 6月, 2010 1 次提交
-
-
由 Gertjan van Wingerde 提交于
Instead of fiddling with the skb->data pointer and thereby risking out of bounds accesses, properly reserve the space needed in an skb for descriptors. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
-