- 13 Mar, 2008 30 commits
-
-
Ivo van Doorn authored
Only rt2400pci can have the preamble bit set in the PLCP value, for all other drivers it should not be cleared since that will conflict with the plcp values for OFDM rates. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
Version bump to 2.1.4 Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
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: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
Due to a terrible typo the RX DMA base address was initialized to the beacon base address. Obviously bad things happen with bugs like that.... Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
The basic rate which is configured in the register should not match all supported rates, but only the _basic_ rates. Fix this by adding a new flag to the rt2x00_rate structure and whenever the mode is changed, loop over all available rates for that band to get the basic rate mask. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
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: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
rt2x00dev isn't interested in the rt2x00leds_register() value anyway. So lets make it return void to even prevent people from assuming there is anybody interested in the returnvalue. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
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: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
When mac sets the IEEE80211_TXCTL_SEND_AFTER_DTIM flag, we should check if the ATIM queue is available in the driver and put the frame in that queue for proper behavior (send frame after beacon interval). Unfortunately not all drivers have this ATIM queue, and will lack this feature for now. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
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: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
rt2x00lib depended on 2 crc algorithms because rt61/rt73 use a different algorithm then rt2800. This means that even when only 1 algorithm was needed, the dependency was still present for both. By moving the checksum generation to the driver we can clean up 2 annoying flags (which indicated which checksum was required) and move the dependency to where it belongs: the driver. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
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>
-
Luis Correia authored
Fix trivial log message. Signed-off-by: Luis Correia <luis.f.correia@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adam Baker authored
When fixing up the packet alignment, if we had to add 2 bytes to the front of the skb we need to remember to take them off the end afterwards. This fixes reception of encrypted packets which were otherwise failing with an invalid ICV. Signed-off-by: Adam Baker <linux@baker-net.org.uk> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
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: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
In rt2x00lib_write_tx_desc() the skb->data and skb->len fields were incorrectly used. For USB drivers both of those values contain invalid data (skb->data points to the device descriptor, skb->len contains the frame _and_ descriptor length). Instead of using the skbuffer fields we should use the skbdesc fields which are correctly initialized and contain all the data that we need. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mattias Nissler authored
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: Mattias Nissler <mattias.nissler@gmx.de> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
skbdesc->desc_len is uninitialized at the start of the function. So it is a _bad_ idea to use it... Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mattias Nissler authored
The sizeof() operator was incorrectly applied to the pointer, not the struct. Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mattias Nissler authored
In the TX path, the driver didn't copy the TX control data structure. Thus, it was invalid in the TX done handler, causing serious trouble and misbehaviour. Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
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: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Harvey Harrison authored
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Rename members of ndis_80211_* structures to match the style of the rest of the code. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Rename enums and structures to ndis_80211_* for greater readability. Also change order so that enumerations are presented first. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Joe Perches authored
(test == true) is not nice. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
After my bit scan re-writing the SIOCSIWSCAN wext ioctl no longer supported scanning for a specific SSID. However, wpa_supplicant is a possible user of this ioctl, so here is code that add's this. While passing, removed even more of the debugfs-based scanning. You can (and should) the SIOCSIWSCAN to ask for scans, so there is no need for proprietary interfaces for scanning. And, besides, the scan result couldn't be used further, e.g. not for associating. Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adrian Bunk authored
Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adrian Bunk authored
Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adrian Bunk authored
Signed-off-by: Adrian Bunk <bunk@kernel.org> Cc: <Larry.Finger@lwfinger.net> Cc: <stefano.brivio@polimi.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adrian Bunk authored
b43_mac_{enable,suspend}() can now become static. Signed-off-by: Adrian Bunk <bunk@kernel.org> Acked-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 12 Mar, 2008 1 commit
-
-
David S. Miller authored
-
- 07 Mar, 2008 9 commits
-
-
Reinette Chatre authored
This is a change to a previous patch ("iwlwifi: 3945 split tx_complete to command and packet function") to ensure we do not have hardirq safe locks (priv->lock in this case) depend on hardirq unsafe locks. We only call iwl3945_tx_queue_reclaim while in a tasklet so we have to use the irqsafe version of the function. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
drivers/net/wireless/ath5k/debug.c: In function 'read_file_tsf': drivers/net/wireless/ath5k/debug.c:203: warning: format '%016llx' expects type 'long long unsigned int', but argument 4 has type 'u64' drivers/net/wireless/ath5k/debug.c:203: warning: format '%016llx' expects type 'long long unsigned int', but argument 4 has type 'u64' drivers/net/wireless/ath5k/debug.c: In function 'read_file_beacon': drivers/net/wireless/ath5k/debug.c:274: warning: format '%016llx' expects type 'long long unsigned int', but argument 4 has type 'u64' drivers/net/wireless/ath5k/debug.c:274: warning: format '%016llx' expects type 'long long unsigned int', but argument 4 has type 'u64' drivers/net/wireless/iwlwifi/iwl-4965.c: In function 'iwl4965_tx_status_reply_compressed_ba': drivers/net/wireless/iwlwifi/iwl-4965.c:3907: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'u64' drivers/net/wireless/iwlwifi/iwl-4965.c: In function 'iwl4965_rx_reply_compressed_ba': drivers/net/wireless/iwlwifi/iwl-4965.c:4039: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type '__le64' drivers/net/wireless/iwlwifi/iwl-4965.c:4046: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64' drivers/net/wireless/iwlwifi/iwl4965-base.c: In function 'iwl4965_tx_status_reply_tx': drivers/net/wireless/iwlwifi/iwl4965-base.c:3661: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'u64' Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
atheros hardware has a problem with the rx timestamp of some IBSS beacons when they caused a TSF update (they have the same BSSID). the rx timestamp is wrong especially if the beacon frames get bigger than 78 byte (at least on AR5213 and AR5414 hardware). in that case ath5k_extend_tsf() will assume a rs_tstamp overflow and give us a timestamp too far in the past which will cause mac80211 to merge IBSS on every beacon (which is not necessary since the BSSID already matches). but in this case we know that the HW must have synced to the beacons TSF and the rx timestamp must be later than that so we can adjust mactime accordingly. also rename the function to ath5k_check_ibss_tsf() and change comments, since "hw merge" is better described as a TSF update. drivers/net/wireless/ath5k/base.c: Changes-licensed-under: 3-Clause-BSD Signed-off-by: Bruno Randolf <bruno@thinktube.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
add comments about the fact that we don't know when exactly the atheros hardware takes the RX timestamp. drivers/net/wireless/ath5k/base.c: Changes-licensed-under: 3-Clause-BSD Signed-off-by: Bruno Randolf <bruno@thinktube.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
move ath5k_tx_status and ath5k_rx_status structures out of the hardware descriptor since they are not accessed by the hardware at all. they just contain converted information from the hardware descriptor. since they are only used in the rx and tx tasklets there is also no use to keep them for each descriptor. drivers/net/wireless/ath5k/ath5k.h: Changes-licensed-under: ISC drivers/net/wireless/ath5k/base.c: Changes-licensed-under: 3-Clause-BSD drivers/net/wireless/ath5k/debug.c: Changes-licensed-under: GPL drivers/net/wireless/ath5k/debug.h: Changes-licensed-under: GPL drivers/net/wireless/ath5k/hw.c: Changes-licensed-under: ISC Signed-off-by: Bruno Randolf <bruno@thinktube.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
* make struct ath5k_desc clearer by directly including unions of structures, which correspond to the hardware descriptors of different HW versions (5210 and 5212). before they were casted at onto ath5k_desc at different points (e.g. ds_hw[2]). * rename some structures and variable names to make their use clearer, e.g. struct ath5k_hw_4w_tx_desc to ath5k_hw_4w_tx_ctl. * substitute "old" with "5210" and "new" with "5212" (eg. rename ath5k_hw_proc_new_rx_status() to ath5k_hw_proc_5212_rx_status()) because old and new are relative and we might have a newer structure at some point. * unify structs ath5k_hw_old_rx_status and ath5k_hw_new_rx_status into one ath5k_hw_rx_status, because they only differ in the flags and masks. drivers/net/wireless/ath5k/ath5k.h: Changes-licensed-under: ISC drivers/net/wireless/ath5k/debug.c: Changes-licensed-under: GPL drivers/net/wireless/ath5k/hw.c: Changes-licensed-under: ISC drivers/net/wireless/ath5k/hw.h: Changes-licensed-under: ISC Signed-off-by: Bruno Randolf <bruno@thinktube.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ron Rindjunsky authored
This patch grabs NIC access inside iwl4965_tx_queue_agg_disable, instead of the caller doing it. The caller must still hold priv->lock when calling the function. Signed-off-by: Max Stepanov <max.stepanov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch 1. removes cmd completion from iwl3945_tx_queue_reclaim and creates iwl3945_cmd_queue_reclaim. 1. removes 11n relevant elements from this function 2. removes call to ieee80211_tx_status_irqsafe and uses ieee80211_tx_status only Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch fix 3945 rate scaling after cfg80211 rate/band changes Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-