- 18 Apr, 2011 1 commit
-
-
Daniel Halperin authored
For some reason, sending QoS configuration causes transmission to stop after a single frame on HT channels when not associated. Removing the extra QoS configuration has no effect on station mode, and fixes injection mode. Signed-off-by:
Daniel Halperin <dhalperi@cs.washington.edu> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 13 Apr, 2011 1 commit
-
-
Stanislaw Gruszka authored
priv->tx_power_next is not initialized to max supported power, but instead default value is used, what cause errors like [ 58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14. [ 58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22). if maximum tx power read from the eeprom is smaller than default. In consequence card is unable to initialize properly. Fix the problem and cleanup tx power initialization. Reported-and-tested-by:
Robin Dong <hao.bigrat@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 12 Apr, 2011 2 commits
-
-
Sujith Manoharan authored
Pass the correct module name and device interface so that ethtool can display the proper values. The firmware version will be fixed later on when the FW can actually report a version. :) Reported-by:
Richard Farina <sidhayn@gmail.com> Signed-off-by:
Sujith Manoharan <Sujith.Manoharan@atheros.com> Tested-by:
Richard Farina <sidhayn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
During PHY errors, the MAC can sometimes fail to enter an idle state on older hardware (before AR9380) after an rx stop has been requested. This typically shows up in the kernel log with messages like these: ath: Could not stop RX, we could be confusing the DMA engine when we start RX up ------------[ cut here ]------------ WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]() Call Trace: [<8023f0e8>] dump_stack+0x8/0x34 [<80075050>] warn_slowpath_common+0x78/0xa4 [<80075094>] warn_slowpath_null+0x18/0x24 [<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k] [<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k] [<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k] When this happens, the state that the MAC enters is easy to identify and does not result in bogus DMA traffic, however to ensure a working state after a channel change, the hardware should still be reset. This patch adds detection for this specific MAC state, after which the above warnings completely disappear in my tests. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 11 Apr, 2011 1 commit
-
-
John W. Linville authored
Otherwise, IWLWIFI_LEGACY has to be selected independently before the drivers are made available. Reported-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 08 Apr, 2011 2 commits
-
-
Jason Conti authored
This patch fixes a very serious off-by-one bug in the driver, which could leave the device in an unresponsive state. The problem was that the extra_len variable [used to reserve extra scratch buffer space for the firmware] was left uninitialized. Because p54_assign_address later needs the value to reserve additional space, the resulting frame could be to big for the small device's memory window and everything would immediately come to a grinding halt. Reference: https://bugs.launchpad.net/bugs/722185 Cc: <stable@kernel.org> Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
Jason Conti <jason.conti@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
These missing chip wakeups mainly cause crashes on AR5416 cards in MIPS boards, but have also been reported to cause radio stability issues on AR9285. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 07 Apr, 2011 3 commits
-
-
Christian Lamparter authored
Joe Culler reported a problem with his AR9170 device: > ath: EEPROM regdomain: 0x5c > ath: EEPROM indicates we should expect a direct regpair map > ath: invalid regulatory domain/country code 0x5c > ath: Invalid EEPROM contents It turned out that the regdomain 'APL7_FCCA' was not mapped yet. According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch should be correct. Cc: <stable@kernel.org> Reported-by:
Joe Culler <joe.culler@gmail.com> Acked-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Brian Cavagnolo authored
When the mwl8k driver attempts and fails to switch from sta to ap firmware (or vice-versa) in the mwl8k_add_interface routine, the mwl8k_stop routine will be called. This routine must not attempt to free the irq if it was not requested. Signed-off-by:
Brian Cavagnolo <brian@cozybit.com> Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
At least EEPROM version 0x11A has the wrong number of chains programmed into it for some reason, so we need to override in the driver. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 04 Apr, 2011 13 commits
-
-
John W. Linville authored
A number of these devices have appeared "in the wild", and apparently the Windows driver is perfectly happy to support this EEPROM version. Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: stable@kernel.org Acked-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Stanislaw Gruszka authored
{rx,tx}done_work's are only initialized for usb devices. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Cc: stable@kernel.org Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
Some compiler/architecture combinations generate some warnings that are not seen on my main system. Two of the "warnings" about unitialized variables are really bugs. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
Cc: <stable@kernel.org> Reported-by: Mark Davis [via p54/devices wiki] Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luciano Coelho authored
We were allocating the size of the NVS file struct and not checking whether the length of the buffer passed was correct before copying it into the allocated memory. This is a security hole because buffer overflows can occur if the userspace passes a bigger file than what is expected. With this patch, we check if the size of the data passed from userspace matches the size required. This bug was introduced in 2.6.36. Cc: stable@kernel.org Reported-by:
Ido Yariv <ido@wizery.com> Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
2.6.38 added WARN_ON(in_irq) in del_timer_sync that triggers on zd1211rw when reseting rx idle timer in urb completion handler. Move timer reseting to tasklet. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Jussi Kivilinna authored
Patch removes the bogus flag introduced by upstream commit eefdbec1. Old code had buffer length check that new code tried to handle with URB_SHORT_NOT_OK flag. With USB debugging enabled bogus flag caused usb_submit_urb fail. Remove URB_SHORT_NOT_OK flag and add buffer length check to urb completion handler. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32092Reported-by:
Jonathan Callen <abcd@gentoo.org> Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Cleaning the ieee80211_rx_data.flags field here is wrong, instead the flags should be valid accross processing the frame on different interfaces. Fix this by removing the incorrect flags=0 assignment. Introduced in commit 554891e6 (mac80211: move packet flags into packet). Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The description for buf_size was misleading and just said you couldn't TX larger aggregates, but of course you can't TX aggregates in a way that would exceed the window either, which is possible even if the aggregates are shorter than that. Expand the description, thanks to Emmanuel for explaining this to me. Cc: Emmanuel Grumbach <egrumbach@gmail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Senthil Balasubramanian authored
The phy information print during driver init time doesn't show the numeric part of the chip name properly for AR9485. This patch addresses this issue by adding the string to the respective array. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luciano Coelho authored
The MODULE_AUTHOR() macro in the main module (wl12xx) has been updated to reflect one of the author's new email address, but the wl12xx_spi and wl12xx_sdio modules haven't been updated. This patches updates them. Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Otherwise, skb_put inside of dma_rx can fail... https://bugzilla.kernel.org/show_bug.cgi?id=32042Signed-off-by:
John W. Linville <linville@tuxdriver.com> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: stable@kernel.org
-
Mariusz Kozlowski authored
On error path kfree() should get pointer to memory allocated by kmalloc() not the address of variable holding it (which is on stack). Signed-off-by:
Mariusz Kozlowski <mk@lab.zgora.pl> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 02 Apr, 2011 7 commits
-
-
Ilpo Järvinen authored
All callers are prepared for alloc failures anyway, so this error can safely be boomeranged to the callers domain without super bad consequences. ...At worst the connection might go into a state where each RTO tries to (unsuccessfully) re-fragment with such a mis-sized value and eventually dies. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wei Yongjun authored
Sometime the ASCONF_ACK parameters can equal to the fourfold of ASCONF parameters, this only happend in some special case: ASCONF parameter is : Unrecognized Parameter (4 bytes) ASCONF_ACK parameter should be: Error Cause Indication parameter (8 bytes header) + Error Cause (4 bytes header) + Unrecognized Parameter (4bytes) Four 4bytes Unrecognized Parameters in ASCONF chunk will cause panic. Pid: 0, comm: swapper Not tainted 2.6.38-next+ #22 Bochs Bochs EIP: 0060:[<c0717eae>] EFLAGS: 00010246 CPU: 0 EIP is at skb_put+0x60/0x70 EAX: 00000077 EBX: c09060e2 ECX: dec1dc30 EDX: c09469c0 ESI: 00000000 EDI: de3c8d40 EBP: dec1dc58 ESP: dec1dc2c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process swapper (pid: 0, ti=dec1c000 task=c09aef20 task.ti=c0980000) Stack: c09469c0 e1894fa4 00000044 00000004 de3c8d00 de3c8d00 de3c8d44 de3c8d40 c09060e2 de25dd80 de3c8d40 dec1dc7c e1894fa4 dec1dcb0 00000040 00000004 00000000 00000800 00000004 00000004 dec1dce0 e1895a2b dec1dcb4 de25d960 Call Trace: [<e1894fa4>] ? sctp_addto_chunk+0x4e/0x89 [sctp] [<e1894fa4>] sctp_addto_chunk+0x4e/0x89 [sctp] [<e1895a2b>] sctp_process_asconf+0x32f/0x3d1 [sctp] [<e188d554>] sctp_sf_do_asconf+0xf8/0x173 [sctp] [<e1890b02>] sctp_do_sm+0xb8/0x159 [sctp] [<e18a2248>] ? sctp_cname+0x0/0x52 [sctp] [<e189392d>] sctp_assoc_bh_rcv+0xac/0xe3 [sctp] [<e1897d76>] sctp_inq_push+0x2d/0x30 [sctp] [<e18a21b2>] sctp_rcv+0x7a7/0x83d [sctp] [<c077a95c>] ? ipv4_confirm+0x118/0x125 [<c073a970>] ? nf_iterate+0x34/0x62 [<c074789d>] ? ip_local_deliver_finish+0x0/0x194 [<c074789d>] ? ip_local_deliver_finish+0x0/0x194 [<c0747992>] ip_local_deliver_finish+0xf5/0x194 [<c074789d>] ? ip_local_deliver_finish+0x0/0x194 [<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44 [<c0747ab3>] ip_local_deliver+0x3e/0x44 [<c074789d>] ? ip_local_deliver_finish+0x0/0x194 [<c074775c>] ip_rcv_finish+0x29f/0x2c7 [<c07474bd>] ? ip_rcv_finish+0x0/0x2c7 [<c0747a6e>] NF_HOOK.clone.1+0x3d/0x44 [<c0747cae>] ip_rcv+0x1f5/0x233 [<c07474bd>] ? ip_rcv_finish+0x0/0x2c7 [<c071dce3>] __netif_receive_skb+0x310/0x336 [<c07221f3>] netif_receive_skb+0x4b/0x51 [<e0a4ed3d>] cp_rx_poll+0x1e7/0x29c [8139cp] [<c072275e>] net_rx_action+0x65/0x13a [<c0445a54>] __do_softirq+0xa1/0x149 [<c04459b3>] ? __do_softirq+0x0/0x149 <IRQ> [<c0445891>] ? irq_exit+0x37/0x72 [<c040a7e9>] ? do_IRQ+0x81/0x95 [<c07b3670>] ? common_interrupt+0x30/0x38 [<c0428058>] ? native_safe_halt+0xa/0xc [<c040f5d7>] ? default_idle+0x58/0x92 [<c0408fb0>] ? cpu_idle+0x96/0xb2 [<c0797989>] ? rest_init+0x5d/0x5f [<c09fd90c>] ? start_kernel+0x34b/0x350 [<c09fd0cb>] ? i386_start_kernel+0xba/0xc1 Signed-off-by:
Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wei Yongjun authored
auth_hmacs field of struct sctp_cookie is used for store Requested HMAC Algorithm Parameter, and each HMAC Identifier is 2 bytes, so the length should be: SCTP_AUTH_NUM_HMACS * sizeof(__u16) + 2 Signed-off-by:
Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michał Mirosław authored
dev_ethtool_get_rx_csum() won't report rx checksumming when it's not changeable and driver is converted to hw_features and friends. Fix this. (dev->hw_features & NETIF_F_RXCSUM) check is dropped - if the ethtool_ops->get_rx_csum is set, then driver is not coverted, yet. Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
The documentation for the USB ethernet devices suggests that only some devices are supposed to use usb0 as the network interface name instead of eth0. The logic used there, and documented in Kconfig for CDC is that eth0 will be used when the mac address is a globally assigned one, but usb0 is used for the locally managed range that is typically used on point-to-point links. Unfortunately, this has caused a lot of pain on the smsc95xx device that is used on the popular pandaboard without an EEPROM to store the MAC address, which causes the driver to call random_ether_address(). Obviously, there should be a proper MAC addressed assigned to the device, and discussions are ongoing about how to solve this, but this patch at least makes sure that the default interface naming gets a little saner and matches what the user can expect based on the documentation, including for new devices. The approach taken here is to flag whether a device might be a point-to-point link with the new FLAG_POINTTOPOINT setting in the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one of the two. The usbnet framework only looks at the MAC address for device naming if both flags are set, otherwise it trusts the flag. Signed-off-by:
Arnd Bergmann <arnd.bergmann@linaro.org> Tested-by:
Andy Green <andy.green@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
FUJITA Tomonori authored
Now we have CONFIG_ARCH_DMA_ADDR_T_64BIT. We can fix the hacky dma_addr_t size test cleanly. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 01 Apr, 2011 1 commit
-
-
David S. Miller authored
Commit 60d9f461 ("appletalk: remove the BKL") added a dereference of "sk" before checking for NULL in atalk_release(). Guard the code block completely, rather than partially, with the NULL check. Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 31 Mar, 2011 5 commits
-
-
Yevgeny Petrilin authored
We should reduce the number of reserved completion queues from the total number of entries. Since the queue size is power of two, not reducing the reserved entries, caused a double queue size, which may lead to allocation failures in some cases. Signed-off-by:
Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yevgeny Petrilin authored
In case of allocation failure, tried to use the promiscuous QP entry that was previously freed. Now freeing this entry only in case we will not put it back to the list of promiscuous entries. Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Peter Pan(潘卫平) authored
use accumulates instead of acumulates. Signed-off-by:
Pan Weiping <panweiping3@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Like DCCP and other similar pieces of code, there are mechanisms here to try allocating smaller hash tables if the allocation fails. So pass in __GFP_NOWARN like the others do instead of emitting a scary message. Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Commits 01a16b21 (netlink: kill eff_cap from struct netlink_skb_parms) and c53fa1ed (netlink: kill loginuid/sessionid/sid members from struct netlink_skb_parms) removed some members from struct netlink_skb_parms that depend on the current context, all netlink users are now required to do synchronous message processing. connector however queues received messages and processes them in a work queue, which is not valid anymore. This patch converts connector to do synchronous message processing by invoking the registered callback handler directly from the netlink receive function. In order to avoid invoking the callback with connector locks held, a reference count is added to struct cn_callback_entry, the reference is taken when finding a matching callback entry on the device's queue_list and released after the callback handler has been invoked. Signed-off-by:
Patrick McHardy <kaber@trash.net> Acked-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 30 Mar, 2011 4 commits
-
-
Eric Dumazet authored
Daniel J Blueman reported a lockdep splat in trie_firstleaf(), caused by RTNL being not locked before a call to fib_table_flush() Reported-by:
Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Philip A. Prindeville authored
Don't flap VCs when carrier state changes; higher-level protocols can detect loss of connectivity and act accordingly. This is more consistent with how other network interfaces work. We no longer use release_vccs() so we can delete it. release_vccs() was duplicated from net/atm/common.c; make the corresponding function exported, since other code duplicates it and could leverage it if it were public. Signed-off-by:
Philip A. Prindeville <philipp@redfish-solutions.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Philip A. Prindeville authored
Omit pkt_hdr preamble when dumping transmitted packet as hex-dump; we can pull this up because the frame has already been sent, and dumping it is the last thing we do with it before freeing it. Also include the size, vpi, and vci in the debug as is done on receive. Use "port" consistently instead of "device" intermittently. Signed-off-by:
Philip Prindeville <philipp@redfish-solutions.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Philip A. Prindeville authored
Use VPI.VCI notation consistently throughout the module. This is the one remaining place where the VCI is used before the VPI in any output. Signed-off-by:
Philip Prindeville <philipp@redfish-solutions.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-