- 13 1月, 2009 33 次提交
-
-
由 John W. Linville 提交于
drivers/net/wireless/p54/p54common.c: In function ‘p54_config’: drivers/net/wireless/p54/p54common.c:1853: warning: ‘ret’ may be used uninitialized in this function Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
drivers/net/wireless/iwlwifi/iwl-3945.c: In function ‘iwl3945_txpower_set_from_eeprom’: drivers/net/wireless/iwlwifi/iwl-3945.c:2222: warning: ‘power_idx’ may be used uninitialized in this function Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
drivers/net/wireless/b43legacy/main.c: In function ‘b43legacy_op_dev_config’: drivers/net/wireless/b43legacy/main.c:2468: warning: ‘up_dev’ may be used uninitialized in this function Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
drivers/net/wireless/b43/main.c: In function ‘b43_op_config’: drivers/net/wireless/b43/main.c:3264: warning: ‘gmode’ may be used uninitialized Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
net/mac80211/ht.c: In function ‘ieee80211_start_tx_ba_session’: net/mac80211/ht.c:472: warning: ‘ret’ may be used uninitialized in this function Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Andrey Yurovsky 提交于
The TX op should return NETDEV_TX_OK or NETDEV_TX_BUSY. Signed-off-by: NAndrey Yurovsky <andrey@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
The TXD_W0_CIPHER field is a 1-bit field. It only acts as boolean value to indicate if the frame must be encrypted or not. The way rt2x00_set_field32() worked it would grab the least signifcant bit from txdesc->cipher and use that as value. Because of that WEP 64 and TKIP worked since they had odd-numbered values, while WEP 128 and AES were even numbers and didn't work. Correctly booleanize the txdecs->cipher value to allow the hardware to encrypt the outgoing data. After this we can enable HW crypto by default again. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Lamparter 提交于
This patch fixes a panic that might occur, if the device is part of a mesh and tries to send with a higher rate index than "0". kernel BUG at net/mac80211/rate.c:239! invalid opcode: 0000 [#1] SMP [...] Call Trace: <IRQ> <0> ? invoke_tx_handlers+0x474/0xb57 [mac80211] ? __ieee80211_tx_prepare+0x260/0x2a8 [mac80211] ? ieee80211_master_start_xmit+0x300/0x43a [mac80211] ? __qdisc_run+0xde/0x1da ? net_tx_action+0xb4/0x102 Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: NChristian Lamparter <chunkeey@web.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
Should return NETDEV_TX_{OK,BUSY} instead of 0,-1 (this doesn't change any current functionality). Changes-licensed-under: 3-Clause-BSD Reported-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NBob Copeland <me@bobcopeland.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Due to misunderstanding of the returned values allowed for the tx callback of mac80211, rtl8187 was using skb's that had been freed. This problem was triggered when the module was sujected to a rmmod/insmod cycle. After that was fixed, the modules would not work after the rmmod/insmod cycle until the USB device was reset. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Lamparter 提交于
This patch hopefully fixes a mac80211<->p54 interaction problem, which was described by Larry Finger (ref: http://marc.info/?l=linux-wireless&m=123009889327707 ) I guess the warning was triggered by pending frames in the receive queue, while we're doing a band change 5GHz. Signed-off-by: NChristian Lamparter <chunkeey@web.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pavel Roskin 提交于
Changing mode on an interface is not allowed if IBSS is disabled for the current channel. That restriction should only apply when switching to the ad-hoc mode, as it was prior to "cfg80211: handle SIOCGIWMODE/SIOCSIWMODE". Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Steve Brown 提交于
This corrects usage of AR5K_CFG_ADHOC introduced in "ath5k: Update PCU code". Also, the name of the indicator is changed to AR5K_CFG_IBSS to more accurately reflect its function. This change restores beaconing in AP and mesh modes. Signed-off-by: NSteve Brown <sbrown@cortland.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
This patch reverts "ath9k: Fix TX status reporting for retries and MCS index" because that change ended up breaking ath9k rate control. While the MCS index reporting to mac80211 was indeed fixed by the patch, it did not take into account that the ath9k rate control algorithm was updating private tables based on this index and the index comes through the rate control API call, i.e., based on mac80211 TX status call. In addition, it looks like the "fix" to remove +1 from TX status 'count' field was not correct based on ieee80211_tx_status() implementation that counts the total of count values, but starting from -1, not 0. The TX status reporting for frames using MCS needs to be fixed somehow, but it does not look like there is any easy fix for the ath9k rate control algorithm, so the best option now seems to be to revert the change and bring it back once the rate control code is cleaned up to handle this better. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Lamparter 提交于
This patch fixes the following WARNING (caused by rix_to_ndx): " >WARNING: at net/mac80211/rc80211_minstrel.c:69 minstrel_rate_init+0xd2/0x33a [mac80211]() >[...] >Call Trace: > warn_on_slowpath+0x51/0x75 > _format_mac_addr+0x4c/0x88 > minstrel_rate_init+0xd2/0x33a [mac80211] > print_mac+0x16/0x1b > schedule_hrtimeout_range+0xdc/0x107 > ieee80211_add_station+0x158/0x1bd [mac80211] > nl80211_new_station+0x1b3/0x20b [cfg80211] The reason is that I'm experimenting with "g" only mode on a 802.11 b/g card. Therefore rate_lowest_index returns 4 (= 6Mbit, instead of usual 0 = 1Mbit). Since mi->r array is initialized with zeros in minstrel_alloc_sta, rix_to_ndx has a hard time to find the 6Mbit entry and will trigged the WARNING. Signed-off-by: NChristian Lamparter <chunkeey@web.de> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
This patch fixes an issue with the sequence numbers of unaggregated QoS frames, because of which the frames are handled in a different order at the AP and resulted in MLME REPLAYFAILURE. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
rt2500usb doesn't strip the IV/ICV data from received frames, so we don't need to set the RX_FLAG_IV_STRIPPED flag. We do need to set the RX_FLAG_MMIC_STRIPPED flag for all encryption types since the MMIC has been removed from the frame. After this patch TKIP Hardware crypto works for rt2500usb. WEP and AES are still failing. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
To be compatible with mac80211 following "mac80211: only create default STA interface if supported", rtl8180 needs to set NL80211_IFTYPE_STATION in interface_modes. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Reported-by: NFabio Rossi <rossi.f@inwind.it> Tested-by: NPiter PUNK <piterpunk@unitednerds.org> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Wu 提交于
My first (minor) patch, hopefully this is correct. Fix a typo in iwl-commands.h for CCK rates which needs 7 bits and not 4. Signed-off-by: NDaniel Wu <dyqith@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
The queue_end() macro points to 1 position after the queue, which means that if we want to know if queue is at the end of the queue we should first increment the position and then check if it is a valid entry. This fixes a segmentation fault which only occurs when the device has enough endpoints to provide a dedicated endpoint for all TX queues (which likely won't happen for rt2500usb and rt73usb, but will happen for rt2800usb). Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Lamparter 提交于
All LM87 firmwares need a explicit termination "packet", in oder to finish the pending transfer properly. Signed-off-by: NChristian Lamparter <chunkeey@web.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Lamparter 提交于
This patch fixes two small flaws: - restore the original TKIP IV if we altered it. - reserve & initialize ICV with zeros. This is actually only necessary for some obsolete p54usb firmwares. But we don't know yet, if all devices are compatible with the new revisions. Signed-off-by: NChristian Lamparter <chunkeey@web.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pavel Roskin 提交于
Reported by Michael Jarosch <mitsch@riotmusic.de> Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Samuel Ortiz 提交于
0x1b is a 3945 specific command, we should print it too when debugging. Signed-off-by: NSamuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
The chainmasks have to be updated before setting the channel, since the HW reset routine uses them to set the appropriate registers. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 David Kilroy 提交于
Fix the warning reproduced below. We add to rx_list in interrupt context and remove elements in tasklet context. While removing elements we need to prevent the interrupt modifying the list. Note that "orinoco: Process bulk of receive interrupt in a tasklet" did not preserve locking semantics on what is now orinoco_rx. This patch reinstates the locking semantics and ensures it covers rx_list as well. This leads to additional cleanup required in free_orinocodev. [89479.105038] WARNING: at lib/list_debug.c:30 __list_add+0x8f/0xa0() [89479.105058] list_add corruption. prev->next should be next (dddb3568), but was cbc28978. (prev=dddb3568). [89479.106002] Pid: 15746, comm: X Not tainted 2.6.28-1avb #26 [89479.106020] Call Trace: [89479.106062] [<c011d3b0>] warn_slowpath+0x60/0x80 [89479.106104] [<c01073d0>] ? native_sched_clock+0x20/0x70 [89479.106194] [<c013d825>] ? lock_release_holdtime+0x35/0x200 [89479.106218] [<c018d9f0>] ? __slab_alloc+0x550/0x560 [89479.106254] [<c02f9c9d>] ? _spin_unlock+0x1d/0x20 [89479.106270] [<c018d9f0>] ? __slab_alloc+0x550/0x560 [89479.106302] [<c01ff2a7>] ? delay_tsc+0x17/0x24 [89479.106319] [<c01ff221>] ? __const_udelay+0x21/0x30 [89479.106376] [<dfa8b1e2>] ? hermes_bap_seek+0x112/0x1e0 [hermes] [89479.106396] [<c013d7eb>] ? trace_hardirqs_off+0xb/0x10 [89479.106418] [<c018e307>] ? __kmalloc_track_caller+0xb7/0x110 [89479.106448] [<c028eefc>] ? dev_alloc_skb+0x1c/0x30 [89479.106465] [<c028eefc>] ? dev_alloc_skb+0x1c/0x30 [89479.106482] [<c020e13f>] __list_add+0x8f/0xa0 [89479.106551] [<dfd0fcae>] orinoco_interrupt+0xcae/0x16c0 [orinoco] [89479.106574] [<c013b0e3>] ? tick_dev_program_event+0x33/0xb0 [89479.106594] [<c01073d0>] ? native_sched_clock+0x20/0x70 [89479.106613] [<c013d825>] ? lock_release_holdtime+0x35/0x200 [89479.106662] [<c013d7eb>] ? trace_hardirqs_off+0xb/0x10 [89479.106892] [<dfe7faa7>] ? usb_hcd_irq+0x97/0xa0 [usbcore] [89479.106926] [<c015ba79>] handle_IRQ_event+0x29/0x60 [89479.106947] [<c015cf89>] handle_level_irq+0x69/0xe0 [89479.106963] [<c015cf20>] ? handle_level_irq+0x0/0xe0 [89479.106977] <IRQ> [<c02ca933>] ? tcp_v4_rcv+0x633/0x6e0 [89479.107025] [<c0103f0c>] ? common_interrupt+0x28/0x30 [89479.107057] [<c02a0000>] ? sk_run_filter+0x320/0x7a0 [89479.107078] [<c020e041>] ? list_del+0x21/0x90 [89479.107106] [<dfd0d24e>] ? orinoco_rx_isr_tasklet+0x2ce/0x480 [orinoco] [89479.107131] [<c01402e0>] ? __lock_acquire+0x160/0x1650 [89479.107151] [<c01073d0>] ? native_sched_clock+0x20/0x70 [89479.107169] [<c013d825>] ? lock_release_holdtime+0x35/0x200 [89479.107200] [<c012249a>] ? irq_enter+0xa/0x60 [89479.107217] [<c0104e52>] ? do_IRQ+0xd2/0x130 [89479.107518] [<c010342c>] ? restore_nocheck_notrace+0x0/0xe [89479.107542] [<c0122830>] ? __do_softirq+0x0/0x110 [89479.107561] [<c013f7b4>] ? trace_hardirqs_on_caller+0x74/0x140 [89479.107583] [<c01ff678>] ? trace_hardirqs_on_thunk+0xc/0x10 [89479.107602] [<c0122087>] ? tasklet_action+0x27/0x90 [89479.107620] [<c013f7b4>] ? trace_hardirqs_on_caller+0x74/0x140 [89479.107638] [<c01220a3>] ? tasklet_action+0x43/0x90 [89479.107655] [<c012289f>] ? __do_softirq+0x6f/0x110 [89479.107674] [<c0122830>] ? __do_softirq+0x0/0x110 [89479.107685] <IRQ> [<c015cf20>] ? handle_level_irq+0x0/0xe0 [89479.107715] [<c012246d>] ? irq_exit+0x5d/0x80 [89479.107732] [<c0104e52>] ? do_IRQ+0xd2/0x130 [89479.107747] [<c0103337>] ? sysenter_exit+0xf/0x16 [89479.107765] [<c013f83d>] ? trace_hardirqs_on_caller+0xfd/0x140 [89479.107782] [<c0103f0c>] ? common_interrupt+0x28/0x30 [89479.107797] ---[ end trace a1fc0a52df4a729d ]--- Reported-by: NAndrey Borzenkov <arvidjaar@mail.ru> Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
CONFIG_ATH9K=y results in build issues if CONFIG_RFKILL=m since ath9k does not depend on rfkill in kconfig (i.e., CONFIG_RFKILL is used to select whether to enable rfkill in ath9k), but uses its functions if rfkill is enabled. Enforce ath9k to be build as a module if CONFIG_RFKILL=m to avoid this invalid configuration. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Michiel 提交于
Add the USB ID for Thomson Speedtouch 121g to p54usb. Signed-off-by: NMichiel <michiel@ettema.net> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
The short preamble mode was not correctly detected during TX, rt2x00 used the rate->hw_value_short field but mac80211 is not using this field that way. Instead the flag IEEE80211_TX_RC_USE_SHORT_PREAMBLE should be used to determine if the frame should be send out using short preamble or not. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stefan Lippers-Hollmann 提交于
add USB ID for the Linksys WUSB200 Wireless-G Business USB Adapter to rt73usb. Signed-off-by: NStefan Lippers-Hollmann <s.l-h@gmx.de> Cc: stable <stable@kernel.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
On x86_64 architecture with 4K page size and SLUB debugging enabled, stress testing on p54usb has resulted in skb allocation failures of O(1) and extreme page fragmentation. Reducing rx_mtu fixes this problem by reducing the size of all receive skb allocations to be of O(0). This change does not impact performance in any way. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Andrew Price 提交于
Since "rt2x00: Fix LED state handling", rt2x00leds_led_radio wrongly checks that the LED type is LED_TYPE_ASSOC. This patch makes it check for LED_TYPE_RADIO once again. Signed-off-by: NAndrew Price <andy@andrewprice.me.uk> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Erik Ekman 提交于
Raytheon cards use 2.4 GHz, not 2.4 MHz. See http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.html#RaylinkSigned-off-by: NErik Ekman <erik@kryo.se> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 11 1月, 2009 7 次提交
-
-
由 Timur Tabi 提交于
The UCC Event Register (UCCE) already has unambigous macro definitions in qe.h, so we should not be defining our own in the UCC Ethernet driver. Removed unused local variable 'dev' from ucc_geth_poll(), which fixes a warning caused by commit 908a7a16 ("net: Remove unused netdev arg from some NAPI interfaces."). Replaced in_be/out_be pairs with setbits32 or clrbits32, where applicable. Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Williams 提交于
The recent dmaengine rework removed the capability to remove dma device driver modules while net_dma is active. Rather than notify dmaengine-clients that channels are trying to be removed, we now rely on clients to notify dmaengine when they no longer have a need for channels. Teach net_dma to release channels by taking dmaengine references at netdevice open and dropping references at netdevice close. Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Roland Dreier 提交于
I have a system with a Chelsio adapter (driven by cxgb3) whose ports are part of a Linux bridge. Recently I updated the kernel and discovered that things stopped working because cxgb3 was doing LRO on packets that were passed into the bridge code for forwarding. (Incidentally, this problem manifested itself in a strange way that made debugging a bit interesting -- for some reason, the skb_warn_if_lro() check in bridge didn't trigger and these LROed packets were forwarded out a forcedeth interface, and caused the forcedeth transmit path to get stuck) This is because cxgb3 has no way of keeping state for the LRO flag until the interface is brought up, so if the bridging code disables LRO while the interface is down, then cxgb3_up() will just reenable LRO, and on my Debian system at least, the init scripts add interfaces to a bridge before bringing the interfaces up. Fix this by keeping track of each interface's LRO state in cxgb3 so that when bridge disables LRO, it stays disabled in cxgb3_up() when the interface is brought up. I did this by changing the rx_csum_offload flag into a pair of bit flags; the effect of this on the rx_eth() fast path is miniscule enough that it should be fine (eg on x86, a cmpb instruction becomes a testb instruction). Signed-off-by: NRoland Dreier <rolandd@cisco.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
Only the SFX7101 requires software power control. This was incorrectly being applied to the SFT9001 rev A as well. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Gerrit Renker 提交于
Thanks to Wei and Arnaldo for pointing out the correct new reference for CCID-3. Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Steve Glendinning 提交于
This change lets "cat /proc/interrupts" show the name of the ethernet device (e.g. eth0) rather than the driver name (smsc911x). Signed-off-by: NSteve Glendinning <steve.glendinning@smsc.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Steve Glendinning 提交于
if this code path is ever hit, the platform_data struct isn't properly configured with a bus width flag so the device won't work (hence the BUG()). This patch adds a dummy return statement to eliminate this compiler warning: drivers/net/smsc911x.c: In function 'smsc911x_reg_read': drivers/net/smsc911x.c:148: warning: control reaches end of non-void function Signed-off-by: NSteve Glendinning <steve.glendinning@smsc.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-