- 26 Jun, 2012 2 commits
-
-
Alexander Duyck authored
FCoE target mode was experiencing issues due to the fact that we were sending up data frames that were padded to 60 bytes after the DDP logic had already stripped the frame down to 52 or 56 depending on the use of VLANs. This was resulting in the FCoE DDP logic having issues since it thought the frame still had data in it due to the padding. To resolve this, adding code so that we do not pad FCoE frames prior to handling them to the stack. CC: <stable@vger.kernel.org> Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Tested-by:
Ross Brattain <ross.b.brattain@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Denys Fedoryshchenko reported a LOCKDEP issue with l2tp code. [ 8683.927442] ====================================================== [ 8683.927555] [ INFO: possible circular locking dependency detected ] [ 8683.927672] 3.4.1-build-0061 #14 Not tainted [ 8683.927782] ------------------------------------------------------- [ 8683.927895] swapper/0/0 is trying to acquire lock: [ 8683.928007] (slock-AF_INET){+.-...}, at: [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e [l2tp_core] [ 8683.928121] [ 8683.928121] but task is already holding lock: [ 8683.928121] (_xmit_ETHER#2){+.-...}, at: [<c02f062d>] sch_direct_xmit+0x36/0x119 [ 8683.928121] [ 8683.928121] which lock already depends on the new lock. [ 8683.928121] [ 8683.928121] [ 8683.928121] the existing dependency chain (in reverse order) is: [ 8683.928121] [ 8683.928121] -> #1 (_xmit_ETHER#2){+.-...}: [ 8683.928121] [<c015a561>] lock_acquire+0x71/0x85 [ 8683.928121] [<c034da2d>] _raw_spin_lock+0x33/0x40 [ 8683.928121] [<c0304e0c>] ip_send_reply+0xf2/0x1ce [ 8683.928121] [<c0317dbc>] tcp_v4_send_reset+0x153/0x16f [ 8683.928121] [<c0317f4a>] tcp_v4_do_rcv+0x172/0x194 [ 8683.928121] [<c031929b>] tcp_v4_rcv+0x387/0x5a0 [ 8683.928121] [<c03001d0>] ip_local_deliver_finish+0x13a/0x1e9 [ 8683.928121] [<c0300645>] NF_HOOK.clone.11+0x46/0x4d [ 8683.928121] [<c030075b>] ip_local_deliver+0x41/0x45 [ 8683.928121] [<c03005dd>] ip_rcv_finish+0x31a/0x33c [ 8683.928121] [<c0300645>] NF_HOOK.clone.11+0x46/0x4d [ 8683.928121] [<c0300960>] ip_rcv+0x201/0x23d [ 8683.928121] [<c02de91b>] __netif_receive_skb+0x329/0x378 [ 8683.928121] [<c02deae8>] netif_receive_skb+0x4e/0x7d [ 8683.928121] [<e08d5ef3>] rtl8139_poll+0x243/0x33d [8139too] [ 8683.928121] [<c02df103>] net_rx_action+0x90/0x15d [ 8683.928121] [<c012b2b5>] __do_softirq+0x7b/0x118 [ 8683.928121] [ 8683.928121] -> #0 (slock-AF_INET){+.-...}: [ 8683.928121] [<c0159f1b>] __lock_acquire+0x9a3/0xc27 [ 8683.928121] [<c015a561>] lock_acquire+0x71/0x85 [ 8683.928121] [<c034da2d>] _raw_spin_lock+0x33/0x40 [ 8683.928121] [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e [l2tp_core] [ 8683.928121] [<e0fe31fb>] l2tp_eth_dev_xmit+0x1a/0x2f [l2tp_eth] [ 8683.928121] [<c02e01e7>] dev_hard_start_xmit+0x333/0x3f2 [ 8683.928121] [<c02f064c>] sch_direct_xmit+0x55/0x119 [ 8683.928121] [<c02e0528>] dev_queue_xmit+0x282/0x418 [ 8683.928121] [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c [ 8683.928121] [<c031f524>] arp_xmit+0x22/0x24 [ 8683.928121] [<c031f567>] arp_send+0x41/0x48 [ 8683.928121] [<c031fa7d>] arp_process+0x289/0x491 [ 8683.928121] [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c [ 8683.928121] [<c031f7a0>] arp_rcv+0xb1/0xc3 [ 8683.928121] [<c02de91b>] __netif_receive_skb+0x329/0x378 [ 8683.928121] [<c02de9d3>] process_backlog+0x69/0x130 [ 8683.928121] [<c02df103>] net_rx_action+0x90/0x15d [ 8683.928121] [<c012b2b5>] __do_softirq+0x7b/0x118 [ 8683.928121] [ 8683.928121] other info that might help us debug this: [ 8683.928121] [ 8683.928121] Possible unsafe locking scenario: [ 8683.928121] [ 8683.928121] CPU0 CPU1 [ 8683.928121] ---- ---- [ 8683.928121] lock(_xmit_ETHER#2); [ 8683.928121] lock(slock-AF_INET); [ 8683.928121] lock(_xmit_ETHER#2); [ 8683.928121] lock(slock-AF_INET); [ 8683.928121] [ 8683.928121] *** DEADLOCK *** [ 8683.928121] [ 8683.928121] 3 locks held by swapper/0/0: [ 8683.928121] #0: (rcu_read_lock){.+.+..}, at: [<c02dbc10>] rcu_lock_acquire+0x0/0x30 [ 8683.928121] #1: (rcu_read_lock_bh){.+....}, at: [<c02dbc10>] rcu_lock_acquire+0x0/0x30 [ 8683.928121] #2: (_xmit_ETHER#2){+.-...}, at: [<c02f062d>] sch_direct_xmit+0x36/0x119 [ 8683.928121] [ 8683.928121] stack backtrace: [ 8683.928121] Pid: 0, comm: swapper/0 Not tainted 3.4.1-build-0061 #14 [ 8683.928121] Call Trace: [ 8683.928121] [<c034bdd2>] ? printk+0x18/0x1a [ 8683.928121] [<c0158904>] print_circular_bug+0x1ac/0x1b6 [ 8683.928121] [<c0159f1b>] __lock_acquire+0x9a3/0xc27 [ 8683.928121] [<c015a561>] lock_acquire+0x71/0x85 [ 8683.928121] [<e0fc73ec>] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core] [ 8683.928121] [<c034da2d>] _raw_spin_lock+0x33/0x40 [ 8683.928121] [<e0fc73ec>] ? l2tp_xmit_skb+0x173/0x47e [l2tp_core] [ 8683.928121] [<e0fc73ec>] l2tp_xmit_skb+0x173/0x47e [l2tp_core] [ 8683.928121] [<e0fe31fb>] l2tp_eth_dev_xmit+0x1a/0x2f [l2tp_eth] [ 8683.928121] [<c02e01e7>] dev_hard_start_xmit+0x333/0x3f2 [ 8683.928121] [<c02f064c>] sch_direct_xmit+0x55/0x119 [ 8683.928121] [<c02e0528>] dev_queue_xmit+0x282/0x418 [ 8683.928121] [<c02e02a6>] ? dev_hard_start_xmit+0x3f2/0x3f2 [ 8683.928121] [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c [ 8683.928121] [<c031f524>] arp_xmit+0x22/0x24 [ 8683.928121] [<c02e02a6>] ? dev_hard_start_xmit+0x3f2/0x3f2 [ 8683.928121] [<c031f567>] arp_send+0x41/0x48 [ 8683.928121] [<c031fa7d>] arp_process+0x289/0x491 [ 8683.928121] [<c031f7f4>] ? __neigh_lookup.clone.20+0x42/0x42 [ 8683.928121] [<c031f4fb>] NF_HOOK.clone.19+0x45/0x4c [ 8683.928121] [<c031f7a0>] arp_rcv+0xb1/0xc3 [ 8683.928121] [<c031f7f4>] ? __neigh_lookup.clone.20+0x42/0x42 [ 8683.928121] [<c02de91b>] __netif_receive_skb+0x329/0x378 [ 8683.928121] [<c02de9d3>] process_backlog+0x69/0x130 [ 8683.928121] [<c02df103>] net_rx_action+0x90/0x15d [ 8683.928121] [<c012b2b5>] __do_softirq+0x7b/0x118 [ 8683.928121] [<c012b23a>] ? local_bh_enable+0xd/0xd [ 8683.928121] <IRQ> [<c012b4d0>] ? irq_exit+0x41/0x91 [ 8683.928121] [<c0103c6f>] ? do_IRQ+0x79/0x8d [ 8683.928121] [<c0157ea1>] ? trace_hardirqs_off_caller+0x2e/0x86 [ 8683.928121] [<c034ef6e>] ? common_interrupt+0x2e/0x34 [ 8683.928121] [<c0108a33>] ? default_idle+0x23/0x38 [ 8683.928121] [<c01091a8>] ? cpu_idle+0x55/0x6f [ 8683.928121] [<c033df25>] ? rest_init+0xa1/0xa7 [ 8683.928121] [<c033de84>] ? __read_lock_failed+0x14/0x14 [ 8683.928121] [<c0498745>] ? start_kernel+0x303/0x30a [ 8683.928121] [<c0498209>] ? repair_env_string+0x51/0x51 [ 8683.928121] [<c04980a8>] ? i386_start_kernel+0xa8/0xaf It appears that like most virtual devices, l2tp should be converted to LLTX mode. This patch takes care of statistics using atomic_long in both RX and TX paths, and fix a bug in l2tp_eth_dev_recv(), which was caching skb->data before a pskb_may_pull() call. Signed-off-by:Eric Dumazet <edumazet@google.com> Reported-by:
Denys Fedoryshchenko <denys@visp.net.lb> Cc: James Chapman <jchapman@katalix.com> Cc: Hong zhi guo <honkiko@gmail.com> Cc: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
- 25 Jun, 2012 11 commits
-
-
alex.bluesman.smirnov@gmail.com authored
Add missed braces after 'if' operator. Signed-off-by:
Alexander Smirnov <alex.bluesman.smirnov@gmail.com> Signed-off-by:
-
Eric Dumazet authored
Its illegal to dereference skb after giving it to l2tp_xmit_skb() as it might be already freed/reused. Signed-off-by:
-
Yevgeny Petrilin authored
Add a missing resource release in ring cleanup. Not doing this leaves a range of QPs that are being reserved, and no one can use them. Signed-off-by:
Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by:
-
Yevgeny Petrilin authored
Fix a crash at the error flow of NOP command which caused the driver to try and use a completion vector which wasn't allocated. Signed-off-by:
-
Yevgeny Petrilin authored
Set valid port parameters: MTU and flow control configuration when configuring the port during HW device initialization, prior to the net device open() being called. Using invalid parameters (such as all zeros) could lead to bad firmware behavior. Signed-off-by:
-
Davide Gerhard authored
This adds support for the iPad to the ipheth driver. (product id = 0x129a) Signed-off-by:
Davide Gerhard <rainbow@irh.it> Signed-off-by:
-
Sjur Brændeland authored
Fix a missing return, causing access to freed memory. Signed-off-by:
Sjur Brændeland <sjur.brandeland@stericsson.com> Signed-off-by:
-
Per Ellefsen authored
When receiving a piggyback'ed descriptor containing an embedded frame, but no payload, the embedded frame was lost. Signed-off-by:
Per Ellefsen <per.ellefsen@stericsson.com> Signed-off-by:
-
Sjur Brændeland authored
Clear caif sockets's shutdown mask at (re)connect. Signed-off-by:
-
Neal Cardwell authored
If security_inet_conn_request() returns non-zero then TCP/IPv6 should drop the request, just as in TCP/IPv4 and DCCP in both IPv4 and IPv6. Signed-off-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
-
Eric Dumazet authored
Commit 2bec5a36 (ipv6: fib: fix crash when changing large fib while dumping it) introduced ability to restart the dump at tree root, but failed to skip correctly a count of already dumped entries. Code didn't match Patrick intent. We must skip exactly the number of already dumped entries. Note that like other /proc/net files or netlink producers, we could still dump some duplicates entries. Reported-by:
Debabrata Banerjee <dbavatar@gmail.com> Reported-by:
Josh Hunt <johunt@akamai.com> Signed-off-by:
-
- 23 Jun, 2012 8 commits
-
-
Antonio Quartulli authored
bug introduced with cea194d90b11aff7fc289149e4c7f305fad3535a In the current TT code, when a TT_Response containing a full table is received from an originator, first the node purges all the clients for that originator in the global translation-table and then merges the newly received table. During the purging phase each client deletion is done by means of a call_rcu() invocation and at the end of this phase the global entry counter for that originator is set to 0. However the invoked rcu function decreases the global entry counter for that originator by one too and since the rcu invocation is likely to be postponed, the node will end up in first setting the counter to 0 and then decreasing it one by one for each deleted client. This bug leads to having a wrong global entry counter for the related node, say X. Then when the node with the broken counter will answer to a TT_REQUEST on behalf of node X, it will create faulty TT_RESPONSE that will generate an unrecoverable situation on the node that asked for the full table recover. The non-recoverability is given by the fact that the node with the broken counter will keep answering on behalf of X because its knowledge about X's state (ttvn + tt_crc) is correct. To solve this problem the counter is not explicitly set to 0 anymore and the counter decrement is performed right before the invocation of call_rcu(). Signed-off-by:Antonio Quartulli <ordex@autistici.org>
-
Marek Lindner authored
bug introduced with 59b699cd If the source or destination mac address of an ethernet packet could not be found in the translation table the packet was dropped if AP isolation was turned on. This behavior would make it impossible to send broadcast packets over the mesh as the broadcast address will never enter the translation table. Signed-off-by:
Marek Lindner <lindner_marek@yahoo.de> Acked-by:
-
Yoshihiro Shimoda authored
The following commit couldn't work if the RMCR is not set to 1. "net: sh_eth: fix the rxdesc pointer when rx descriptor empty happens" commit id 79fba9f5 If RMCR is not set, the controller will clear the EDRRR after it received a frame. In this case, the driver doesn't need to fix the value of cur_rx/dirty_rx. The driver only needs it when the controll detects receive descriptors are empty. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
françois romieu authored
The 8168evl (RTL_GIGA_MAC_VER_34) based Gigabyte GA-990FXA motherboards are very prone to NETDEV watchdog problems without this change. See https://bugzilla.kernel.org/show_bug.cgi?id=42899 for instance. I don't know why it *works*. It's depressingly effective though. For the record: - the problem may go along IOMMU (AMD-Vi) errors but it really looks like a red herring. - the patch sets the RX_MULTI_EN bit. If the 8168c doc is any guide, the chipset now fetches several Rx descriptors at a time. - long ago the driver ignored the RX_MULTI_EN bit. e542a226 changed the RxConfig settings. Whatever the problem it's now labeled a regression. - Realtek's own driver can identify two different 8168evl devices (CFG_METHOD_16 and CFG_METHOD_17) where the r8169 driver only sees one. It sucks. Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Ming Lei authored
If usbnet is resumed by remote wakeup, generally there are some packets comming to be handled, so allocate and submit rx URBs in usbnet_resume to avoid delays introduced by tasklet. Otherwise, usbnet may have been runtime suspended before the usbnet_bh is executed to schedule Rx URBs. Without the patch, usbnet can't recieve any packets from peer in runtime suspend state if runtime PM is enabled and autosuspend_delay is set as zero. Signed-off-by:
Ming Lei <ming.lei@canonical.com> Acked-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Ming Lei authored
This patch decreases dev->suspend_count in the -EBUSY failure path of usbnet_suspend. Without the change, the later runtime suspend will do nothing except for increasing dev->suspend_count. Signed-off-by:
-
Ming Lei authored
Without clearing OPEN flag in failure path, runtime or system resume may submit interrupt/rx URB and start tx queue mistakenly on a interface in DOWN state. Signed-off-by:
-
Bjørn Mork authored
Ignoring interfaces with additional descriptors is not a reliable method for locating the correct interface on Gobi devices. There is at least one device where this method fails: https://bbs.archlinux.org/viewtopic.php?id=143506 The result is that the AT command port (interface #2) is hidden from qcserial, preventing traditional serial modem usage: [ 15.562552] qmi_wwan 4-1.6:1.0: cdc-wdm0: USB WDM device [ 15.562691] qmi_wwan 4-1.6:1.0: wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b [ 15.563383] qmi_wwan: probe of 4-1.6:1.1 failed with error -22 [ 15.564189] qmi_wwan 4-1.6:1.2: cdc-wdm1: USB WDM device [ 15.564302] qmi_wwan 4-1.6:1.2: wwan1: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b [ 15.564328] qmi_wwan: probe of 4-1.6:1.3 failed with error -22 [ 15.569376] qcserial 4-1.6:1.1: Qualcomm USB modem converter detected [ 15.569440] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB0 [ 15.570372] qcserial 4-1.6:1.3: Qualcomm USB modem converter detected [ 15.570430] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB1 Use static interface numbers taken from the interface map in qcserial for all Gobi devices instead: Gobi 1K USB layout: 0: serial port (doesn't respond) 1: serial port (doesn't respond) 2: AT-capable modem port 3: QMI/net Gobi 2K+ USB layout: 0: QMI/net 1: DM/DIAG (use libqcdm from ModemManager for communication) 2: AT-capable modem port 3: NMEA This should be more reliable over all, and will also prevent the noisy "probe failed" messages. The whitelisting logic is expected to be replaced by direct interface number matching in 3.6. Reported-by:
Heinrich Siebmanns (Harvey) <H.Siebmanns@t-online.de> Cc: <stable@vger.kernel.org> # v3.4: 00001880 USB: qmi_wwan: Make forced int 4 whitelist generic Cc: <stable@vger.kernel.org> # v3.4: f7142e6c USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z Cc: <stable@vger.kernel.org> # v3.4 Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
- 22 Jun, 2012 1 commit
-
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
-
- 20 Jun, 2012 9 commits
-
-
Rajkumar Manoharan authored
After the change "mac80211: remove spurious BSSID change flag", BSS_CHANGED_BSSID will not be passed on association or IBSS status changes. So it could be better to program bssid on ASSOC or IBSS change notification. Not doing so, is affecting the packet transmission. Cc: stable@vger.kernel.org [3.4+] Reported-by:
Michael Leun <lkml20120218@newton.leun.net> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When debugging is disabled, the event log functions aren't functional in the way that the debugfs file expects. This leads to the debugfs access crashing. Since the event log functions aren't functional then, remove the debugfs file when CONFIG_IWLWIFI_DEBUG is not set. Cc: stable@kernel.org Reported-by:
Lekensteyn <lekensteyn@gmail.com> Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
"ath9k: Fix softlockup in AR9485" with commit id 64bc1239 fixed the reported issue, yet its better to avoid the possible infinite loop in ar9003_get_pll_sqsum_dvc by having a timeout as suggested by ath9k maintainers. http://www.spinics.net/lists/linux-wireless/msg92126.html. Based on my testing PLL's locking measurement is done in ~200us (2 iterations). Cc: stable@vger.kernel.org Cc: Rolf Offermanns <rolf.offermanns@gmx.net> Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
Grazvydas Ignotas authored
This patch fixes two memory leaks in the SPI initialization code. Patch based on old maemo patch by: Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
-
Grazvydas Ignotas authored
Always report beacon loss to the stack, not only when in powersave state. This is because there's possibility that the driver disables PSM before it handles old BSS_LOSE_EVENT, so beacon loss has to be reported. Patch based on old maemo patch by: Janne Ylalehto <janne.ylalehto@nokia.com> Juuso Oikarinen <juuso.oikarinen@nokia.com> Luciano Coelho <luciano.coelho@nokia.com> Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by:
-
Grazvydas Ignotas authored
Cast MSB part of current TSF to u64 to prevent loss of most significant bits. MSB should also be shifted by 32. Patch based on old maemo patch by: Yuri Kululin <ext-yuri.kululin@nokia.com> Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by:
-
Alexander Duyck authored
This patch fixes a memory leak that was introduced in the 3.4 kernel. The leak occurred when FCoE was enabled and traffic was passed over the FCoE rings reserved for FCoE. The memory leak was due to us not populating the compound page information on the order 1 pages needed for FCoE. Signed-off-by:
-
Carolyn Wyborny authored
Fix Kconfig file to make sure that PTP and IGB/IXGBE are both either in-kernel or modules, not mixed. Having the build status mixed causes compile errors. Signed-off-by:
Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by:
Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by:
-
Carolyn Wyborny authored
i210/i211 device has only 16 RAR address filters like 82575, instead of 32 like i350. This patch removes the entries for i210/i211 in the get_invariants function which was setting them for 32. This ensures that they will get the default value which is the correct one. Signed-off-by:
-
- 19 Jun, 2012 9 commits
-
-
Antonio Quartulli authored
skb_linearize(skb) possibly rearranges the skb internal data and then changes the skb->data pointer value. For this reason any other pointer in the code that was assigned skb->data before invoking skb_linearise(skb) must be re-assigned. In the current tt_query message handling code this is not done and therefore, in case of skb linearization, the pointer used to handle the packet header ends up in pointing to free'd memory. This bug was introduced by a73105b8 (batman-adv: improved client announcement mechanism) Signed-off-by:
-
-
Bing Zhao authored
add_virtual_intf() needs to return an ERR_PTR(), instead of NULL, on errors, otherwise cfg80211 will crash. Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Dan Carpenter authored
"qual" used to be declared on the stack, but then in 998a5a7d ("airo: reduce stack memory footprint") we made it dynamically allocated. Unfortunately the memcpy() here was missed and it's still copying stack memory instead of the data that we want. In other words, "&qual" should be "qual". Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Avinash Patil authored
When running heavy traffic we stop the tx queue if the pending packet count reaches certain threshold. Later, the tx queue should be woken up as soon as the packet count falls below the threshold. Current code wakes TX queue up on STA interface only. Removing the check for STA interface will allow both STA and AP interfaces to resume transmit when tx_pending count becomes low. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
Bob Copeland authored
spin_unlock_bh(&txq->lock) already disables softirqs so we don't want to do it here. Fixes smatch warnings: drivers/net/wireless/ath/ath5k/base.c:1048 ath5k_drain_tx_buffs() error: double lock 'bottom_half:' drivers/net/wireless/ath/ath5k/base.c:1056 ath5k_drain_tx_buffs() error: double unlock 'bottom_half:' Reported-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Felix Fietkau authored
After setup_frame_info has been called, only info->control.rates is still valid, other control fields have been overwritten by the ath_frame_info data. Move the access to info->control.vif for checking short preamble to setup_frame_info before it gets overwritten. This regression was introduced in commit d47a61aa "ath9k: Fix multi-VIF BSS handling" Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Reported-by:
Thomas Hühn <thomas@net.t-labs.tu-berlin.de> Acked-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Cc: stable@vger.kernel.org [3.4] Signed-off-by:
-
Felix Fietkau authored
The rate pointer variable for a rate series is used in a loop before it is initialized. This went unnoticed because it was used earlier for the RTS/CTS rate. This bug can lead to the wrong PHY type being passed to the duration calculation function. Signed-off-by:
-
Jason Wang authored
On a freescale imx6q platform, a hardware phy chip KSZ9021 is recognized as a KS8001 chip by the current driver like this: eth0: Freescale FEC PHY driver [Micrel KS8001 or KS8721] KSZ9021 has phy_id 0x00221610, while KSZ8001 has phy_id 0x0022161a, the current phy_id_mask (0x00fffff0/0x00ffff10) can't distinguish them. So change phy_id_mask to resolve this problem. Although the micrel datasheet says that the 4 LSB of phyid2 register contains the chip revision number and the current driver is designed to follow this rule, in reality the chip implementation doesn't follow it. Cc: David J. Choi <david.choi@micrel.com> Cc: David S. Miller <davem@davemloft.net> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by:
Hui Wang <jason77.wang@gmail.com> Signed-off-by:
-
