- 15 6月, 2008 4 次提交
-
-
由 Ivo van Doorn 提交于
TX queues shouldn't be kicked after each frame that is put into the queue. This could cause problems during RTS and CTS-to-self as well as with fragmentation. In all those cases you want all frames to be send out in a single burst. Off course we shouldn't let the queue fill up entirely, thus we introduce a 10% threshold which, when reached, will force the frames to be send out regardless of the frame. In addition we should prevent queues to become full in such a way that the tx() handler can fail. Instead of stopping the queue when it is full, we should stop it when it is below the threshold. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
rt2x00usb_kick_tx_queue() will loop over all entries within the INDEX_DONE->INDEX range and kick each entry which is pending to be kicked. This makes the kick_tx_queue approach work the same as with the PCI drivers which will allow for more code generalisation into rt2x00lib. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Reduce code duplication by moving led structure initialization into a per-driver function. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
* Reduce goto usage * Mark if-statements which are true on hardware error unlikely() * Cleanup debug messages This makes the code look nicer and be better optimized since the chance of hardware errors should be very small. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 5月, 2008 7 次提交
-
-
由 Johannes Berg 提交于
This patch converts mac80211 and all drivers to have transmit information and status in skb->cb rather than allocating extra memory for it and copying all the data around. To make it fit, a union is used where only data that is necessary for all steps is kept outside of the union. A number of fixes were done by Ivo, as well as the rt2x00 part of this patch. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
With the pending removal of the tx_control structure we can merge the RX and TX entry private data structure in advance. This will temporarily increase the required memory for the queue, but that overhead will only be limited. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
the rxdesc structure is properly memsetted before passed to the driver. This means we don't have to reinitialize the flags and dev_flags fields in the drivers again. This will prevent problems when the rxdone handler is adding flags in a earlier status and will make the code look nicer when we are adding more read attributes in the rxdone handler in the driver. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
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>
-
由 Ivo van Doorn 提交于
Due to usage of memmove() in rt2x00usb the descriptor can become corrupted because it is being overwritten by the data part. Overall having the descriptor in front of the frame is a bad idea, we can however use the skb->cb array for this task, since that contains more then enough room to hold the entire descriptor and preserve the information long enough. After this we can also cleanup the alignment code a bit to make it work a bit more flexible to allow for all kinds of odd header lengths. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
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>
-
由 Ivo van Doorn 提交于
Move the last remaining information details read from ieee80211_tx_control in the drivers to the txentry_desc structure. After this we can remove ieee80211_tx_control from the argument list for the callback function, which makes it easier when the control information is moved into skb->cb Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 5月, 2008 1 次提交
-
-
由 Bruno Randolf 提交于
trying to clean up the signal/noise code. the previous code in mac80211 had confusing names for the related variables, did not have much definition of what units of signal and noise were provided and used implicit mechanisms from the wireless extensions. this patch introduces hardware capability flags to let the hardware specify clearly if it can provide signal and noise level values and which units it can provide. this also anticipates possible new units like RCPI in the future. for signal: IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific IEEE80211_HW_SIGNAL_DB - dB difference to unspecified reference point IEEE80211_HW_SIGNAL_DBM - dBm, difference to 1mW for noise we currently only have dBm: IEEE80211_HW_NOISE_DBM - dBm, difference to 1mW if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has to provide the maximum value (max_signal) it reports in order for applications to make sense of the signal values. i tried my best to find out for each driver what it can provide and update it but i'm not sure (?) for some of them and used the more conservative guess in doubt. this can be fixed easily after this patch has been merged by changing the hardware flags of the driver. DRIVER SIGNAL MAX NOISE QUAL ----------------------------------------------------------------- adm8211 unspec(?) 100 n/a missing at76_usb unspec(?) (?) unused missing ath5k dBm dBm percent rssi b43legacy dBm dBm percent jssi(?) b43 dBm dBm percent jssi(?) iwl-3945 dBm dBm percent snr+more iwl-4965 dBm dBm percent snr+more p54 unspec 127 n/a missing rt2x00 dBm n/a percent rssi+tx/rx frame success rt2400 dBm n/a rt2500pci dBm n/a rt2500usb dBm n/a rt61pci dBm n/a rt73usb dBm n/a rtl8180 unspec(?) 65 n/a (?) rtl8187 unspec(?) 65 (?) noise(?) zd1211 dB(?) 100 n/a percent drivers/net/wireless/ath5k/base.c: Changes-licensed-under: 3-Clause-BSD Signed-off-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 5月, 2008 2 次提交
-
-
由 Ivo van Doorn 提交于
Add some helper macro's to help determining the the timeout for USB register access. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
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>
-
- 02 5月, 2008 1 次提交
-
-
由 Ivo van Doorn 提交于
There was an obvious typo in LED structure initialization which caused the radio and quality/activity leds to be incorrectly initialized which resulted in the leds not being enabled. Additionally add the rt2x00led_led_activity() handler that will enable TX/RX activity leds when the radio is being enabled. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 02 4月, 2008 2 次提交
-
-
由 Ivo van Doorn 提交于
Implement triggers inside rt2x00 itself based on input from mac80211. This replaces the method of using the mac80211 trigger events which do not work for USB drivers due to the scheduling requirement. After this patch RT2500USB_LEDS and RT73USB_LEDS no longer need to be tagged as broken since they now support LED handling again without having to check for in_atomic(). Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
The TO_DS filter does not only depend on the FIF_PROMISC_IN_BSS flag provided by mac80211, but also on the intf_ap_count count. This makes sense, since when Master mode is active, we should all frames that are send to the active AP (the device itself). This means that when an interface is added we should force the packet filter to be updated during the next mac80211 call of configure_filter() to make sure the intf_ap_count field is checked. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 26 3月, 2008 2 次提交
-
-
由 Ivo van Doorn 提交于
rt73usb and rt2500usb used in_atomic to determine if a configuration step should be rescheduled or not. Since in_atomic() is not a valid method to determine if sleeping is allowed we should fix the way this is handled by adding a new flag to rt2x00. In addition mark LED class support for the drivers broken since that also uses the broken in_atomic() method but so far no solution exists to have LED triggers work only in scheduled context. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
The rxdone_entry_desc structure contains 3 fields which are always 1 or 0. We can safe 8 bytes by replacing them with a single dev_flags fields which contain the flags for those settings. Additionally we can remove the OFDM flag since it is no longer used since the introduction of the SIGNAL_PLCP flag. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 3月, 2008 8 次提交
-
-
由 Ivo van Doorn 提交于
After sampling hundreds of RX frame descriptors, the results were conclusive: - The Ralink documentation regarding the SIGNAL and RSSI are wrong. It turns out that of the 5 BBR registers, we should not use BBR0 and BBR1 for SIGNAL and RSSI respectively, but actually BBR1 and BBR2. BBR0 does show values, but the exact meaning remains unclear, but they cannot be translated into a SIGNAL or RSSI field. BBR3, BBR4 and BBR5 are always 0, so their meaning is unknown. As it turns out, the reported SIGNAL is the PLCP value, this in contradiction to what was expected looking at rt2500pci which only reported the PLCP values for OFDM rates and bitrate values for CCK rates. This means we should let the driver raise the flag about the contents of the SIGNAL field so rt2x00lib can always do the right thing based on what the driver reports. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Whatever mode we are in, according to the legacy drivers we should always enable TSF ticking/counting. We should also always enable the TBCN/TBTT field, this field is only disabled during beacon regeneration. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Rename config_preamble() to config_erp() and cleanup argument list by putting it all into a single structure. This will make the function more meaningful and easier to expand later. This second option is mostly intended to make the patch "mac80211: proper short-slot handling" from Johannes Berg easier to apply for rt2x00. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
rt2x00lib should filter SW diversity out before sending any configuration changes to the driver. When rt2x00lib fails to do this, it is important that such events are reported because it _must_ be fixed. So upgrading the error level to a BUG_ON() which will make sure this bug gets noticed whenever it happens. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis Correia 提交于
Fix trivial log message. Signed-off-by: NLuis Correia <luis.f.correia@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
We should not write 0 to the beacon sync register during config_intf() since that will clear out the beacon interval and forces the beacon to be send out at the lowest interval. (reported by Mattias Nissler). The side effect of the same bug was that while working with multiple virtual AP interfaces a change for any of those interfaces would disable beaconing untill an beacon update was provided. This is resolved by only updating the TSF_SYNC value during config_intf(). In update_beacon() we disable beaconing temporarily to prevent fake beacons to be transmitted. Finally kick_tx_queue() will enable beaconing again. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mattias Nissler 提交于
rxdesc->size is unitialized before the desriptor has been read. Move the truncation of the sk buffer to the moment all variables have been initialized. Signed-off-by: NMattias Nissler <mattias.nissler@gmx.de> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Some architectures give problems when reading RX frame descriptor words when the descriptor is not aligned on a 4 byte boundrary. Due to optimalizations for the ieee80211 payload 4 byte alignment, it is no longer guarenteed that the descriptor is placed on the 4 byte boundrary (In fact, for rt73usb it is absolutely never aligned to 4 bytes, for rt2500usb it depends on the length of the payload). This will copy the descriptor to a 4 byte aligned location before it is read for the first time. This will also move the payload data alignment in rt2x00usb (instead of inside the driver) where it has always belonged. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 3月, 2008 12 次提交
-
-
由 Ivo van Doorn 提交于
The async vendor requests are a ugly hack which is not working correctly. The proper fix for the scheduling while atomic issue is finding out why we can't use led classes for USB drivers and fix that. Just replace all async calls with the regular ones and print an error for the disallowed LED configuration attempts. That will help in determining which led class is causing the problem. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Don't wildly pass any number for num_rates to rt2x00lib, instead pass which type of rates are supported (CCK, OFDM). Same for num_modes but then for the 2GHZ and 5GHZ band. This makes the interface look much nicer and makes extending it later easier. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
This adds a new flag for the skb_frame_desc structure which is used to tag rts/cts frames that are generated by the driver. Through the tag we can recognize frames we have generated ourselves, so we don't report their tx status to mac80211. This patch is based on the original patch by Mattias Nissler <mattias.nissler@gmx.de>. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
skbdesc->data_len was not initialized correctly in rt2x00pci, rt2x00usb, rt2500usb and rt73usb. The value was set to queue->data_size which means that the incorrect frame size was pased to the upper layers. Correctly base the value on either the skb->len, or the rx frame size passed to the driver by the device. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Remove the debug messages regarding initialization from EEPROM. The values are vendor specific, and are not really needed for debug purposes. If they ever become usefull we still have access to them through debugfs which also prints the exact same values... Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Add kerneldoc for vendor request functions in rt2x00usb. Add asynchroneous vendor request function in rt2x00usb. With the availability of the asynchroneuous vendor request we can now enable LED class support for rt2500usb and rt73usb. Since LED handling is not important, it doesn't really matter if a register call fails (This solution is better then no LED class support at all). Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Make use of the led triggers provided by mac80211 to control the led status. This can be enabled through a per-driver configuration option which will automatically enable the generic handler in rt2x00lib. This has been enabled for rt2500usb and rt73usb for the moment since the led class will call set_brightness in irq context which will not work correctly with the usb drivers who need to sleep. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
rt2500usb initialized the SIFS and EIFS without using the values coming from rt2x000lib. After this is fixed HWMODE_{A,B,G} is now unused and can be removed in favour of the ieee80211_band enumeration which could still be usefull later. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
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>
-
由 Ivo van Doorn 提交于
Rework the interface handling. Delete the interface structure and replace it with a per-interface structure. This changes the way rt2x00 handles the active interface drastically. Copy ieee80211_bss_conf to the this rt2x00_intf structure during the bss_info_changed() callback function. This will allow us to reference it later, and removes the requirement for the device flag SHORT_PREAMBLE flag which is interface specific. Drivers receive the option to give the maximum number of virtual interfaces the device can handle. Virtual interface support: rt2400pci: 1 sta or 1 ap, * monitor interfaces rt2500pci: 1 sta or 1 ap, * monitor interfaces rt2500usb: 1 sta or 1 ap, * monitor interfaces rt61pci: 1 sta or 4 ap, * monitor interfaces rt73usb: 1 sta or 4 ap, * monitor interfaces At the moment none of the drivers support AP and STA interfaces simultaneously, this is a hardware limitation so future support will be very unlikely. Each interface structure receives its dedicated beacon entry, with this we can easily work with beaconing while multiple master mode interfaces are currently active. The configuration handlers for the MAC, BSSID and type are often called together since they all belong to the interface configuration. Merge the 3 configuration calls and cleanup the API between rt2x00lib and the drivers. While we are cleaning up the interface configuration anyway, we might as well clean up the configuration handler as well. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
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>
-
由 Ivo van Doorn 提交于
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 2月, 2008 1 次提交
-
-
由 Ivo van Doorn 提交于
This adds 2 new states which both are used to toggle the RX. These new states are required for usage inside the link tuner thread, because the normal RX toggling will stop the link tuner thread. While it is possible that the link tuner thread itself is the caller of the RX toggle (when using software antenna diversity). Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-