summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/intel
AgeCommit message (Collapse)AuthorFilesLines
2020-01-27ixgbe: sync the first fragment unconditionallyFiro Yang1-7/+9
[ Upstream commit e7ba676c6188d394a0133fc4b9bcd7ee50d54b7f ] In Xen environment, if Xen-swiotlb is enabled, ixgbe driver could possibly allocate a page, DMA memory buffer, for the first fragment which is not suitable for Xen-swiotlb to do DMA operations. Xen-swiotlb have to internally allocate another page for doing DMA operations. This mechanism requires syncing the data from the internal page to the page which ixgbe sends to upper network stack. However, since commit f3213d932173 ("ixgbe: Update driver to make use of DMA attributes in Rx path"), the unmap operation is performed with DMA_ATTR_SKIP_CPU_SYNC. As a result, the sync is not performed. Since the sync isn't performed, the upper network stack could receive a incomplete network packet. By incomplete, it means the linear data on the first fragment(between skb->head and skb->end) is invalid. So we have to copy the data from the internal xen-swiotlb page to the page which ixgbe sends to upper network stack through the sync operation. More details from Alexander Duyck: Specifically since we are mapping the frame with DMA_ATTR_SKIP_CPU_SYNC we have to unmap with that as well. As a result a sync is not performed on an unmap and must be done manually as we skipped it for the first frag. As such we need to always sync before possibly performing a page unmap operation. Fixes: f3213d932173 ("ixgbe: Update driver to make use of DMA attributes in Rx path") Signed-off-by: Firo Yang <firo.yang@suse.com> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27i40e: reduce stack usage in i40e_set_fcArnd Bergmann1-40/+51
[ Upstream commit 33b165684ab70867d4545643f550a5d48d3ddc57 ] The functions i40e_aq_get_phy_abilities_resp() and i40e_set_fc() both have giant structure on the stack, which makes each one use stack frames larger than 500 bytes. As clang decides one function into the other, we get a warning for exceeding the frame size limit on 32-bit architectures: drivers/net/ethernet/intel/i40e/i40e_common.c:1654:23: error: stack frame size of 1116 bytes in function 'i40e_set_fc' [-Werror,-Wframe-larger-than=] When building with gcc, the inlining does not happen, but i40e_set_fc() calls i40e_aq_get_phy_abilities_resp() anyway, so they add up on the kernel stack just as much. The parts that actually use large stacks don't overlap, so make sure each one is a separate function, and mark them as noinline_for_stack to prevent the compilers from combining them again. Fixes: 0a862b43acc6 ("i40e/i40evf: Add module_types and update_link_info") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27ixgbe: don't clear IPsec sa counters on HW clearingShannon Nelson1-4/+0
[ Upstream commit 9e3f2f5ecee69b0f70003fb3e07639151e91de73 ] The software SA record counters should not be cleared when clearing the hardware tables. This causes the counters to be out of sync after a driver reset. Fixes: 63a67fe229ea ("ixgbe: add ipsec offload add and remove SA") Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31ice: delay lessMitch Williams2-3/+4
[ Upstream commit 88bb432a55de8ae62106305083a8bfbb23b01ad2 ] Shorten the delay for SQ responses, but increase the number of loops. Max delay time is unchanged, but some operations complete much more quickly. In the process, add a new define to make the delay count and delay time more explicit. Add comments to make things more explicit. This fixes a problem with VF resets failing on with many VFs. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31ixgbe: protect TX timestamping from API misuseManjunath Patil1-1/+2
[ Upstream commit 07066d9dc3d2326fbad8f7b0cb0120cff7b7dedb ] HW timestamping can only be requested for a packet if the NIC is first setup via ioctl(SIOCSHWTSTAMP). If this step was skipped, then the ixgbe driver still allowed TX packets to request HW timestamping. In this situation, we see 'clearing Tx Timestamp hang' noise in the log. Fix this by checking that the NIC is configured for HW TX timestamping before accepting a HW TX timestamping request. Similar-to: commit 26bd4e2db06b ("igb: protect TX timestamping from API misuse") commit 0a6f2f05a2f5 ("igb: Fix a test with HWTSTAMP_TX_ON") Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31i40e: initialize ITRN registers with correct valuesNicholas Nunley1-5/+5
[ Upstream commit 998e5166e604fd37afe94352f7b8c2d816b11049 ] Since commit 92418fb14750 ("i40e/i40evf: Use usec value instead of reg value for ITR defines") the driver tracks the interrupt throttling intervals in single usec units, although the actual ITRN/ITR0 registers are programmed in 2 usec units. Most register programming flows in the driver correctly handle the conversion, although it is currently not applied when the registers are initialized to their default values. Most of the time this doesn't present a problem since the default values are usually immediately overwritten through the standard adaptive throttling mechanism, or updated manually by the user, but if adaptive throttling is disabled and the interval values are left alone then the incorrect value will persist. Since the intended default interval of 50 usecs (vs. 100 usecs as programmed) performs better for most traffic workloads, this can lead to performance regressions. This patch adds the correct conversion when writing the initial values to the ITRN registers. Signed-off-by: Nicholas Nunley <nicholas.d.nunley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-17e100: Fix passing zero to 'PTR_ERR' warning in e100_load_ucode_waitYueHaibing1-2/+2
[ Upstream commit cd0d465bb697a9c7bf66a9fe940f7981232f1676 ] Fix a static code checker warning: drivers/net/ethernet/intel/e100.c:1349 e100_load_ucode_wait() warn: passing zero to 'PTR_ERR' Signed-off-by: YueHaibing <yuehaibing@huawei.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13ice: Fix possible NULL pointer de-referenceBruce Allan1-0/+3
[ Upstream commit f25dad19ba70f7cc135da78ec013325042cd8c52 ] A recent update to smatch is causing it to report the error "we previously assumed 'm_entry->vsi_list_info' could be null". Fix that. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13ice: Fix return value from NAPI pollDave Ertman1-1/+2
[ Upstream commit e0c9fd9b77a7334032ec407d9e14d7c3cac1ac4f ] ice_napi_poll is hard-coded to return zero when it's done. It should instead return the work done (if any work was done). The only time it should return zero is if an interrupt or poll is handled and no work is performed. So change the return value to be the minimum of work done or budget-1. Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13i40e: don't restart nway if autoneg not supportedMitch Williams1-5/+5
[ Upstream commit 7c3758f7839377ab67529cc50264a640636c47af ] On link types that do not support autoneg, we cannot attempt to restart nway negotiation. This results in a dead link that requires a power cycle to remedy. Fix this by saving off the autoneg state and checking this value before we try to restart nway. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13ice: Fix NVM mask definesLev Faerman1-3/+3
[ Upstream commit 6263e811f4d4418660c20b36a08063c6d2c3fb9d ] Fixes bad masks that would break compilation when evaluated. Signed-off-by: Lev Faerman <lev.faerman@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-01fm10k: ensure completer aborts are marked as non-fatal after a resumeJacob Keller1-20/+28
[ Upstream commit e330af788998b0de4da4f5bd7ddd087507999800 ] VF drivers can trigger PCIe completer aborts any time they read a queue that they don't own. Even in nominal circumstances, it is not possible to prevent the VF driver from reading queues it doesn't own. VF drivers may attempt to read queues it previously owned, but which it no longer does due to a PF reset. Normally these completer aborts aren't an issue. However, on some platforms these trigger machine check errors. This is true even if we lower their severity from fatal to non-fatal. Indeed, we already have code for lowering the severity. We could attempt to mask these errors conditionally around resets, which is the most common time they would occur. However this would essentially be a race between the PF and VF drivers, and we may still occasionally see machine check exceptions on these strictly configured platforms. Instead, mask the errors entirely any time we resume VFs. By doing so, we prevent the completer aborts from being sent to the parent PCIe device, and thus these strict platforms will not upgrade them into machine check errors. Additionally, we don't lose any information by masking these errors, because we'll still report VFs which attempt to access queues via the FUM_BAD_VF_QACCESS errors. Without this change, on platforms where completer aborts cause machine check exceptions, the VF reading queues it doesn't own could crash the host system. Masking the completer abort prevents this, so we should mask it for good, and not just around a PCIe reset. Otherwise malicious or misconfigured VFs could cause the host system to crash. Because we are masking the error entirely, there is little reason to also keep setting the severity bit, so that code is also removed. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-01igb: shorten maximum PHC timecounter update intervalMiroslav Lichvar1-1/+7
[ Upstream commit 094bf4d0e9657f6ea1ee3d7e07ce3970796949ce ] The timecounter needs to be updated at least once per ~550 seconds in order to avoid a 40-bit SYSTIM timestamp to be misinterpreted as an old timestamp. Since commit 500462a9d ("timers: Switch to a non-cascading wheel"), scheduling of delayed work seems to be less accurate and a requested delay of 540 seconds may actually be longer than 550 seconds. Shorten the delay to 480 seconds to be sure the timecounter is updated in time. This fixes an issue with HW timestamps on 82580/I350/I354 being off by ~1100 seconds for few seconds every ~9 minutes. Cc: Jacob Keller <jacob.e.keller@intel.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24ixgbe: Fix crash with VFs and flow director on interface flapRadoslaw Tyl1-2/+8
[ Upstream commit 5d826d209164b0752c883607be4cdbbcf7cab494 ] This patch fix crash when we have restore flow director filters after reset adapter. In ixgbe_fdir_filter_restore() filter->action is outside of the rx_ring array, as it has a VF identifier in the upper 32 bits. Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24i40e: Use proper enum in i40e_ndo_set_vf_link_stateNathan Chancellor1-1/+1
[ Upstream commit 43ade6ad18416b8fd5bb3c9e9789faa666527eec ] Clang warns when one enumerated type is converted implicitly to another. drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4214:42: warning: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Wenum-conversion] pfe.event_data.link_event.link_speed = I40E_LINK_SPEED_40GB; ~ ^~~~~~~~~~~~~~~~~~~~ 1 warning generated. Use the proper enum from virtchnl_link_speed, which has the same value as I40E_LINK_SPEED_40GB, VIRTCHNL_LINK_SPEED_40GB. This appears to be missed by commit ff3f4cc267f6 ("virtchnl: finish conversion to virtchnl interface"). Link: https://github.com/ClangBuiltLinux/linux/issues/81 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24ixgbe: Fix ixgbe TX hangs with XDP_TX beyond queue limitRadoslaw Tyl1-4/+10
[ Upstream commit 8d7179b1e2d64b3493c0114916486fe92e6109a9 ] We have Tx hang when number Tx and XDP queues are more than 64. In XDP always is MTQC == 0x0 (64TxQs). We need more space for Tx queues. Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24ice: Fix forward to queue group logicAnirudh Venkataramanan1-4/+10
[ Upstream commit be8ff000bf83e658e63ab64cf4d2755abc5add5b ] When adding a rule, queue region size needs to be provided as log base 2 of the number of queues in region. Fix that. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20i40e: Prevent deleting MAC address from VF when set by PFPatryk Małek1-0/+10
[ Upstream commit 5907cf6c5bbe78be2ed18b875b316c6028b20634 ] To prevent VF from deleting MAC address that was assigned by the PF we need to check for that scenario when we try to delete a MAC address from a VF. Signed-off-by: Patryk Małek <patryk.malek@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20i40evf: cancel workqueue sync for adminq when a VF is removedLihong Yang1-0/+2
[ Upstream commit babbcc60040abfb7a9e3caa1c58fe182ae73762a ] If a VF is being removed, there is no need to continue with the workqueue sync for the adminq task, thus cancel it. Without this call, when VFs are created and removed right away, there might be a chance for the driver to crash with events stuck in the adminq. Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20i40e: hold the rtnl lock on clearing interrupt schemePatryk Małek1-0/+8
[ Upstream commit 5cba17b14182696d6bb0ec83a1d087933f252241 ] Hold the rtnl lock when we're clearing interrupt scheme in i40e_shutdown and in i40e_remove. Signed-off-by: Patryk Małek <patryk.malek@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20i40evf: Don't enable vlan stripping when rx offload is turned onPatryk Małek1-5/+6
[ Upstream commit 3bd77e2ae1477d6f87fc3f542c737119d5decf9f ] With current implementation of i40evf_set_features when user sets any offload via ethtool we set I40EVF_FLAG_AQ_ENABLE_VLAN_STRIPPING as a required aq which triggers driver to call i40evf_enable_vlan_stripping. This shouldn't take place. This patches fixes it by setting the flag only when VLAN offload is turned on. Signed-off-by: Patryk Małek <patryk.malek@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20i40e: Check and correct speed values for link on openJan Sokolowski1-3/+24
[ Upstream commit e78d9a39fd06109022d11c8ca444cfcec2abb290 ] If our card has been put in an unstable state due to other drivers interacting with it, speed settings might be incorrect. If incorrect, forcefully reset them on open to known default values. Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20i40evf: set IFF_UNICAST_FLT flag for the VFLihong Yang1-0/+2
[ Upstream commit e65aae086330d0a6c6c9f874aef03c69cf98884b ] Set IFF_UNICAST_FLT flag for the VF to prevent it from entering promiscuous mode when macvlan is added to the VF. Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20i40e: use correct length for strncpyMitch Williams1-1/+2
[ Upstream commit 7eb74ff891b4e94b8bac48f648a21e4b94ddee64 ] Caught by GCC 8. When we provide a length for strncpy, we should not include the terminating null. So we must tell it one less than the size of the destination buffer. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20i40evf: Validate the number of queues a PF sendsPaul M Stillwell Jr1-0/+32
[ Upstream commit 3c818910911c93bb5099c6637ec350f90c0e71fc ] A PF can send any number of queues to the VF and the VF may not be able to support that many. Check to see that the number of queues is less than or equal to the max number of queues the VF can have. Signed-off-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20ice: Fix and update driver version stringAnirudh Venkataramanan1-1/+1
[ Upstream commit 9ea47d81a7f17c6b77211ab75fbca2127719ad39 ] Remove the "ice" prefix for the driver version string and bump version to 0.7.1-k. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20ice: Prevent control queue operations during resetAnirudh Venkataramanan4-5/+34
[ Upstream commit fd2a981777d911b2e94cdec50779c85c58a0dec9 ] Once reset is issued, the driver loses all control queue interfaces. Exercising control queue operations during reset is incorrect and may result in long timeouts. This patch introduces a new field 'reset_ongoing' in the hw structure. This is set to 1 by the core driver when it receives a reset interrupt. ice_sq_send_cmd checks reset_ongoing before actually issuing the control queue operation. If a reset is in progress, it returns a soft error code (ICE_ERR_RESET_PENDING) to the caller. The caller may or may not have to take any action based on this return. Once the driver knows that the reset is done, it has to set reset_ongoing back to 0. This will allow control queue operations to be posted to the hardware again. This "bail out" logic was specifically added to ice_sq_send_cmd (which is pretty low level function) so that we have one solution in one place that applies to all types of control queues. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20ice: Update request resource command to latest specificationDan Nowlin4-21/+67
[ Upstream commit ff2b13213a6a0baca105bc3bc724225f0adde1f8 ] Align Request Resource Ownership AQ command (0x0008) to the latest specification. This includes: - Correcting the resource IDs for the Global Cfg and Change locks. - new enum ICE_CHANGE_LOCK_RES_ID - new enum ICE_GLOBAL_CFG_LOCK_RES_ID - Altering the flow for Global Config Lock to allow only the first PF to download the package. Signed-off-by: Dan Nowlin <dan.nowlin@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-12e1000: fix memory leaksWenwen Wang1-4/+3
[ Upstream commit 8472ba62154058b64ebb83d5f57259a352d28697 ] In e1000_set_ringparam(), 'tx_old' and 'rx_old' are not deallocated if e1000_up() fails, leading to memory leaks. Refactor the code to fix this issue. Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-12igb: Fix constant media auto sense switching when no cable is connectedManfred Rudigier1-1/+2
[ Upstream commit 8d5cfd7f76a2414e23c74bb8858af7540365d985 ] At least on the i350 there is an annoying behavior that is maybe also present on 82580 devices, but was probably not noticed yet as MAS is not widely used. If no cable is connected on both fiber/copper ports the media auto sense code will constantly swap between them as part of the watchdog task and produce many unnecessary kernel log messages. The swap code responsible for this behavior (switching to fiber) should not be executed if the current media type is copper and there is no signal detected on the fiber port. In this case we can safely wait until the AUTOSENSE_EN bit is cleared. Signed-off-by: Manfred Rudigier <manfred.rudigier@omicronenergy.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-05i40e: check __I40E_VF_DISABLE bit in i40e_sync_filters_subtaskStefan Assmann1-0/+5
commit a7542b87607560d0b89e7ff81d870bd6ff8835cb upstream. While testing VF spawn/destroy the following panic occurred. BUG: unable to handle kernel NULL pointer dereference at 0000000000000029 [...] Workqueue: i40e i40e_service_task [i40e] RIP: 0010:i40e_sync_vsi_filters+0x6fd/0xc60 [i40e] [...] Call Trace: ? __switch_to_asm+0x35/0x70 ? __switch_to_asm+0x41/0x70 ? __switch_to_asm+0x35/0x70 ? _cond_resched+0x15/0x30 i40e_sync_filters_subtask+0x56/0x70 [i40e] i40e_service_task+0x382/0x11b0 [i40e] ? __switch_to_asm+0x41/0x70 ? __switch_to_asm+0x41/0x70 process_one_work+0x1a7/0x3b0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthread_bind+0x30/0x30 ret_from_fork+0x35/0x40 Investigation revealed a race where pf->vf[vsi->vf_id].trusted may get accessed by the watchdog via i40e_sync_filters_subtask() although i40e_free_vfs() already free'd pf->vf. To avoid this the call to i40e_sync_vsi_filters() in i40e_sync_filters_subtask() needs to be guarded by __I40E_VF_DISABLE, which is also used by i40e_free_vfs(). Note: put the __I40E_VF_DISABLE check after the __I40E_MACVLAN_SYNC_PENDING check as the latter is more likely to trigger. CC: stable@vger.kernel.org Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-05e1000e: add workaround for possible stalled packetKai-Heng Feng2-1/+11
[ Upstream commit e5e9a2ecfe780975820e157b922edee715710b66 ] This works around a possible stalled packet issue, which may occur due to clock recovery from the PCH being too slow, when the LAN is transitioning from K1 at 1G link speed. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-19ixgbe: Prevent u8 wrapping of ITR value to something less than 10usAlexander Duyck1-1/+3
commit 377228accbbb8b9738f615d791aa803f41c067e0 upstream. There were a couple cases where the ITR value generated via the adaptive ITR scheme could exceed 126. This resulted in the value becoming either 0 or something less than 10. Switching back and forth between a value less than 10 and a value greater than 10 can cause issues as certain hardware features such as RSC to not function well when the ITR value has dropped that low. CC: stable@vger.kernel.org Fixes: b4ded8327fea ("ixgbe: Update adaptive ITR algorithm") Reported-by: Gregg Leventhal <gleventhal@janestreet.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-19ixgbe: Fix secpath usage for IPsec TX offload.Steffen Klassert1-1/+3
[ Upstream commit f39b683d35dfa93a58f1b400a8ec0ff81296b37c ] The ixgbe driver currently does IPsec TX offloading based on an existing secpath. However, the secpath can also come from the RX side, in this case it is misinterpreted for TX offload and the packets are dropped with a "bad sa_idx" error. Fix this by using the xfrm_offload() function to test for TX offload. Fixes: 592594704761 ("ixgbe: process the Tx ipsec offload") Reported-by: Michael Marley <michael@michaelmarley.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-26iavf: fix dereference of null rx_buffer pointerColin Ian King1-2/+4
[ Upstream commit 9fe06a51287b2d41baef7ece94df34b5abf19b90 ] A recent commit efa14c3985828d ("iavf: allow null RX descriptors") added a null pointer sanity check on rx_buffer, however, rx_buffer is being dereferenced before that check, which implies a null pointer dereference bug can potentially occur. Fix this by only dereferencing rx_buffer until after the null pointer check. Addresses-Coverity: ("Dereference before null check") Signed-off-by: Colin Ian King <colin.king@canonical.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-26igb: clear out skb->tstamp after reading the txtimeVedang Patel1-0/+1
[ Upstream commit 1e08511d5d01884a3c9070afd52a47799312074a ] If a packet which is utilizing the launchtime feature (via SO_TXTIME socket option) also requests the hardware transmit timestamp, the hardware timestamp is not delivered to the userspace. This is because the value in skb->tstamp is mistaken as the software timestamp. Applications, like ptp4l, request a hardware timestamp by setting the SOF_TIMESTAMPING_TX_HARDWARE socket option. Whenever a new timestamp is detected by the driver (this work is done in igb_ptp_tx_work() which calls igb_ptp_tx_hwtstamps() in igb_ptp.c[1]), it will queue the timestamp in the ERR_QUEUE for the userspace to read. When the userspace is ready, it will issue a recvmsg() call to collect this timestamp. The problem is in this recvmsg() call. If the skb->tstamp is not cleared out, it will be interpreted as a software timestamp and the hardware tx timestamp will not be successfully sent to the userspace. Look at skb_is_swtx_tstamp() and the callee function __sock_recv_timestamp() in net/socket.c for more details. Signed-off-by: Vedang Patel <vedang.patel@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-26ixgbe: Check DDM existence in transceiver before accessMauro S. M. Rodrigues2-1/+3
[ Upstream commit 655c91414579d7bb115a4f7898ee726fc18e0984 ] Some transceivers may comply with SFF-8472 but not implement the Digital Diagnostic Monitoring (DDM) interface described in it. The existence of such area is specified by bit 6 of byte 92, set to 1 if implemented. Currently, due to not checking this bit ixgbe fails trying to read SFP module's eeprom with the follow message: ethtool -m enP51p1s0f0 Cannot get Module EEPROM data: Input/output error Because it fails to read the additional 256 bytes in which it was assumed to exist the DDM data. This issue was noticed using a Mellanox Passive DAC PN 01FT738. The eeprom data was confirmed by Mellanox as correct and present in other Passive DACs in from other manufacturers. Signed-off-by: "Mauro S. M. Rodrigues" <maurosr@linux.vnet.ibm.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-21e1000e: start network tx queue only when link is upKonstantin Khlebnikov1-2/+4
commit d17ba0f616a08f597d9348c372d89b8c0405ccf3 upstream. Driver does not want to keep packets in Tx queue when link is lost. But present code only reset NIC to flush them, but does not prevent queuing new packets. Moreover reset sequence itself could generate new packets via netconsole and NIC falls into endless reset loop. This patch wakes Tx queue only when NIC is ready to send packets. This is proper fix for problem addressed by commit 0f9e980bf5ee ("e1000e: fix cyclic resets at link up with active tx"). Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Suggested-by: Alexander Duyck <alexander.duyck@gmail.com> Tested-by: Joseph Yasi <joe.yasi@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Tested-by: Oleksandr Natalenko <oleksandr@redhat.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-21Revert "e1000e: fix cyclic resets at link up with active tx"Konstantin Khlebnikov1-6/+9
commit caff422ea81e144842bc44bab408d85ac449377b upstream. This reverts commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61. That change cased false-positive warning about hardware hang: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang: TDH <0> TDT <1> next_to_use <1> next_to_clean <0> buffer_info[next_to_clean]: time_stamp <fffba7a7> next_to_watch <0> jiffies <fffbb140> next_to_watch.status <0> MAC Status <40080080> PHY Status <7949> PHY 1000BASE-T Status <0> PHY Extended Status <3000> PCI Status <10> e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Besides warning everything works fine. Original issue will be fixed property in following patch. Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Reported-by: Joseph Yasi <joe.yasi@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203175 Tested-by: Joseph Yasi <joe.yasi@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Tested-by: Oleksandr Natalenko <oleksandr@redhat.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-15ice: Add missing case in print_link_msg for printing flow controlBrett Creeley1-0/+3
[ Upstream commit 203a068ac9e2722e4d118116acaa3a5586f9468a ] Currently we aren't checking for the ICE_FC_NONE case for the current flow control mode. This is causing "Unknown" to be printed for the current flow control method if flow control is disabled. Fix this by adding the case for ICE_FC_NONE to print "None". Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-06-15i40e: Queues are reserved despite "Invalid argument" errorAdam Ludkiewicz1-0/+3
[ Upstream commit 3e957b377bf4262aec2dd424f28ece94e36814d4 ] Added a new local variable in the i40e_setup_tc function named old_queue_pairs so num_queue_pairs can be restored to the correct value in case configuring queue channels fails. Additionally, moved the exit label in the i40e_setup_tc function so the if (need_reset) block can be executed. Also, fixed data packing in the i40e_setup_tc function. Signed-off-by: Adam Ludkiewicz <adam.ludkiewicz@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31igb: Exclude device from suspend direct complete optimizationKai-Heng Feng1-0/+3
[ Upstream commit 5b6e13216be29ced7350d9c354a1af8fe0ad9a3e ] igb sets different WoL settings in system suspend callback and runtime suspend callback. The suspend direct complete optimization leaves igb in runtime suspended state with wrong WoL setting during system suspend. To fix this, we need to disable suspend direct complete optimization to let igb always use suspend callback to set correct WoL during system suspend. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31e1000e: Disable runtime PM on CNP+Kai-Heng Feng1-1/+1
[ Upstream commit 459d69c407f9ba122f12216555c3012284dc9fd7 ] There are some new e1000e devices can only be woken up from D3 one time, by plugging Ethernet cable. Subsequent cable plugging does set PME bit correctly, but it still doesn't get woken up. Since e1000e connects to the root complex directly, we rely on ACPI to wake it up. In this case, the GPE from _PRW only works once and stops working after that. Though it appears to be a platform bug, e1000e maintainers confirmed that I219 does not support D3. So disable runtime PM on CNP+ chips. We may need to disable earlier generations if this bug also hit older platforms. Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=280819 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31i40e: don't allow changes to HW VLAN stripping on active port VLANsNicholas Nunley1-0/+8
[ Upstream commit bfb0ebed53857cfc57f11c63fa3689940d71c1c8 ] Modifying the VLAN stripping options when a port VLAN is configured will break traffic for the VSI, and conceptually doesn't make sense, so don't allow this. Signed-off-by: Nicholas Nunley <nicholas.d.nunley@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31i40e: Able to add up to 16 MAC filters on an untrusted VFAdam Ludkiewicz1-2/+4
[ Upstream commit 06b6e2a2333eb3581567a7ac43ca465ef45f4daa ] This patch fixes the problem with the driver being able to add only 7 multicast MAC address filters instead of 16. The problem is fixed by changing the maximum number of MAC address filters to 16+1+1 (two extra are needed because the driver uses 1 for unicast MAC address and 1 for broadcast). Signed-off-by: Adam Ludkiewicz <adam.ludkiewicz@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-08igb: Fix WARN_ONCE on runtime suspendArvind Sankar2-49/+10
[ Upstream commit dabb8338be533c18f50255cf39ff4f66d4dabdbe ] The runtime_suspend device callbacks are not supposed to save configuration state or change the power state. Commit fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend") changed the driver to not save configuration state during runtime suspend, however the driver callback still put the device into a low-power state. This causes a warning in the pci pm core and results in pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend. Fix this by not changing the power state either, leaving that to pci pm core, and make the same change for suspend callback as well. Also move a couple of defines into the appropriate header file instead of inline in the .c file. Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend") Signed-off-by: Arvind Sankar <niveditas98@gmail.com> Reviewed-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-02fm10k: Fix a potential NULL pointer dereferenceYue Haibing1-0/+2
commit 01ca667133d019edc9f0a1f70a272447c84ec41f upstream. Syzkaller report this: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 4378 Comm: syz-executor.0 Tainted: G C 5.0.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:__lock_acquire+0x95b/0x3200 kernel/locking/lockdep.c:3573 Code: 00 0f 85 28 1e 00 00 48 81 c4 08 01 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 24 00 00 49 81 7d 00 e0 de 03 a6 41 bc 00 00 RSP: 0018:ffff8881e3c07a40 EFLAGS: 00010002 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000080 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8881e3c07d98 R11: ffff8881c7f21f80 R12: 0000000000000001 R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001 FS: 00007fce2252e700(0000) GS:ffff8881f2400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fffc7eb0228 CR3: 00000001e5bea002 CR4: 00000000007606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: lock_acquire+0xff/0x2c0 kernel/locking/lockdep.c:4211 __mutex_lock_common kernel/locking/mutex.c:925 [inline] __mutex_lock+0xdf/0x1050 kernel/locking/mutex.c:1072 drain_workqueue+0x24/0x3f0 kernel/workqueue.c:2934 destroy_workqueue+0x23/0x630 kernel/workqueue.c:4319 __do_sys_delete_module kernel/module.c:1018 [inline] __se_sys_delete_module kernel/module.c:961 [inline] __x64_sys_delete_module+0x30c/0x480 kernel/module.c:961 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fce2252dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000140 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fce2252e6bc R13: 00000000004bcca9 R14: 00000000006f6b48 R15: 00000000ffffffff If alloc_workqueue fails, it should return -ENOMEM, otherwise may trigger this NULL pointer dereference while unloading drivers. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 0a38c17a21a0 ("fm10k: Remove create_workqueue") Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-05e1000e: Exclude device from suspend direct complete optimizationKai-Heng Feng1-0/+2
[ Upstream commit 59f58708c5047289589cbf6ee95146b76cf57d1e ] e1000e sets different WoL settings in system suspend callback and runtime suspend callback. The suspend direct complete optimization leaves e1000e in runtime suspended state with wrong WoL setting during system suspend. To fix this, we need to disable suspend direct complete optimization to let e1000e always use suspend callback to set correct WoL during system suspend. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05e1000e: fix cyclic resets at link up with active txKonstantin Khlebnikov1-9/+6
[ Upstream commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61 ] I'm seeing series of e1000e resets (sometimes endless) at system boot if something generates tx traffic at this time. In my case this is netconsole who sends message "e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames" from e1000e itself. As result e1000_watchdog_task sees used tx buffer while carrier is off and start this reset cycle again. [ 17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 22.936455] e1000e 0000:02:00.0 eth1: changing MTU from 1500 to 9000 [ 23.033336] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 27.174495] 8021q: 802.1Q VLAN Support v1.8 [ 27.174513] 8021q: adding VLAN 0 to HW filter on device eth1 [ 30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation [ 30.898564] netpoll: netconsole: local port 6666 [ 30.898566] netpoll: netconsole: local IPv6 address 2a02:6b8:0:80b:beae:c5ff:fe28:23f8 [ 30.898567] netpoll: netconsole: interface 'eth1' [ 30.898568] netpoll: netconsole: remote port 6666 [ 30.898568] netpoll: netconsole: remote IPv6 address 2a02:6b8:b000:605c:e61d:2dff:fe03:3790 [ 30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0 [ 30.917747] console [netcon0] enabled [ 30.917749] netconsole: network logging started [ 31.453353] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.185730] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.321840] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.465822] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.597423] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.745417] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 34.877356] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 35.005441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 35.157376] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 35.289362] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 35.417441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames [ 37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None This patch flushes tx buffers only once when carrier is off rather than at each watchdog iteration. Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05e1000e: Fix -Wformat-truncation warningsFlorian Fainelli1-2/+2
[ Upstream commit 135e7245479addc6b1f5d031e3d7e2ddb3d2b109 ] Provide precision hints to snprintf() since we know the destination buffer size of the RX/TX ring names are IFNAMSIZ + 5 - 1. This fixes the following warnings: drivers/net/ethernet/intel/e1000e/netdev.c: In function 'e1000_request_msix': drivers/net/ethernet/intel/e1000e/netdev.c:2109:13: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] "%s-rx-0", netdev->name); ^ drivers/net/ethernet/intel/e1000e/netdev.c:2107:3: note: 'snprintf' output between 6 and 21 bytes into a destination of size 20 snprintf(adapter->rx_ring->name, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(adapter->rx_ring->name) - 1, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%s-rx-0", netdev->name); ~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/e1000e/netdev.c:2125:13: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] "%s-tx-0", netdev->name); ^ drivers/net/ethernet/intel/e1000e/netdev.c:2123:3: note: 'snprintf' output between 6 and 21 bytes into a destination of size 20 snprintf(adapter->tx_ring->name, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(adapter->tx_ring->name) - 1, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%s-tx-0", netdev->name); ~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>