- 27 Jul, 2010 6 commits
-
-
Gustavo F. Padovan authored
Those marks are useful to save space in the binary and in the memory. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Gustavo F. Padovan authored
Use the new hci_recv_stream_fragment() to reassembly incoming UART streams. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Tested-by: Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Gustavo F. Padovan authored
Testing first we avoid enter the loop when count = 0. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Gustavo F. Padovan authored
.c file shall not have the 'x' permission. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
Certain headsets such as the Motorola H350 will reject SCO and eSCO connection requests while the ACL is transitioning from sniff mode to active mode. Add synchronization so that SCO and eSCO connection requests will wait until the ACL has fully transitioned to active mode. < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2 handle 12 > HCI Event: Command Status (0x0f) plen 4 Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 12 voice setting 0x0040 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 12 packets 1 > HCI Event: Mode Change (0x14) plen 6 status 0x00 handle 12 mode 0x00 interval 0 Mode: Active > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO Error: Connection Accept Timeout Exceeded Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-next-2.6John W. Linville authored
Conflicts: drivers/net/wireless/iwlwifi/iwl-commands.h
-
- 26 Jul, 2010 28 commits
-
-
Ivo van Doorn authored
Since commit: commit f1aa4c54 Author: Ivo van Doorn <ivdoorn@gmail.com> Date: Tue Jun 29 21:38:55 2010 +0200 rt2x00: Write the BSSID to register when interface is added mananged mode in rt2500pci was broken, due to intf->bssid containing random data rather then the expected 00:00:00:00:00:00 This is corrected by sending the BSSID to rt2x00lib_config_intf only in AP mode where the bssid is set to a valid value. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith authored
In AP mode, there is no need to notify the driver about QoS changes for the monitor interface that is created. The warning in ieee80211_bss_info_change_notify() would be hit otherwise. Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
The noisefloor array index always corresponds to the rx chain number it belongs to (with an offset of 3 for the extension chain). It's much simpler (and actually more correct) to directly use the chainmask to calculate the bitmask for the noisefloor array, instead of using these weird chip revision checks and hardcoded mask values. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
In the noisefloor array, the extension channel values start at index 3 Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When the hardware is configured in HT20 mode, noise floor readings for the extension channel often return invalid values, which keep the values in the NF history buffer at the hardware-specific maximum limit. Fix this by discarding the extension channel values when in HT20 mode. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When an aggregation session is being cleaned up, while the tx status for some frames is being processed, the TID is flushed and its buffers are sent out. Unfortunately that left the pending un-acked frames unprocessed, thus leaking buffers. Fix this by reordering the code so that those frames are processed first, before the TID is flushed. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
I just had the following: WARNING: at drivers/net/wireless/iwlwifi/iwl-agn-tx.c:574 iwlagn_tx_skb+0x1576/0x15f0 [iwlagn]() Call Trace: <IRQ> [<ffffffff8105c5df>] warn_slowpath_common+0x7f/0xc0 [<ffffffff8105c63a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa0290b46>] iwlagn_tx_skb+0x1576/0x15f0 [iwlagn] [<ffffffffa027076c>] iwl_mac_tx+0x5c/0x260 [iwlagn] [<ffffffffa01bdf5b>] __ieee80211_tx+0x10b/0x1a0 [mac80211] [<ffffffffa01bfb86>] ieee80211_tx_pending+0x186/0x2d0 [mac80211] [<ffffffff81062ea5>] tasklet_action+0x125/0x130 [<ffffffff810634a6>] __do_softirq+0x106/0x270 [<ffffffff8100c09c>] call_softirq+0x1c/0x30 iwlagn 0000:02:00.0: Attempting to modify non-existing station 107 Note that 107 == 0x6b which is slab poison. The reason is that mac80211 passed a freed station pointer to mac80211, because as it happened iwlwifi reset itself while mac80211 was disconnecting from the network. It turns out that we do take care to look up the station pointer in ieee80211_tx_pending_skb, but then don't use it, which obviously is a bug. Fix this by removing the ieee80211_tx_h_sta handler and assigning the station pointer directly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
Negate has precedence over comparison so the original test was always false. (Neither 0 nor 1 are equal to NL80211_IFTYPE_MONITOR). Signed-off-by: Dan Carpenter <error27@gmail.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When wireless extensions are used to control an encrypted IBSS, we erroneously can try to set the default management key. Fix this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Another remnant of the previous key locking scheme needs to be removed -- this causes a warning otherwise as ieee80211_set_default_mgmt_key will acquire a mutex. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
The "rd" variable isn't needed any more since 4f366c5d "wireless: only use alpha2 regulatory information from country IE" Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
The intent was to free "msp->ratelist" here. "msp->sample_table" is always NULL at this point. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Sometimes txq state(txq->stopped) can be marked as started but the actual queue may not be started (in ATH_WIPHY_SCAN state, for example). Fix this. Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
snprintf() returns the number of characters that would have been written (not counting the NUL character). So we can't use it as the limiter to simple_read_from_buffer() without capping it first at sizeof(buf). Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
The snprintf() function returns the number of characters that would have been written (not counting the NUL character on the end). It could potentially be larger than the size of the buffer. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Julia Lawall authored
Use kmemdup when some other buffer is immediately copied into the allocated region. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S - memcpy(to, from, size); // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
"It's not problematic if minstrel gets feedback for rates that it doesn't have in its list, it should just ignore it. - Felix" Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Felix Fietkau <nbd@openwrt.org>
-
John W. Linville authored
If sta is NULL, we will have problems long before we get here... Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Felix Fietkau <nbd@openwrt.org>
-
John W. Linville authored
The current practice of checking vif for NULL in one place but not another seems to confuse some static checkers, smatch in particular. Since vif will only be NULL in the case of internal scans, adjust the checks accordingly. Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
The driver is already removed from drivers/staging. The wireless extensions part is not really valid anymore either, since wext got moved and refactored, etc. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
The prism54 driver had an entry in feature-removal-schedule.txt and it sees very little activity other than API-change "bombing runs". The mac80211-based p54 driver should be used instead. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
CHECK drivers/net/wireless/rtl818x/rtl8180_rtl8225.c drivers/net/wireless/rtl818x/rtl8180_rtl8225.c:53:33: warning: dubious: x | !y The existing code is clever and works fine, but it's not worth even a single line of Sparse warning SPAM... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Adapted from Realtek-provided driver... Signed-off-by: John W. Linville <linville@tuxdriver.com> Tested-by: Pauli Nieminen <suokkos@gmail.com>
-
John W. Linville authored
CHECK drivers/net/wireless/wl12xx/wl1251_tx.c drivers/net/wireless/wl12xx/wl1251_tx.c:118:32: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_tx.c:118:32: expected unsigned short [unsigned] [usertype] frag_threshold drivers/net/wireless/wl12xx/wl1251_tx.c:118:32: got restricted __le16 [usertype] <noident> drivers/net/wireless/wl12xx/wl1251_tx.c:164:24: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_tx.c:164:24: expected unsigned short [unsigned] [usertype] length drivers/net/wireless/wl12xx/wl1251_tx.c:164:24: got restricted __le16 [usertype] <noident> drivers/net/wireless/wl12xx/wl1251_tx.c:166:22: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_tx.c:166:22: expected unsigned short [unsigned] [usertype] rate drivers/net/wireless/wl12xx/wl1251_tx.c:166:22: got restricted __le16 [usertype] <noident> drivers/net/wireless/wl12xx/wl1251_tx.c:167:29: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_tx.c:167:29: expected unsigned int [unsigned] [usertype] expiry_time drivers/net/wireless/wl12xx/wl1251_tx.c:167:29: got restricted __le32 [usertype] <noident> drivers/net/wireless/wl12xx/wl1251_tx.c:200:43: warning: incorrect type in argument 1 (different base types) drivers/net/wireless/wl12xx/wl1251_tx.c:200:43: expected restricted __le16 [usertype] fc drivers/net/wireless/wl12xx/wl1251_tx.c:200:43: got unsigned short [unsigned] [assigned] [usertype] fc CHECK drivers/net/wireless/wl12xx/wl1251_cmd.c drivers/net/wireless/wl12xx/wl1251_cmd.c:428:39: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_cmd.c:428:39: expected unsigned int [unsigned] [usertype] rx_config_options drivers/net/wireless/wl12xx/wl1251_cmd.c:428:39: got restricted __le32 [usertype] <noident> drivers/net/wireless/wl12xx/wl1251_cmd.c:429:39: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_cmd.c:429:39: expected unsigned int [unsigned] [usertype] rx_filter_options drivers/net/wireless/wl12xx/wl1251_cmd.c:429:39: got restricted __le32 [usertype] <noident> drivers/net/wireless/wl12xx/wl1251_cmd.c:435:29: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_cmd.c:435:29: expected unsigned short [unsigned] [usertype] tx_rate drivers/net/wireless/wl12xx/wl1251_cmd.c:435:29: got restricted __le16 [usertype] <noident> drivers/net/wireless/wl12xx/wl1251_cmd.c:439:47: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_cmd.c:439:47: expected unsigned int [unsigned] [usertype] min_duration drivers/net/wireless/wl12xx/wl1251_cmd.c:439:47: got restricted __le32 [usertype] <noident> drivers/net/wireless/wl12xx/wl1251_cmd.c:441:47: warning: incorrect type in assignment (different base types) drivers/net/wireless/wl12xx/wl1251_cmd.c:441:47: expected unsigned int [unsigned] [usertype] max_duration drivers/net/wireless/wl12xx/wl1251_cmd.c:441:47: got restricted __le32 [usertype] <noident> CHECK drivers/net/wireless/wl12xx/wl1251_boot.c drivers/net/wireless/wl12xx/wl1251_boot.c:228:22: warning: symbol 'interrupt' shadows an earlier one /home/linville/git/wireless-next-2.6/arch/x86/include/asm/hw_irq.h:132:13: originally declared here Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
"iwlagn: add statistic notification structure for WiFi/BT devices" added several new '__attribute__ ((packed))' lines. Change them to the generic __packed. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 23 Jul, 2010 6 commits
-
-
Johannes Berg authored
defines shouldn't be terminated with a semicolon, the code using them should supply it. Luckily these are not used in a context where it matters. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
Since the ibss_beacon variable will only be filled in the appropriate modes, there's no reason to be checking the mode again. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Some devices may have multiple MAC addresses in their EEPROM, read them and advertise them to cfg80211. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This function is only needed in the same file it is defined in, i.e. iwl-core.c Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
gcc complains about the firmware loading: iwl-agn.c: In function ‘iwlagn_load_firmware’: iwl-agn.c:1860: warning: ‘tlv_len’ may be used uninitialized in this function iwl-agn.c:1861: warning: ‘tlv_type’ may be used uninitialized in this function iwl-agn.c:1862: warning: ‘tlv_data’ may be used uninitialized in this function This is almost correct but we do do break out of the TLV parsing loop when setting ret. However, the code is hard to follow, and clearly even the compiler is having issues with it too. Additionally, however, the current code is wrong. If there is a TLV length check error, the code will report invalid TLV after parsing: ... because "len" will still be non-zero as we broke out of the loop. So to remove the warning and fix that issue, make the code easier to read by doing length checking with an error label. As a result, we can completely remove the "ret" variable. Also, while at it, remove the "fixed_tlv_size" variable since each TLV type has its own specified length, it just happens that we have only variable length, flags (0 length) and u32 TLVs right now. It should still be checked with more explicit length checks to make it easier to understand. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Different devices have different size of phy calibration table; add new TLV to specify the size. If the TLV is not part of uCode header, the default table size will be used to make sure the backward compatibilities. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-