- Dec 30, 2009
-
-
John W. Linville authored
This reverts commit 9bd568a5 . That commit is shown to cause allocation failures during initialization on some machines. http://bugzilla.kernel.org/show_bug.cgi?id=14844 Signed-off-by:
John W. Linville <linville@tuxdriver.com>
- Dec 29, 2009
-
-
Zhu Yi authored
Allocate priv->rx_packets[IWM_RX_ID_HASH + 1] because the max array index is IWM_RX_ID_HASH according to IWM_RX_ID_GET_HASH(). Cc: stable@kernel.org Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Roel Kluin authored
`loop' reaches INIT_LOOP + 1 after the loop. so if ACX_INTR_INIT_COMPLETE occurs in the last iteration the write occurs but also the error out as if a timeout occurred. This is probably very unlikely to ever occur. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Acked-by:
Kalle Valo <kalle.valo@nokia.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
mac80211 does not propagate failed hardware reconfiguration requests. For suspend and resume this is important due to all the possible issues that can come out of the suspend <-> resume cycle. Not propagating the error means cfg80211 will assume the resume for the device went through fine and mac80211 will continue on trying to poke at the hardware, enable timers, queue work, and so on for a device which is completley unfunctional. The least we can do is to propagate device start issues and warn when this occurs upon resume. A side effect of this patch is we also now propagate the start errors upon harware reconfigurations (non-suspend), but this should also be desirable anyway, there is not point in continuing to reconfigure a device if mac80211 was unable to start the device. For further details refer to the thread: http://marc.info/?t=126151038700001&r=1&w=2 Cc: stable@kernel.org Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
When mac80211 suspends it calls a driver's suspend callback as a last step and after that the driver assumes no calls will be made to it until we resume and its start callback is kicked. If such calls are made, however, suspend can end up throwing hardware in an unexpected state and making the device unusable upon resume. Fix this by preventing mac80211 to schedule dynamic_ps_disable_work by checking for when mac80211 starts to suspend and starts quiescing. Frames should be allowed to go through though as that is part of the quiescing steps and we do not flush the mac80211 workqueue since it was already done towards the beginning of suspend cycle. The other mac80211 issue will be hanled in the next patch. For further details see refer to the thread: http://marc.info/?t=126144866100001&r=1&w=2 Cc: stable@kernel.org Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
My previous change added in: commit 815833e7 ath9k: fix tx status reporting was not checking all possible tx error conditions. This could possibly lead to throughput issues due to slow rate control adaption or missed retransmissions of failed A-MPDU frames. This patch adds a mask for all possible error conditions and uses it in the xmit ok check. Cc: stable@kernel.org Reported-by:
Björn Smedman <bjorn.smedman@venatech.se> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
AMDPDU actions poke hardware for TX operation, as such we want to turn hardware on for these actions. AMDPU RX operations do not require hardware on as nothing is done in hardware for those actions. Without this we cannot guarantee hardware has been programmed correctly for each AMPDU TX action. Cc: stable@kernel.org Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
When we remove a IBSS/AP/Mesh interface we stop DMA but to do this we should ensure hardware is on. Awaken the device prior to these calls. This should ensure DMA is stopped upon suspend and plain device removal. Cc: stable@kernel.org Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Sujith authored
Ensure the device is awake prior to trying to tell hardware to stop it. Impact of not doing this is we can likely leave the device in an undefined state likely causing issues with suspend and resume. This patch ensures harware is where it should be prior to suspend. Cc: stable@kernel.org Signed-off-by:
Sujith <Sujith.Manoharan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
If there's an invalid channel or SSID, the code leaks the scan request. Always free the scan request, unless it was successfully given to the driver. Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
This is just a clean up and doesn't make a functional difference. It keeps the lint checkers happy. Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Kalle Valo <kalle.valo@nokia.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Tobias Klauser authored
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Acked-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Tobias Klauser authored
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Joseph Nahmias reported, in http://bugs.debian.org/562016, that he was getting the following warning (with some log around the issue): ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1) ath0: direct probe responded ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1) ath0: authenticated ath0: associate with AP 00:11:95:77:e0:b0 (try 1) ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3) ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1) ath0: RX AssocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2) ath0: associated ------------[ cut here ]------------ WARNING: at net/wireless/mlme.c:97 cfg80211_send_rx_assoc+0x14d/0x152 [cfg80211]() Hardware name: 7658CTO ... Pid: 761, comm: phy0 Not tainted 2.6.32-trunk-686 #1 Call Trace: [<c1030a5d>] ? warn_slowpath_common+0x5e/0x8a [<c1030a93>] ? warn_slowpath_null+0xa/0xc [<f86cafc7>] ? cfg80211_send_rx_assoc+0x14d/0x152 ... ath0: link becomes ready ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3) ath0: no IPv6 routers present ath0: link is not ready ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1) ath0: direct probe responded ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1) ath0: authenticated ath0: associate with AP 00:11:95:77:e0:b0 (try 1) ath0: RX ReassocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2) ath0: associated It is not clear to me how the first "direct probe" here happens, but this seems to be a race condition, if the user requests to deauth after requesting assoc, but before the assoc response is received. In that case, it may happen that mac80211 tries to report the assoc success to cfg80211, but gets blocked on the wdev lock that is held because the user is requesting the deauth. The result is that we run into a warning. This is mostly harmless, but maybe cause an unexpected event to be sent to userspace; we'd send an assoc success event although userspace was no longer expecting that. To fix this, remove the warning and check whether the race happened and in that case abort processing. Reported-by:
Joseph Nahmias <joe@nahmias.net> Cc: stable@kernel.org Cc: 562016-quiet@bugs.debian.org Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This removes the remaining users of the rx status 'qual' field and the field itself. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
This is a rt2870 based device. Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bob Copeland authored
The calibration period is now invoked by triggering a software interrupt from within the ISR by ath5k_hw_calibration_poll() instead of via a timer. However, the calibration interval isn't initialized before interrupts are enabled, so we can have a situation where an interrupt occurs before the interval is assigned, so the interval is actually negative. As a result, the ISR will arm a software interrupt to schedule the tasklet, and then rearm it when the SWI is processed, and so on, leading to a softlockup at modprobe time. Move the initialization order around so the calibration interval is set before interrupts are active. Another possible fix is to schedule the tasklet directly from the poll routine, but I think there are additional plans for the SWI. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When fixed bssid is requested when joining an ibss network, incoming beacons that match the configured bssid cause mac80211 to create new sta entries, even before the ibss interface is in joined state. When that happens, it fails to bring up the interface entirely, because it checks for existing sta entries before joining. This patch fixes this bug by refusing to create sta info entries before the interface is fully operational. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Samuel Ortiz authored
There is no reason to signal a carrier off when doing a 802.11 scan. Cc: Holger Schurig <holgerschurig@gmail.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Andrey Borzenkov authored
orinoco_set_key is called from two places both with interrupts disabled (under orinoco_lock). Use GFP_ATOMIC instead of GFP_KERNEL. Fixes following warning: [ 77.254109] WARNING: at /home/bor/src/linux-git/kernel/lockdep.c:2465 lockdep_trace_alloc+0x9a/0xa0() [ 77.254109] Hardware name: PORTEGE 4000 [ 77.254109] Modules linked in: af_packet irnet ppp_generic slhc ircomm_tty ircomm binfmt_misc dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath dm_mod loop nvram toshiba cryptomgr aead pcompress crypto_blkcipher michael_mic crypto_hash crypto_algapi orinoco_cs orinoco cfg80211 smsc_ircc2 pcmcia irda toshiba_acpi yenta_socket video i2c_ali1535 backlight rsrc_nonstatic ali_agp pcmcia_core psmouse output crc_ccitt i2c_core alim1535_wdt rfkill sg evdev ohci_hcd agpgart usbcore pata_ali libata reiserfs [last unloaded: scsi_wait_scan] [ 77.254109] Pid: 2296, comm: wpa_supplicant Not tainted 2.6.32-1avb #1 [ 77.254109] Call Trace: [ 77.254109] [<c011f0ad>] warn_slowpath_common+0x6d/0xa0 [ 77.254109] [<c014206a>] ? lockdep_trace_alloc+0x9a/0xa0 [ 77.254109] [<c014206a>] ? lockdep_trace_alloc+0x9a/0xa0 [ 77.254109] [<c011f0f5>] warn_slowpath_null+0x15/0x20 [ 77.254109] [<c014206a>] lockdep_trace_alloc+0x9a/0xa0 [ 77.254109] [<c018d296>] __kmalloc+0x36/0x130 [ 77.254109] [<dffcb6a8>] ? orinoco_set_key+0x48/0x1c0 [orinoco] [ 77.254109] [<dffcb6a8>] orinoco_set_key+0x48/0x1c0 [orinoco] [ 77.254109] [<dffcb9fc>] orinoco_ioctl_set_encodeext+0x1dc/0x2d0 [orinoco] [ 77.254109] [<c035b117>] ioctl_standard_call+0x207/0x3b0 [ 77.254109] [<dffcb820>] ? orinoco_ioctl_set_encodeext+0x0/0x2d0 [orinoco] [ 77.254109] [<c0307f1f>] ? rtnl_lock+0xf/0x20 [ 77.254109] [<c0307f1f>] ? rtnl_lock+0xf/0x20 [ 77.254109] [<c02fb115>] ? __dev_get_by_name+0x85/0xb0 [ 77.254109] [<c035b616>] wext_handle_ioctl+0x176/0x200 [ 77.254109] [<dffcb820>] ? orinoco_ioctl_set_encodeext+0x0/0x2d0 [orinoco] [ 77.254109] [<c030020f>] dev_ioctl+0x6af/0x730 [ 77.254109] [<c02eec65>] ? move_addr_to_kernel+0x55/0x60 [ 77.254109] [<c02eed59>] ? sys_sendto+0xe9/0x130 [ 77.254109] [<c02ed77e>] sock_ioctl+0x7e/0x250 [ 77.254109] [<c02ed700>] ? sock_ioctl+0x0/0x250 [ 77.254109] [<c019cf4c>] vfs_ioctl+0x1c/0x70 [ 77.254109] [<c019d1fa>] do_vfs_ioctl+0x6a/0x590 [ 77.254109] [<c0178e50>] ? might_fault+0x90/0xa0 [ 77.254109] [<c0178e0a>] ? might_fault+0x4a/0xa0 [ 77.254109] [<c02ef90e>] ? sys_socketcall+0x17e/0x280 [ 77.254109] [<c019d759>] sys_ioctl+0x39/0x60 [ 77.254109] [<c0102e3b>] sysenter_do_call+0x12/0x32 [ 77.254109] ---[ end trace 95ef563548d21efd ]--- Signed-off-by:
Andrey Borzenkov <arvidjaar@mail.ru> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- Dec 27, 2009
-
-
Ralf Baechle authored
Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> net/xfrm/xfrm_policy.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
A few lines earlier we assume that best->slave could be either null or non-null so we should check it here as well. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Drake authored
Commit f001fde5 changed net_device.dev_addr from a 32-byte array to a pointer. I found 4 ethernet drivers which rely on sizeof(dev_addr), which are now only copying 4 bytes of the address information on 32bit systems. Fix them to use ETH_ALEN. Signed-off-by:
Daniel Drake <dsd@laptop.org> Reviewed-by:
Jiri Pirko <jpirko@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sandeep Gopalpet authored
The gfar_select_queue() function was used to set queue mapping only for forwarding/bridging applications and the condition for locally generated packets was completely ignored. The solution is to remove the gfar_select_queue() function and use skb_record_rx_queue to set queue mapping for forwarding/bridging applications. This will ensure that in case of forwarding/bridging applications txq = rxq will be selected and skb_tx_hash will be used to pick up a txq for locally generated packets. Signed-off-by:
Sandeep Gopalpet <Sandeep.Kumar@freescale.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vitaliy Gusev authored
Using macro tun_sk is more clear and shorter. However tun.c has tun_sk, but doesn't use it. Signed-off-by:
Vitaliy Gusev <vgusev@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Anton Vorontsov authored
If PHY doesn't have an IRQ, phylib would poll for link changes, and would call adjust_link() every second. In that case we disable and enable the controller every second. Let's better check if there is actually anything changed, and, if so, change the MAC settings. Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Anton Vorontsov authored
Since commit 864fdf88 ("ucc_geth: Fix hangs after switching from full to half duplex") ucc_geth driver disables the controller during MAC configuration changes. Though, disabling the controller might take quite awhile, and so the netdev watchdog might get upset: NETDEV WATCHDOG: eth2 (ucc_geth): transmit queue 0 timed out ------------[ cut here ]------------ Badness at c02729a8 [verbose debug info unavailable] NIP: c02729a8 LR: c02729a8 CTR: c01b6088 REGS: c0451c40 TRAP: 0700 Not tainted (2.6.32-trunk-8360e) [...] NIP [c02729a8] dev_watchdog+0x280/0x290 LR [c02729a8] dev_watchdog+0x280/0x290 Call Trace: [c0451cf0] [c02729a8] dev_watchdog+0x280/0x290 (unreliable) [c0451d50] [c00377c4] run_timer_softirq+0x164/0x224 [c0451da0] [c0032a38] __do_softirq+0xb8/0x13c [c0451df0] [c00065cc] do_softirq+0xa0/0xac [c0451e00] [c003280c] irq_exit+0x7c/0x9c [c0451e10] [c00640c4] __ipipe_sync_stage+0x248/0x24c [...] This patch fixes the issue by detaching the netdev during the time we change the configuration. Reported-by:
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Tested-by:
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Cc: Stable <stable@vger.kernel.org> [2.6.32] Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Anton Vorontsov authored
Following oops was seen with the ucc_geth driver: Unable to handle kernel paging request for data at address 0x00000058 Faulting instruction address: 0xc024f2fc Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c024f2fc] skb_recycle_check+0x14/0x100 LR [e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver] Call Trace: [df857d50] [c000b03c] __ipipe_grab_irq+0x3c/0xa4 (unreliable) [df857d60] [e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver] [df857dd0] [c0258cf8] net_rx_action+0xf8/0x1b8 [df857e10] [c0032a38] __do_softirq+0xb8/0x13c [df857e60] [c00065cc] do_softirq+0xa0/0xac [...] This is because ucc_geth_tx() tries to process an empty queue when queues are logically stopped. Stopping the queues doesn't disable polling, and since nowadays ucc_geth_tx() is actually called from the polling routine, the oops above might pop up. Fix this by removing 'netif_queue_stopped() == 0' check. Reported-by:
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Tested-by:
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Cc: Stable <stable@vger.kernel.org> [2.6.32] Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Dec 26, 2009
-
-
Denis Kirjanov authored
Use DMA_BIT_MASK instead of plain values. Signed-off-by:
Denis Kirjanov <kirjanov@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jamal Hadi Salim authored
when using policy routing and the skb mark: there are cases where a back path validation requires us to use a different routing table for src ip validation than the one used for mapping ingress dst ip. One such a case is transparent proxying where we pretend to be the destination system and therefore the local table is used for incoming packets but possibly a main table would be used on outbound. Make the default behavior to allow the above and if users need to turn on the symmetry via sysctl src_valid_mark Signed-off-by:
Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Chan authored
When the device is reset during MTU change, ring size change, or self test, etc, the cnic status block needs to be properly initialized if cnic is registered. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
Eilon Greenstein <eilong@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Dec 24, 2009
-
-
John Fastabend authored
This updates pktgen so that it does not decrement skb->users when it receives valid NET_XMIT_xxx values. These are now valid return values from ndo_start_xmit in net-next-2.6. They also indicate the skb has been consumed. This fixes pktgen to work correctly with vlan devices. Signed-off-by:
John Fastabend <john.r.fastabend@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jarek Poplawski authored
There are BUGs "scheduling while atomic" triggered by the timer rhine_tx_timeout(). They are caused by calling napi_disable() (with msleep()). This patch fixes it by moving most of the timer content to the workqueue function (similarly to other drivers, like tg3), with spin_lock() changed to BH version. Additionally, there is spin_lock_irq() moved in rhine_close() to exclude napi_disable() etc., also tg3's way. Reported-by:
Andrey Rahmatullin <wrar@altlinux.org> Tested-by:
Andrey Rahmatullin <wrar@altlinux.org> Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Don Skidmore authored
This patch adds a pci_save_state() call in ixgbe_resume() after pci_restore_state(). A similar change was made in ixgbe_io_slot_reset() that accommodates pci_restore_state() new behavior. This change makes pci_restore_state() clear the saved_state flag This is necessary due to a resent kernel change to pci_restore_state() so that it now clears the saved_state flag of the device right after the device.s standard configuration registers have been poplulated with the previously saved values. Signed-off-by:
Don Skidmore <donald.c.skidmore@intel.com> Acked-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sarveshwar Bandi authored
Changes to return correct values for transceiver and supported in ethtool get_settings function. Signed-off-by:
Sarveshwar Bandi <sarveshwarb@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sarveshwar Bandi authored
NIC controller has to be set to an appropriate mode before doing a loopback test. Test will fail otherwise. Signed-off-by:
Sarveshwar Bandi <sarveshwarb@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sarveshwar Bandi authored
This change ensures that loopback test command gives up after 4 seconds when the hardware is not responsive. This could happen if the ports are connected properly in loopback mode. Signed-off-by:
Sarveshwar Bandi <sarveshwarb@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Williams, Mitch A authored
Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
The ethtool code for enabling Wake on Lan was not correctly checking the status register bits so as a result ports 0 and 2 were both being allowed to set WOL to enabled even though it is only supported on the first port for our adapters. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-