- 31 10月, 2014 6 次提交
-
-
由 Or Gerlitz 提交于
If mlx4_ib_create_flow() attempts to create > 1 rules with the firmware, and one of these registrations fail, we leaked the already created flow rules. One example of the leak is when the registration of the VXLAN ghost steering rule fails, we didn't unregister the original rule requested by the user, introduced in commit d2fce8a9 "mlx4: Set user-space raw Ethernet QPs to properly handle VXLAN traffic". While here, add dump of the VXLAN portion of steering rules so it can actually be seen when flow creation fails. Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Or Gerlitz 提交于
For VXLAN/NVGRE encapsulation, the current HW doesn't support offloading both the outer UDP TX checksum and the inner TCP/UDP TX checksum. The driver doesn't advertize SKB_GSO_UDP_TUNNEL_CSUM, however we are wrongly telling the HW to offload the outer UDP checksum for encapsulated packets, fix that. Fixes: 837052d0 ('net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling') Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anish Bhatt 提交于
win0_lock was being used un-initialized, resulting in warning traces being seen when lock debugging is enabled (and just wrong) Fixes : fc5ab020 ('cxgb4: Replaced the backdoor mechanism to access the HW memory with PCIe Window method') Signed-off-by: NAnish Bhatt <anish@chelsio.com> Signed-off-by: NCasey Leedom <leedom@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 hayeswang 提交于
Avoid unnecessary behavior when autosuspend occurs during open(). The relative processes should only be run after finishing open(). Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 hayeswang 提交于
If (tp->speed & LINK_STATUS) is not zero, the rtl8152_resume() would call rtl_start_rx() before enabling the tx/rx. Avoid this by resetting it to zero. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 hayeswang 提交于
The flag of SELECTIVE_SUSPEND should be cleared when autoresuming. Otherwise, when the system suspend and resume occur, it may have the wrong flow. Besides, because the flag of SELECTIVE_SUSPEND couldn't be used to check if the hw enables the relative feature, it should alwayes be disabled in close(). Signed-off-by: NHayes Wang <hayeswang@realtek.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 30 10月, 2014 6 次提交
-
-
由 Emil Tantilov 提交于
Following commands: modprobe ixgbe ifconfig ethX up ethtool -s ethX advertise 0x020 can lead to "setup link failed with code -14" error due to the setup_link call racing with the SFP detection routine in the watchdog. This patch resolves this issue by protecting the setup_link call with check for __IXGBE_IN_SFP_INIT. Reported-by: NScott Harrison <scoharr2@cisco.com> Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Junwei Zhang 提交于
Signed-off-by: NMartin Zhang <martinbj2008@gmail.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Roman Gushchin 提交于
Incoming packet is dropped silently by sk_filter(), if the skb was allocated from pfmemalloc reserves and the corresponding socket is not marked with the SOCK_MEMALLOC flag. Igb driver allocates pages for DMA with __skb_alloc_page(), which calls alloc_pages_node() with the __GFP_MEMALLOC flag. So, in case of OOM condition, igb can get pages with pfmemalloc flag set. If an incoming packet hits the pfmemalloc page and is large enough (small packets are copying into the memory, allocated with netdev_alloc_skb_ip_align(), so they are not affected), it will be dropped. This behavior is ok under high memory pressure, but the problem is that the igb driver reuses these mapped pages. So, packets are still dropping even if all memory issues are gone and there is a plenty of free memory. In my case, some TCP sessions hang on a small percentage (< 0.1%) of machines days after OOMs. Fix this by avoiding reuse of such pages. Signed-off-by: NRoman Gushchin <klamm@yandex-team.ru> Tested-by: Aaron Brown "aaron.f.brown@intel.com" Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Francesco Ruggeri 提交于
VMWare's e1000 implementation does not seem to support unicast filtering. This can be observed by configuring a macvlan interface on eth0 in a VM in VMWare Fusion 5.0.5, and trying to use that interface instead of eth0. Tested on 3.16. Signed-off-by: NFrancesco Ruggeri <fruggeri@arista.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Tej Parkash 提交于
1. Remove the rcu_read_lock/unlock around rcu_access_pointer 2. Replace the rcu_dereference with rcu_access_pointer Signed-off-by: NTej Parkash <tej.parkash@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Hariprasad Shenai 提交于
Replaced repetive Device ID's which got added in commit b961f9a4 ("cxgb4vf: Remove superfluous "idx" parameter of CH_DEVICE() macro") Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 10月, 2014 8 次提交
-
-
由 Olivier Blin 提交于
Promiscuous mode was not supported anymore with my Lenovo adapters (RTL8153) since commit c472ab68 (cdc-ether: clean packet filter upon probe). It was not possible to use them in a bridge anymore. Signed-off-by: NOlivier Blin <olivier.blin@softathome.com> Also-analyzed-by: NLoïc Yhuel <loic.yhuel@softathome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Olivier Blin 提交于
This will be used by the set_rx_mode callback. Also move a comment about multicast filtering in this new function. Signed-off-by: NOlivier Blin <olivier.blin@softathome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Olivier Blin 提交于
To delegate promiscuous mode and multicast filtering to the subdriver. Signed-off-by: NOlivier Blin <olivier.blin@softathome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Florian Fainelli 提交于
bcm_sysport_resume() was missing an UniMAC reset which can lead to various receive FIFO corruptions coming out of a suspend cycle. If the RX FIFO is stuck, it will deliver corrupted/duplicate packets towards the host CPU interface. This could be reproduced on crowded network and when Wake-on-LAN is enabled for this particular interface because the switch still forwards packets towards the host CPU interface (SYSTEMPORT), and we had to leave the UniMAC RX enable bit on to allow matching MagicPackets. Once we re-enter the resume function, there is a small window during which the UniMAC receive is still enabled, and we start queueing packets, but the RDMA and RBUF engines are not ready, which leads to having packets stuck in the UniMAC RX FIFO, ultimately delivered towards the host CPU as corrupted. Fixes: 40755a0f ("net: systemport: add suspend and resume support") Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Florian Fainelli 提交于
There is currently a small window during which the SYSTEMPORT adapter enables its RX interrupts without having enabled its NAPI handler, which can result in packets to be discarded during interface bringup. A similar but more serious window exists in bcm_sysport_resume() during which we can have the RDMA engine not fully prepared to receive packets and yet having RX interrupts enabled. Fix this my moving the RX interrupt enable down to bcm_sysport_netif_start() after napi_enable() for the RX path is called, which fixes both call sites: bcm_sysport_open() and bcm_sysport_resume(). Fixes: b02e6d9b ("net: systemport: add bcm_sysport_netif_{enable,stop}") Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vince Bridgers 提交于
Marvell phy 88E1145 configuration & initialization was missing a case for initializing SGMII mode. This patch adds that case. Signed-off-by: NVince Bridgers <vbridger@opensource.altera.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mugunthan V N 提交于
when slave 0 has no phy and slave 1 connected to phy, driver probe will fail as there is no phy id present for slave 0 device tree, so continuing even though no phy-id found, also moving mac-id read later to ensure mac-id is read from device tree even when phy-id entry in not found. Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andrew Lunn 提交于
The mv88e6171 can support two different tagging protocols, DSA and EDSA. The switch driver structure only allows one protocol to be enumerated, and DSA was chosen. However the Kconfig entry ensures the EDSA tagging code is built. With a minimal configuration, we then end up with a mismatch. The probe is successful, EDSA tagging is used, but the switch is configured for DSA, resulting in mangled packets. Change the switch driver structure to enumerate EDSA, fixing the mismatch. Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Fixes: 42f27253 ("net: DSA: Marvell mv88e6171 switch driver") Acked-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 10月, 2014 2 次提交
-
-
由 Anish Bhatt 提交于
Disabling DCBx in firmware automatically enables DCBx for control via host lldp agents. Wait for an explicit setstate call from an lldp agents to enable DCBx instead. Fixes: 76bcb31e ("cxgb4 : Add DCBx support codebase and dcbnl_ops") Signed-off-by: NAnish Bhatt <anish@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anish Bhatt 提交于
Clear out any DCB apps we might have added to kernel table when we lose DCB sync (or IEEE equivalent event). These were previously left behind and not cleaned up correctly. IEEE allows individual components to work independently, so improve check for IEEE completion by specifying individual components. Fixes: 10b00466 ("cxgb4: IEEE fixes for DCBx state machine") Signed-off-by: NAnish Bhatt <anish@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 27 10月, 2014 2 次提交
-
-
由 Eli Cohen 提交于
After moving the EQ ownership to software effectively destroying it, call synchronize_irq() to ensure that any handler routines running on other CPU cores finish execution. Only then free the EQ buffer. The same thing is done when we destroy a CQ which is one of the sources generating interrupts. In the case of CQ we want to avoid completion handlers on a CQ that was destroyed. In the case we do the same to avoid receiving asynchronous events after the EQ has been destroyed and its buffers freed. Signed-off-by: NEli Cohen <eli@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eli Cohen 提交于
After destroying the EQ, the object responsible for generating interrupts, call synchronize_irq() to ensure that any handler routines running on other CPU cores finish execution. Only then free the EQ buffer. This patch solves a very rare case when we get panic on driver unload. The same thing is done when we destroy a CQ which is one of the sources generating interrupts. In the case of CQ we want to avoid completion handlers on a CQ that was destroyed. In the case we do the same to avoid receiving asynchronous events after the EQ has been destroyed and its buffers freed. Signed-off-by: NEli Cohen <eli@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 10月, 2014 6 次提交
-
-
由 Geert Uytterhoeven 提交于
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function ‘xgene_enet_ecc_init’: drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: ‘data’ may be used uninitialized in this function Depending on the arbitrary value on the stack, the loop may terminate too early, and cause a bogus -ENODEV failure. Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
We accidentally mask by the _SHIFT variable. It means that "event" is always zero. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Tested-by: NJim Young <jamesx.m.young@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric Dumazet 提交于
We need to cancel the work queue after rcu grace period, otherwise it can be rescheduled by incoming packets. We need to purge queue if some skbs are still in it. We can use __skb_queue_head_init() variant in macvlan_process_broadcast() Signed-off-by: NEric Dumazet <edumazet@google.com> Fixes: 412ca155 ("macvlan: Move broadcasts into a work queue") Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Vrabel 提交于
If a frontend not receiving packets it is useful to detect this and turn off the carrier so packets are dropped early instead of being queued and drained when they expire. A to-guest queue is stalled if it doesn't have enough free slots for a an extended period of time (default 60 s). If at least one queue is stalled, the carrier is turned off (in the expectation that the other queues will soon stall as well). The carrier is only turned on once all queues are ready. When the frontend connects, all the queues start in the stalled state and only become ready once the frontend queues enough Rx requests. Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com> Reviewed-by: NWei Liu <wei.liu2@citrix.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Vrabel 提交于
Netback needs to discard old to-guest skb's (guest Rx queue drain) and it needs detect guest Rx stalls (to disable the carrier so packets are discarded earlier), but the current implementation is very broken. 1. The check in hard_start_xmit of the slot availability did not consider the number of packets that were already in the guest Rx queue. This could allow the queue to grow without bound. The guest stops consuming packets and the ring was allowed to fill leaving S slot free. Netback queues a packet requiring more than S slots (ensuring that the ring stays with S slots free). Netback queue indefinately packets provided that then require S or fewer slots. 2. The Rx stall detection is not triggered in this case since the (host) Tx queue is not stopped. 3. If the Tx queue is stopped and a guest Rx interrupt occurs, netback will consider this an Rx purge event which may result in it taking the carrier down unnecessarily. It also considers a queue with only 1 slot free as unstalled (even though the next packet might not fit in this). The internal guest Rx queue is limited by a byte length (to 512 Kib, enough for half the ring). The (host) Tx queue is stopped and started based on this limit. This sets an upper bound on the amount of memory used by packets on the internal queue. This allows the estimatation of the number of slots for an skb to be removed (it wasn't a very good estimate anyway). Instead, the guest Rx thread just waits for enough free slots for a maximum sized packet. skbs queued on the internal queue have an 'expires' time (set to the current time plus the drain timeout). The guest Rx thread will detect when the skb at the head of the queue has expired and discard expired skbs. This sets a clear upper bound on the length of time an skb can be queued for. For a guest being destroyed the maximum time needed to wait for all the packets it sent to be dropped is still the drain timeout (10 s) since it will not be sending new packets. Rx stall detection is reintroduced in a later commit. Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com> Reviewed-by: NWei Liu <wei.liu2@citrix.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Vrabel 提交于
Frontends that do not provide feature-rx-notify may stall because netback depends on the notification from frontend to wake the guest Rx thread (even if can_queue is false). This could be fixed but feature-rx-notify was introduced in 2006 and I am not aware of any frontends that do not implement this. Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com> Acked-by: NWei Liu <wei.liu2@citrix.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 10月, 2014 10 次提交
-
-
由 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>
-
由 Larry Finger 提交于
Drivers that do not use the get_btc_status() callback may not define a dummy routine. The caller needs to check before making the call. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com> Cc: Mike Galbraith <umgwanakikbuti@gmail.com> Cc: Thadeu Cascardo <cascardo@cascardo.eti.br> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-