- 29 10月, 2014 17 次提交
-
-
由 Johannes Berg 提交于
The warning gives no information about the frame, and presents the flags so that one might think they're the frame. Clarify and add more information. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
This makes it easier to tune the values during the testing. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Arik Nemtsov 提交于
It is unused and won't be available in some future invocations of the function. Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Max Stepanov 提交于
The MVM_FW_BCAST_FILTER_PASS_ALL option defined in iwl-dbg-cfg.ini configuration file allows to enable/disable FW broadcast filtering. If MVM_FW_BCAST_FILTER_PASS_ALL is not defined in iwl-dbg-cfg.ini or its value is 0, the mvm broadcast filtering is enabled. Setting MVM_FW_BCAST_FILTER_PASS_ALL=1 in iwl-dbg-cfg.ini blocks sending of BCAST_FILTER_CMD to FW. Signed-off-by: NMax Stepanov <Max.Stepanov@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
This is were it really needs to be. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eran Harary 提交于
In the new format the "CSS section" has the same TLV type as the "mem section". So we need to run the secured flow for all the 8000 products. Signed-off-by: NEran Harary <eran.harary@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
When the ARC is reset when we exit from Sx in case we had WoWLAN running, we can't access the prph before we reset the NIC. Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
Otherwise we have no way to know that the buffer hasn't been allocated. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Gregory Greenman 提交于
A few slave bus devices show better performance when we reduce the size of the Tx A-MPDU. Signed-off-by: NGregory Greenman <gregory.greenman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luciano Coelho 提交于
Getting the BSS station vif is something that may be needed by other parts of the code. So, instead of having an iterator specifically for d3, change it into a generic one in utils.c. Additionally, add a iwl_mvm_get_bss_vif() function to make it easier to retrieving it. Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luciano Coelho 提交于
Before we get all the chain (ie. mac80211, cfg80211, nl80211 and userspace) changed to support net-detect, we can use this debugfs entry for easy testing and as a proof of concept. Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luciano Coelho 提交于
The net-detect feature will require a scan offload to be started in the same way it is done now for scheduled scan. Spin a new function off of the sched_scan_start op code for reuse. Additionally, restructure the function a bit for more readability. Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luciano Coelho 提交于
Instead of checking if we are associated when suspending with wowlan enabled in the interface iterator, allow it to return an unassociated vif and move the check to the main suspend function. This will be needed by netdetect, since it should also work when we are not associated but the vif is active. Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luciano Coelho 提交于
Take the WoWLAN handling code out of the main suspend function, dividing it into three parts: get_config (which is used before the firmware is switched), switch_to_d3 (which handles the rebooting of the hardware with the D3 firmware) and config (which configures the D3 firmware for WoWLAN operation). This is necessary to prepare for the net-detect implementation, which will use only the switch_to_d3 part of this flow. Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Luciano Coelho 提交于
We use ieee80211_iter_keys() which requires the rtnl to be held. If we don't lock the rtnl, like we do when we suspend during a d3 test, we get the following splat: RTNL: assertion failed at net/mac80211/key.c (566) CPU: 1 PID: 26529 Comm: cat Tainted: G W O 3.10.29-dev #1 Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012 e7b15008 e7b15008 e68adc1c c168aa62 e68adc54 f91f20b6 f923700c f9236fd8 00000236 00000000 ece23874 00000000 f94941e0 00000000 e43b8e48 e7b15008 00000000 e8b69e78 e68adcc0 f9493ab9 e68adc68 00000000 e43b8e48 e7b15008 Call Trace: [<c168aa62>] dump_stack+0x16/0x18 [<f91f20b6>] ieee80211_iter_keys+0x166/0x170 [mac80211] [<f94941e0>] ? iwl_mvm_query_wakeup_reasons+0x5f0/0x5f0 [iwlmvm] [<f9493ab9>] iwl_mvm_setup_connection_keep.isra.5+0x99/0x1d0 [iwlmvm] [<f9165e28>] ? cfg80211_report_wowlan_wakeup+0x308/0x510 [cfg80211] [<f9493fe5>] iwl_mvm_query_wakeup_reasons+0x3f5/0x5f0 [iwlmvm] [<c116125a>] ? init_object+0x3a/0x70 [<f8a5b8ee>] ? iwl_trans_pcie_d3_resume+0x1be/0x3a0 [iwlwifi] [<f94956da>] __iwl_mvm_resume+0x14a/0x180 [iwlmvm] [<f9495736>] iwl_mvm_d3_test_release+0x26/0xc0 [iwlmvm] [<c117a64d>] __fput+0xad/0x210 [<c117a7bd>] ____fput+0xd/0x10 [<c10601a1>] task_work_run+0x81/0xb0 [<c1040fa5>] do_exit+0x255/0xac0 [<c104e511>] ? dequeue_signal+0x31/0x1a0 [<c1041888>] do_group_exit+0x38/0xa0 [<c10a6cfb>] ? trace_hardirqs_on+0xb/0x10 [<c1051c31>] get_signal_to_deliver+0x1e1/0x8e0 [<c104bd52>] ? try_to_del_timer_sync+0x42/0x60 [<c104bd70>] ? try_to_del_timer_sync+0x60/0x60 [<c168dc82>] ? schedule_timeout+0x102/0x2a0 [<c10011ba>] do_signal+0x3a/0x8e0 [<c104b190>] ? __internal_add_timer+0xb0/0xb0 [<c168de7a>] ? schedule_timeout_interruptible+0x1a/0x20 [<c104ce39>] ? msleep_interruptible+0x39/0x40 [<f94939a9>] ? iwl_mvm_d3_test_read+0x49/0x70 [iwlmvm] [<c11797fc>] ? vfs_read+0x8c/0x160 [<c11243af>] ? SyS_fadvise64_64+0x15f/0x2b0 [<f9493960>] ? iwl_mvm_wowlan_program_keys+0x4a0/0x4a0 [iwlmvm] [<c1179a57>] ? SyS_read+0x57/0xa0 [<c1001acf>] do_notify_resume+0x6f/0xa0 [<c1692500>] work_notifysig+0x29/0x31 Fix this by hold the rtnl lock when calling __iwl_mvm_resume() in the d3 test wake up path. Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
mac80211 will never call rate_control_tx_status with a NULL pointer for sta. Remove the superfluous check. This check misled smatch. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eyal Shapira 提交于
The current TLC isn't optimized for low latency and some devices have issues with MIMO. This kind of combo creates latency issues. Allow to temporarily disable MIMO for tests in order to solve the latency issues without the added complexity of MIMO. Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com> Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 24 10月, 2014 9 次提交
-
-
由 Emmanuel Grumbach 提交于
iwl_poll_bit may return a strictly positive value when the poll doesn't match on the first try. This was caught when WoWLAN started failing upon resume even if the poll_bit actually succeeded. Also change a wrong print. If we reach the end of iwl_pcie_prepare_card_hw, it means that we couldn't get the devices. Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
This reverts commit aa11bbf3. This commit was causing connection issues and is not needed if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default. Regardless of the issues mentioned above, this patch added the following WARNING: WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:190 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]() Got an HT rate for a non data frame 0x8 CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G O 3.17.0+ #6 Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07/02/2014 0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52 0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600 0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020 Call Trace: [<ffffffff814fa911>] ? dump_stack+0x41/0x51 [<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90 [<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50 [<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm] [<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm] [<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm] [<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211] [<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211] [<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80211] [<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0 [<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0 [<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0 [<ffffffff8142f670>] ? ether_setup+0x70/0x70 [<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110 [<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40 [<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0 [<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60 [<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0 [<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180 [<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70 [<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f ---[ end trace cc19a150d311fc63 ]--- which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=85691 CC: <stable@vger.kernel.org> [3.13+] Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
When mac80211 wants to ensure that a frame is sent, it calls the flush() callback. Until now, iwldvm implemented this by waiting that all the frames are sent (ACKed or timeout). In case of weak signal, this can take a significant amount of time, delaying the next connection (in case of roaming). Many users have reported that the flush would take too long leading to the following error messages to be printed: iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2 iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201 iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00 [snip] iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000 [snip] iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [9,9] [snip] Instead of waiting for these packets, simply drop them. This significantly improves the responsiveness of the network. Note that all the queues are flushed, but the VO one. This is not typically used by the applications and it likely contains management frames that are useful for connection or roaming. This bug is tracked here: https://bugzilla.kernel.org/show_bug.cgi?id=56581 But it is duplicated in distributions' trackers. A simple search in Ubuntu's database led to these bugs: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809 Cc: <stable@vger.kernel.org> Depends-on: 77be2c54 ("mac80211: add vif to flush call") Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Matti Gottlieb 提交于
Don't add the time event to the list. We added it several times the same time event, which leads to an infinite loop when walking the list. Since we (currently) don't support more than one ROC for STA vif at a time, enforce this and don't add the time event to any list. We were also missing the locking of the mutex which led to a lockdep splat - fix that. Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Haim Dreyfuss 提交于
The tx power should be limited from many reasons. currently, setting the tx power is available by the mvm only for station interface. Adding the tx power condition to bss_info_changed_ap_ibss make it available also for AP. Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
The probe requests sent during scan must get BT prio 3. Fix that. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
Cc: <stable@vger.kernel.org> [3.16+] Fixes: 2adc8949 ("iwlwifi: mvm: BT Coex - fix boost register / LUT values") Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Liad Kaufman 提交于
I changed the string but forgot to update the fix also to MODULE_FIRMWARE(). Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
The LTR is the handshake between the device and the root complex about the latency allowed when the bus exits power save. This configuration was missing and this led to high latency in the link power up. The end user could experience high latency in the network because of this. Cc: <stable@vger.kernel.org> [3.10+] Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 09 10月, 2014 8 次提交
-
-
由 Eric Dumazet 提交于
Add two helpers so that drivers do not have to care of BQL being available or not. Signed-off-by: NEric Dumazet <edumazet@google.com> Reported-by: NJim Davis <jim.epost@gmail.com> Fixes: 29d40c90 ("net/mlx4_en: Use prefetch in tx path") Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
The tx_desc struct holds 8 __be64 values. The original code in ring_tx_db() took a tx_desc pointer then casted it to an int pointer and then casted it to a u64 pointer. It was confusing and triggered some static checker warnings. I have changed the cxgb_pio_copy() function to only take tx_desc pointers. This isn't really a loss of flexibility because anything else was buggy to begin with. I also removed the casting on the destination pointer since that was unnecessary and a bit messy. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
"cntxt_id" is an unsigned int but "udb" is a u64 so there is a potential shift wrapping bug here. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
Support skb->xmit_more in i40e is straightforward : we need to move around i40e_maybe_stop_tx() call to correctly test netif_xmit_stopped() before taking the decision to not kick the NIC. Signed-off-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDaniel Borkmann <dborkman@redhat.com> Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 LEROY Christophe 提交于
When using a MPC8xx as a router, 'perf' shows a significant time spent in fs_enet_interrupt() and fs_enet_start_xmit(). 'perf annotate' shows that the time spent in fs_enet_start_xmit is indeed spent between spin_unlock_irqrestore() and the following instruction, hence in interrupt handling. This is due to the TX complete interrupt that fires after each transmitted packet. This patch modifies the handling of TX complete to use NAPI. With this patch, my NAT router offers a throughput improved by 21% Original performance: [root@localhost tmp]# scp toto pgs:/tmp toto 100% 256MB 2.8MB/s 01:31 Performance with the patch: [root@localhost tmp]# scp toto pgs:/tmp toto 100% 256MB 3.4MB/s 01:16 Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 LEROY Christophe 提交于
In the probe function, use_napi is inconditionnaly set to 1. This patch removes all the code which is conditional to !use_napi, and removes use_napi which has then become useless. Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Chun-Hao Lin 提交于
RTL8168EP is Realtek PCIe Gigabit Ethernet controller with DASH support. It is a successor chip of RTL8168DP. For RTL8168EP, the read/write ocp register is via eri channel type 2, so I move ocp_xxx() related functions under rtl_eri_xxx. And use r8168dp_ocp_xxx() for RTL8168DP ocp read/write, r8168ep_ocp_xxx() for RTL8168EP ocp read/write. The way of checking dash enable is different with RTL8168DP. I use r8168dp_check_dash()for RTL8168DP and r8168ep_check_dash() for RTL8168EP, to check if dash is enabled. The driver_start() and driver_stop() of RTL8168EP is also different with RTL8168DP. I use rtl8168dp_driver_xxx() for RTL8168DP and rtl8168ep_driver_xxx for RTL8168EP. Right now, RTL8168EP phy mcu did not need firmware code patch, so I did not add firmware code for it. so I did not add firmware code for it. Signed-off-by: NChun-Hao Lin <hau@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Pawel Moll 提交于
Because CCN's cycle counter always runs, it will generate an interrupt on overflow even if the relevant perf event was not requested, causing a spurious warning message. Fixed now by warning on only normal counter unwanted overflows. Also cleaning the overflow mask at init now, not to warn on event previously requested by firmware. Signed-off-by: NPawel Moll <pawel.moll@arm.com> Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 08 10月, 2014 6 次提交
-
-
由 Linus Torvalds 提交于
Commit 7bced397 ("net_dma: simple removal") removed the long-dead net_dma code, but unintentionally broke the build for the qualcomm crypto engine (qce) that had accidentally depended on the inclusion of <linux/dmaengine.h> through the networking header files that used to have it. Add the required dmaengine.h include explicitly to fix the breakage. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Takao Indoh 提交于
This patch fixes a bug on hotmod removing. After ipmi interface is removed using hotmod, kernel panic occurs when rmmod impi_si. For example, try this: # echo "remove,"`cat /proc/ipmi/0/params` > \ /sys/module/ipmi_si/parameters/hotmod # rmmod ipmi_si Then, rmmod fails with the following messages. ------------[ cut here ]------------ WARNING: CPU: 12 PID: 10819 at /mnt/repos/linux/lib/list_debug.c:53 __list_del_entry+0x63/0xd0() CPU: 12 PID: 10819 Comm: rmmod Not tainted 3.17.0-rc1 #19 Hardware name: FUJITSU-SV PRIMERGY BX920 S2/D3030, BIOS 080015 Rev.3D81.3030 02/10/2012 Call Trace: dump_stack+0x45/0x56 warn_slowpath_common+0x7d/0xa0 warn_slowpath_fmt+0x4c/0x50 __list_del_entry+0x63/0xd0 list_del+0xd/0x30 cleanup_one_si+0x2a/0x230 [ipmi_si] ipmi_pnp_remove+0x15/0x20 [ipmi_si] pnp_device_remove+0x24/0x40 __device_release_driver+0x7f/0xf0 driver_detach+0xb0/0xc0 bus_remove_driver+0x55/0xd0 driver_unregister+0x2c/0x50 pnp_unregister_driver+0x12/0x20 cleanup_ipmi_si+0xbc/0xf0 [ipmi_si] SyS_delete_module+0x132/0x1c0 system_call_fastpath+0x16/0x1b ---[ end trace 70b4377268f85c23 ]--- list_del in cleanup_one_si() fails because the smi_info is already removed when hotmod removing. When ipmi interface is removed by hotmod, smi_info is removed by cleanup_one_si(), but is is still set in drvdata. Therefore when rmmod ipmi_si, ipmi_pnp_remove tries to remove it again and fails. By this patch, a pointer to smi_info in drvdata is cleared when hotmod removing so that it will be not accessed when rmmod. changelog: v2: - Clear drvdata in cleanup_one_si - Change subject v1: https://lkml.org/lkml/2014/9/8/741Signed-off-by: NTakao Indoh <indou.takao@jp.fujitsu.com> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Arnd Bergmann 提交于
Building ipmi on arm with gcc-4.9 results in this warning for an allmodconfig build: drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_thread': include/linux/time.h:28:5: warning: 'busy_until.tv_sec' may be used uninitialized in this function [-Wmaybe-uninitialized] if (lhs->tv_sec > rhs->tv_sec) ^ drivers/char/ipmi/ipmi_si_intf.c:1007:18: note: 'busy_until.tv_sec' was declared here struct timespec busy_until; ^ The warning is bogus and this case can not occur. Apparently this is a false positive resulting from gcc getting a little smarter about tracking assignments but not smart enough. Marking the ipmi_thread_busy_wait function as inline gives the gcc optimization logic enough information to figure out for itself that the case cannot happen, which gets rid of the warning without adding any fake initialization. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Benjamin Herrenschmidt 提交于
If an IPMI controller is used by the firmware and as such marked with a reserved status, we shouldn't use it. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Corey Minyard 提交于
The code to send the channel config errors was missing an error report in one place and needed some more information in another, and had an extraneous bit of code. Clean all that up. Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Eric Dumazet 提交于
Testing xmit_more support with netperf and connected UDP sockets, I found strange dst refcount false sharing. Current handling of IFF_XMIT_DST_RELEASE is not optimal. Dropping dst in validate_xmit_skb() is certainly too late in case packet was queued by cpu X but dequeued by cpu Y The logical point to take care of drop/force is in __dev_queue_xmit() before even taking qdisc lock. As Julian Anastasov pointed out, need for skb_dst() might come from some packet schedulers or classifiers. This patch adds new helper to cleanly express needs of various drivers or qdiscs/classifiers. Drivers that need skb_dst() in their ndo_start_xmit() should call following helper in their setup instead of the prior : dev->priv_flags &= ~IFF_XMIT_DST_RELEASE; -> netif_keep_dst(dev); Instead of using a single bit, we use two bits, one being eventually rebuilt in bonding/team drivers. The other one, is permanent and blocks IFF_XMIT_DST_RELEASE being rebuilt in bonding/team. Eventually, we could add something smarter later. Signed-off-by: NEric Dumazet <edumazet@google.com> Cc: Julian Anastasov <ja@ssi.bg> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-