- 30 4月, 2017 3 次提交
-
-
由 Sasha Neftin 提交于
The propagation of CannonLake mac type to driver functionality Signed-off-by: NSasha Neftin <sasha.neftin@intel.com> Reviewed-by: NRaanan Avargil <raanan.avargil@intel.com> Reviewed-by: NDima Ruinskiy <dima.ruinskiy@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Sasha Neftin 提交于
i219 (6) and i219 (7) are the next LOM generations that will be available on the nextIntel Client platform (CannonLake) This patch provides the initial support for these devices Signed-off-by: NSasha Neftin <sasha.neftin@intel.com> Reviewed-by: NRaanan Avargil <raanan.avargil@intel.com> Reviewed-by: NDima Ruinskiy <dima.ruinskiy@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jarod Wilson 提交于
I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used as a PTP slave experiences random ~10 hour clock jumps, which are resolved if the same workaround for the 82574 and 82583 is employed, so set the appropriate flag2 in e1000_pch_lpt_info too. Reported-by: NRupesh Patel <rupatel@redhat.com> Signed-off-by: NJarod Wilson <jarod@redhat.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 17 8月, 2016 1 次提交
-
-
由 Jarod Wilson 提交于
I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used as a PTP slave experiences random ~10 hour clock jumps, which are resolved if the same workaround for the 82574 and 82583 is employed, so set the appropriate flag2 in e1000_pch_lpt_info too. Reported-by: NRupesh Patel <rupatel@redhat.com> Signed-off-by: NJarod Wilson <jarod@redhat.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 14 5月, 2016 1 次提交
-
-
由 Jacob Keller 提交于
This prevents signed bitshift issues when the shift would overwrite the signed bit, and prevents making this mistake in the future when copying and modifying code. Use GENMASK or the unsigned postfix for cases which aren't suitable for BIT() macro. Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 25 2月, 2016 4 次提交
-
-
由 Raanan Avargil 提交于
There have been bugs caused by HW ULP configuration settings not being properly cleared after cable connect in V-Pro capable systems. This caused HW to get out of sync occasionally. The fix ensures that ULP settings are cleared in HW after LAN cable re-connect. Signed-off-by: NRaanan Avargil <raanan.avargil@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Raanan Avargil 提交于
Based on feedback from HW team, the configured value of the internal PHY HW FIFO pointer gap was incorrect for non-gig speeds. This patch provides the correct configuration. Signed-off-by: NRaanan Avargil <raanan.avargil@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Raanan Avargil 提交于
Several packet loss issues were reported for which the root cause for them was an incorrect configuration of internal HW PHY clock gating mechanism by SW. This patch provides the correct mechanism. Signed-off-by: NRaanan Avargil <raanan.avargil@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Raanan Avargil 提交于
Due to system level changes introduced in Skylake, ULP exit takes significantly longer to occur. Therefore, driver must wait longer for. Signed-off-by: NRaanan Avargil <raanan.avargil@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 13 12月, 2015 2 次提交
-
-
由 Raanan Avargil 提交于
i219-LM (3) is a LOM that will be available on systems with the Lewisburg Platform Controller Hub (PCH) chipset from Intel. This patch provides the initial support for the device. Signed-off-by: NRaanan Avargil <raanan.avargil@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Raanan Avargil 提交于
Due to timing changes to the ME firmware in Skylake, this timer needs to be increased to 300ms. Signed-off-by: NRaanan Avargil <raanan.avargil@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 26 6月, 2015 5 次提交
-
-
由 Yanir Lubetkin 提交于
In SPT hardware does not require this driver workaround. Removed the conditional that caused K1 workaround execution on SPT. Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Yanir Lubetkin 提交于
Due to clocking changes in the Skylake platform, there was i219 data corruption. To work around this, HW team reported the need to increase the minimum gap between the PHY FIFO read and write pointers. Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Yanir Lubetkin 提交于
In SPT/i219, there were CRC errors in speed 10/100 full duplex. The solution given by the HW team is to increase the IPG from 8 to 0xC Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Yanir Lubetkin 提交于
In i219, there is a hardware bug that prevented ULP entry. A side effect of the original software fix for this was that EEE in Sx couldn't be enabled. This patch implements a modified flow that allows both ULP and EEE in Sx. Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Yanir Lubetkin 提交于
On power up, the MAC - PHY interface needs to be set to PCIe, even if cable is disconnected. In ME systems, the ME handles this on exit from Sx state. In non-ME, the driver handles it. Added a check for non-ME system to the driver code that handles that. Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 03 6月, 2015 2 次提交
-
-
由 Yanir Lubetkin 提交于
Bump the version to reflect the driver changes and bug fixes for i219. Also update the copyright, while we are at it. Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Yanir Lubetkin 提交于
Fixes a warning that was reported by Yanjiang Jin <yanjiang.jin@windriver.com> by implementing the solution suggested by Alexander Duyck <alexander.h.duyck@redhat.com>. Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 04 5月, 2015 2 次提交
-
-
由 Jeff Kirsher 提交于
We were using s64 for lat_ns (latency nano-second value) since in our calculations a negative value could be a resultant. For negative values, we then assign lat_ns to be zero, so the value passed to do_div() was never negative, but do_div() expects the argument type to be u64, so do a cast to resolve a compile warning seen on PowerPC. CC: Yanjiang Jin <yanjiang.jin@windriver.com> CC: Yanir Lubetkin <yanirx.lubetkin@intel.com> Reported-by: NYanjiang Jin <yanjiang.jin@windriver.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com>
-
由 Alexander Duyck 提交于
When the VLAN_HLEN was added to the calculation for the maximum frame size there seems to have been a number of issues added to the driver. The first issue is that in some cases the maximum frame size for a device never really reached the actual maximum frame size as the VLAN header length was not included the calculation for that value. As a result some parts only supported a maximum frame size of either 1496 in the case of parts that didn't support jumbo frames, and 8996 in the case of the parts that do. The second issue is the fact that there were several checks that weren't updated so as a result setting an MTU of 1500 was treated as enabling jumbo frames as the calculated value was 1522 instead of 1518. I have addressed those by replacing ETH_FRAME_LEN with VLAN_ETH_FRAME_LEN where appropriate. The final issue was the fact that lowering the MTU below 1500 would cause the driver to allocate 2K buffers for the rings. This is an old issue that was fixed several years ago in igb/ixgbe and I am addressing now by just replacing == with a <= so that we always just round up to 1522 for anything that isn't a jumbo frame. Fixes: c751a3d5 ("e1000e: Correctly include VLAN_HLEN when changing interface MTU") Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 06 3月, 2015 1 次提交
-
-
由 Yanir Lubetkin 提交于
The interface to the device flash was modified in i219 and later HW. This patch better describes the change and the impact on the driver. CC: John W Linville <linville@tuxdriver.com> Reported-by: NJohn W Linville <linville@tuxdriver.com> Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 24 2月, 2015 1 次提交
-
-
由 David Ertman 提交于
i219 is the next-generation LOM that will be available on systems with the Sunrise Point Platform Controller Hub (PCH) chipset from Intel. This patch provides the initial support for the device. Signed-off-by: NDave Ertman <david.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Tested-by: NCarmen Edwards <carmenx.edwards@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 26 7月, 2014 2 次提交
-
-
由 David Ertman 提交于
On I217 and newer hardware, EEE is enabled in the PHY by the software when link is up and disabled by the hardware when link is lost. To enable EEE in Sx (When both ends of the link support, and are enabled for, EEE and 100Mbps), we need to disable LPLU and configure the PHY to automatically enable EEE when link is up, since there will be no software to complete the task. To configure this in the PHY, the Auto Enable LPI bit in the Low Power Idle GPIO Control register must be set. For normal operation in S0, this bit must be cleared. Signed-off-by: NDave Ertman <david.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
Modifying the jumbo frame workaround for 82579, i217 and i218 client parts to increase the gap between the read and write pointers in the Tx FIFO. Signed-off-by: NDave Ertman <david.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 21 7月, 2014 1 次提交
-
-
由 Fabian Frederick 提交于
Signed-off-by: NFabian Frederick <fabf@skynet.be> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 27 5月, 2014 2 次提交
-
-
由 David Ertman 提交于
Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
Previously, the check to turn on promiscuous mode only took into account the total number of SHared Receive Address (SHRA) registers and if the request was for a register within that range. It is possible that the Management Engine might have locked a number of SHRA and not allowed a new address to be written to the requested register. Add a function to determine the number of unlocked SHRA registers. Then determine if the number of registers available is sufficient for our needs, if not then return -ENOMEM so that UNICAST PROMISC mode is activated. Since the method by which ME claims SHRA registers is non-deterministic, also add a return value to the function attempting to write an address to a SHRA, and return a -E1000_ERR_CONFIG if the write fails. The error will be passed up the function chain and allow the driver to also set UNICAST PROMISC when this happens. Cc: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 06 5月, 2014 4 次提交
-
-
由 David Ertman 提交于
It has been determined that the workaround of putting the PHY into MDIO slow mode to access the PHY id is not necessary with Lynx Point and newer parts. The issue that necessitated the workaround has been fixed on the newer hardware. We will maintains, as a last ditch attempt, the conversion to MDIO Slow Mode in the failure branch when attempting to access the PHY id so as to cover all contingencies. Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
Several customers have reported a link flap issue on 82579. The symptoms are random and intermittent link losses when 82579 is connected to specific link partners. Issue has been root caused as interoperability problem between 82579 and at least some Broadcom PHYs in the Energy Efficient Ethernet wake mechanism. To fix the issue, we are disabling the Phase Locked Loop shutdown in 100M Low Power Idle. This solution will cause an increase of power in 100M EEE link. It will cost additional 28mW in this specific mode. Cc: Lukasz Adamczuk <lukasz.adamczuk@intel.com> Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
In commit 772d05c5 "e1000e: slow performance between two 82579 connected via 10Mbit hub", a workaround was put into place to address the overaggressive transmit behavior of 82579 parts when connecting at 10Mbs half-duplex. This same behavior is seen on i217 and i218 parts as well. This patch expands the original workaround to encompass these parts. Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
This is a workaround for a HW erratum on 82579 devices. Erratum is #23 in Intel 6 Series Chipset and Intel C200 Series Chipset specification Update June 2013. Problem: 82579 parts experience packet loss in Gig and 100 speeds when interconnect between PHY and MAC is exiting K1 power saving state. This was previously believed to only affect 1Gig speed, but has been observed at 100Mbs also. Workaround: Disable K1 for 82579 devices at Gig and 100 speeds. Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 23 4月, 2014 1 次提交
-
-
由 David Ertman 提交于
Fixing "WARNING:SPACING: networking uses a blank line after declarations" Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 08 3月, 2014 6 次提交
-
-
由 David Ertman 提交于
Previous commit c3a0dce3 fixed an overrun for the RAR on i218 devices. This commit also attempted to homogenize the RAR/SHRA access for all parts accessed by the e1000e driver. This change introduced an error for assigning MAC addresses to guest OS's for 82579 devices. Only RAR[0] is accessible to the driver for 82579 parts, and additional addresses must be placed into the SHRA[L|H] registers. The rar_entry_count was changed in the previous commit to an inaccurate value that accounted for all RAR and SHRA registers, not just the ones usable by the driver. This patch fixes the count to the correct value and adjusts the e1000_rar_set_pch2lan() function to user the correct index. Cc: John Greene <jogreene@redhat.com> Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
ULP is a power saving feature that reduces the power consumption of the PHY when a cable is not connected. ULP is gated on the following conditions: 1) The hardware must support ULP. Currently this is only I218 devices from Intel 2) ULP is initiated by the driver, so, no driver results in no ULP. 3) ULP's implementation utilizes Runtime Power Management to toggle its execution. ULP is enabled/disabled based on the state of Runtime PM. 4) ULP is not active when wake-on-unicast, multicast or broadcast is active as these features are mutually-exclusive. Since the PHY is in an unavailable state while ULP is active, any access of the PHY registers will fail. This is resolved by utilizing kernel calls that cause the device to exit Runtime PM (e.g. pm_runtime_get_sync) and then, after PHY access is complete, allow the device to resume Runtime PM (e.g. pm_runtime_put_sync). Under certain conditions, toggling the LANPHYPC is necessary to disable ULP mode. Break out existing code to toggle LANPHYPC to a new function to avoid code duplication. Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Cc: Bruce Allan <bruce.w.allan@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
Branding strings from recently released and soon to be released hardware configurations that are supported by e1000e. Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Acked-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
This patch is to update the GPL header by removing the portion that refers to the Free Software Foundation address. Change the copyright date for 2014. Reformat the header comments to conform to kernel networking coding norms Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
Enabling EEE LPI sooner than one second after link up on 82579 causes link issues with some switches. Remove EEE enablement for 82579 parts from the link initialization flow to avoid initializing too early. EEE initialization for 82579 will be done in e1000e_update_phy_task. Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Acked-by: NBruce W Allan <bruce.w.allan@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 David Ertman 提交于
On a ME enabled system with the cable out, the driver init flow would generate an erroneous message indicating that resets were being blocked by an active ME session. Cause was ME clearing the semaphore bit to block further PHY resets for up to 50 msec during power-on/cycle. After this interval, ME would re-set the bit and allow PHY resets. To resolve this, change the flow of e1000e_phy_hw_reset_generic() to utilize a delay and retry method. Poll the FWSM register to minimize any extra time added to the flow. If the delay times out at 100ms (checked in 10msec increments), then return the value E1000_BLK_PHY_RESET, as this is the accurate state of the PHY. Attempting to alter just the call to e1000e_phy_hw_reset_generic() in e1000_init_phy_workarounds_pchlan() just caused the problem to move further down the flow. Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> Acked-by: NBruce W. Allan <bruce.w.allan@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 14 9月, 2013 1 次提交
-
-
由 David Ertman 提交于
When copying the MAC RAR registers to PHY there is an error in the calculation of the rar_entry_count, which causes a write of unknown/ undefined register space in the MAC to unknown/undefined register space in the PHY. This patch fixes the overrun with writing to the PHY RAR and also fixes the ethtool offline register tests so that the correctly addressed registers have the appropriate bitmasks for R/W and RO bits for affected parts. Shawn Rader gets credit for finding and fixing the register overrun. Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com> CC: Shawn Rader <shawn.t.rader@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 28 7月, 2013 1 次提交
-
-
由 Bruce Allan 提交于
The initialization of the PHY on I217/I218, while similar to 82579, must also check to see if the MAC and PHY are in the same mode (PCIe vs. SMBus) otherwise the PHY will be inaccessible by the MAC. Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-