Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/960724/?format=api
{ "id": 960724, "url": "http://patchwork.ozlabs.org/api/patches/960724/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20180821213913.32528-1-jeffrey.t.kirsher@intel.com/", "project": { "id": 46, "url": "http://patchwork.ozlabs.org/api/projects/46/?format=api", "name": "Intel Wired Ethernet development", "link_name": "intel-wired-lan", "list_id": "intel-wired-lan.osuosl.org", "list_email": "intel-wired-lan@osuosl.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20180821213913.32528-1-jeffrey.t.kirsher@intel.com>", "list_archive_url": null, "date": "2018-08-21T21:39:13", "name": "[v3] Documentation: e1000e: Update kernel documentation", "commit_ref": null, "pull_url": null, "state": "changes-requested", "archived": false, "hash": "48e4d8c5ad51157c9c2d9f49e775a6e3139c9e03", "submitter": { "id": 473, "url": "http://patchwork.ozlabs.org/api/people/473/?format=api", "name": "Kirsher, Jeffrey T", "email": "jeffrey.t.kirsher@intel.com" }, "delegate": { "id": 68, "url": "http://patchwork.ozlabs.org/api/users/68/?format=api", "username": "jtkirshe", "first_name": "Jeff", "last_name": "Kirsher", "email": "jeffrey.t.kirsher@intel.com" }, "mbox": "http://patchwork.ozlabs.org/project/intel-wired-lan/patch/20180821213913.32528-1-jeffrey.t.kirsher@intel.com/mbox/", "series": [ { "id": 61865, "url": "http://patchwork.ozlabs.org/api/series/61865/?format=api", "web_url": "http://patchwork.ozlabs.org/project/intel-wired-lan/list/?series=61865", "date": "2018-08-21T21:39:13", "name": "[v3] Documentation: e1000e: Update kernel documentation", "version": 3, "mbox": "http://patchwork.ozlabs.org/series/61865/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/960724/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/960724/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<intel-wired-lan-bounces@osuosl.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Delivered-To": [ "patchwork-incoming@bilbo.ozlabs.org", "intel-wired-lan@lists.osuosl.org" ], "Authentication-Results": [ "ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=osuosl.org\n\t(client-ip=140.211.166.133; helo=hemlock.osuosl.org;\n\tenvelope-from=intel-wired-lan-bounces@osuosl.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org;\n\tdmarc=fail (p=none dis=none) header.from=intel.com" ], "Received": [ "from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 41w3wW0Lwfz9s9F\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 22 Aug 2018 07:39:22 +1000 (AEST)", "from localhost (localhost [127.0.0.1])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id 72D948787D;\n\tTue, 21 Aug 2018 21:39:21 +0000 (UTC)", "from hemlock.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id VQ-byaVPJy0h; Tue, 21 Aug 2018 21:39:18 +0000 (UTC)", "from ash.osuosl.org (ash.osuosl.org [140.211.166.34])\n\tby hemlock.osuosl.org (Postfix) with ESMTP id E562187825;\n\tTue, 21 Aug 2018 21:39:18 +0000 (UTC)", "from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\tby ash.osuosl.org (Postfix) with ESMTP id 539921BFFDD\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 21 Aug 2018 21:39:17 +0000 (UTC)", "from localhost (localhost [127.0.0.1])\n\tby fraxinus.osuosl.org (Postfix) with ESMTP id 4E1E680D43\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 21 Aug 2018 21:39:17 +0000 (UTC)", "from fraxinus.osuosl.org ([127.0.0.1])\n\tby localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)\n\twith ESMTP id jVQj6o71m3Yw for <intel-wired-lan@lists.osuosl.org>;\n\tTue, 21 Aug 2018 21:39:15 +0000 (UTC)", "from mga01.intel.com (mga01.intel.com [192.55.52.88])\n\tby fraxinus.osuosl.org (Postfix) with ESMTPS id D016785F94\n\tfor <intel-wired-lan@lists.osuosl.org>;\n\tTue, 21 Aug 2018 21:39:15 +0000 (UTC)", "from orsmga007.jf.intel.com ([10.7.209.58])\n\tby fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t21 Aug 2018 14:39:15 -0700", "from jtkirshe-desk1.jf.intel.com ([134.134.177.59])\n\tby orsmga007.jf.intel.com with ESMTP; 21 Aug 2018 14:39:15 -0700" ], "X-Virus-Scanned": [ "amavisd-new at osuosl.org", "amavisd-new at osuosl.org" ], "X-Greylist": "domain auto-whitelisted by SQLgrey-1.7.6", "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.53,271,1531810800\"; d=\"scan'208\";a=\"66813839\"", "From": "Jeff Kirsher <jeffrey.t.kirsher@intel.com>", "To": "intel-wired-lan@lists.osuosl.org", "Date": "Tue, 21 Aug 2018 14:39:13 -0700", "Message-Id": "<20180821213913.32528-1-jeffrey.t.kirsher@intel.com>", "X-Mailer": "git-send-email 2.17.1", "Subject": "[Intel-wired-lan] [PATCH v3] Documentation: e1000e: Update kernel\n\tdocumentation", "X-BeenThere": "intel-wired-lan@osuosl.org", "X-Mailman-Version": "2.1.24", "Precedence": "list", "List-Id": "Intel Wired Ethernet Linux Kernel Driver Development\n\t<intel-wired-lan.osuosl.org>", "List-Unsubscribe": "<https://lists.osuosl.org/mailman/options/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=unsubscribe>", "List-Archive": "<http://lists.osuosl.org/pipermail/intel-wired-lan/>", "List-Post": "<mailto:intel-wired-lan@osuosl.org>", "List-Help": "<mailto:intel-wired-lan-request@osuosl.org?subject=help>", "List-Subscribe": "<https://lists.osuosl.org/mailman/listinfo/intel-wired-lan>, \n\t<mailto:intel-wired-lan-request@osuosl.org?subject=subscribe>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "7bit", "Errors-To": "intel-wired-lan-bounces@osuosl.org", "Sender": "\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>" }, "content": "Updated the e1000e kernel documentation with the latest information.\nAlso remove the command line parameters, which do not exist with the\nin-kernel driver. Converted the documentation to the RST format.\n\nSigned-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>\n---\nv1/v2: initial documentation update\n\nv3: convert to RST format, remove module parameters that do not exist\n and add SPDX header\n\n Documentation/networking/e1000e.rst | 151 ++++++++++++++\n Documentation/networking/e1000e.txt | 312 ----------------------------\n Documentation/networking/index.rst | 1 +\n MAINTAINERS | 2 +-\n drivers/net/ethernet/intel/Kconfig | 3 +\n 5 files changed, 156 insertions(+), 313 deletions(-)\n create mode 100644 Documentation/networking/e1000e.rst\n delete mode 100644 Documentation/networking/e1000e.txt", "diff": "diff --git a/Documentation/networking/e1000e.rst b/Documentation/networking/e1000e.rst\nnew file mode 100644\nindex 000000000000..f19090c2605d\n--- /dev/null\n+++ b/Documentation/networking/e1000e.rst\n@@ -0,0 +1,151 @@\n+.. SPDX-License-Identifier: GPL-2.0+\n+\n+Linux* Driver for Intel(R) Ethernet Network Connection\n+======================================================\n+\n+Intel Gigabit Linux driver.\n+Copyright(c) 2008-2018 Intel Corporation.\n+\n+Contents\n+========\n+\n+- Identifying Your Adapter\n+- Additional Configurations\n+- Support\n+\n+Identifying Your Adapter\n+========================\n+For information on how to identify your adapter, and for the latest Intel\n+network drivers, refer to the Intel Support website:\n+http://www.intel.com/support\n+\n+\n+Additional Features and Configurations\n+======================================\n+\n+Jumbo Frames\n+------------\n+Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)\n+to a value larger than the default value of 1500.\n+\n+Use the ifconfig command to increase the MTU size. For example, enter the\n+following where <x> is the interface number::\n+\n+ ifconfig eth<x> mtu 9000 up\n+\n+Alternatively, you can use the ip command as follows::\n+\n+ ip link set mtu 9000 dev eth<x>\n+ ip link set up dev eth<x>\n+\n+This setting is not saved across reboots. The setting change can be made\n+permanent by adding 'MTU=9000' to the file:\n+\n+- For RHEL: /etc/sysconfig/network-scripts/ifcfg-eth<x>\n+- For SLES: /etc/sysconfig/network/<config_file>\n+\n+NOTE: The maximum MTU setting for Jumbo Frames is 8996. This value coincides\n+with the maximum Jumbo Frames size of 9018 bytes.\n+\n+NOTE: Using Jumbo frames at 10 or 100 Mbps is not supported and may result in\n+poor performance or loss of link.\n+\n+NOTE: The following adapters limit Jumbo Frames sized packets to a maximum of\n+4088 bytes:\n+ - Intel(R) 82578DM Gigabit Network Connection\n+ - Intel(R) 82577LM Gigabit Network Connection\n+\n+The following adapters do not support Jumbo Frames:\n+ - Intel(R) PRO/1000 Gigabit Server Adapter\n+ - Intel(R) PRO/1000 PM Network Connection\n+ - Intel(R) 82562G 10/100 Network Connection\n+ - Intel(R) 82562G-2 10/100 Network Connection\n+ - Intel(R) 82562GT 10/100 Network Connection\n+ - Intel(R) 82562GT-2 10/100 Network Connection\n+ - Intel(R) 82562V 10/100 Network Connection\n+ - Intel(R) 82562V-2 10/100 Network Connection\n+ - Intel(R) 82566DC Gigabit Network Connection\n+ - Intel(R) 82566DC-2 Gigabit Network Connection\n+ - Intel(R) 82566DM Gigabit Network Connection\n+ - Intel(R) 82566MC Gigabit Network Connection\n+ - Intel(R) 82566MM Gigabit Network Connection\n+ - Intel(R) 82567V-3 Gigabit Network Connection\n+ - Intel(R) 82577LC Gigabit Network Connection\n+ - Intel(R) 82578DC Gigabit Network Connection\n+\n+NOTE: Jumbo Frames cannot be configured on an 82579-based Network device if\n+MACSec is enabled on the system.\n+\n+\n+ethtool\n+-------\n+The driver utilizes the ethtool interface for driver configuration and\n+diagnostics, as well as displaying statistical information. The latest ethtool\n+version is required for this functionality. Download it at:\n+\n+https://www.kernel.org/pub/software/network/ethtool/\n+\n+NOTE: When validating enable/disable tests on some parts (for example, 82578),\n+it is necessary to add a few seconds between tests when working with ethtool.\n+\n+\n+Speed and Duplex Configuration\n+------------------------------\n+In addressing speed and duplex configuration issues, you need to distinguish\n+between copper-based adapters and fiber-based adapters.\n+\n+In the default mode, an Intel(R) Ethernet Network Adapter using copper\n+connections will attempt to auto-negotiate with its link partner to determine\n+the best setting. If the adapter cannot establish link with the link partner\n+using auto-negotiation, you may need to manually configure the adapter and link\n+partner to identical settings to establish link and pass packets. This should\n+only be needed when attempting to link with an older switch that does not\n+support auto-negotiation or one that has been forced to a specific speed or\n+duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds\n+and higher cannot be forced. Use the autonegotiation advertising setting to\n+manually set devices for 1 Gbps and higher.\n+\n+Speed, duplex, and autonegotiation advertising are configured through the\n+ethtool* utility.\n+\n+Caution: Only experienced network administrators should force speed and duplex\n+or change autonegotiation advertising manually. The settings at the switch must\n+always match the adapter settings. Adapter performance may suffer or your\n+adapter may not operate if you configure the adapter differently from your\n+switch.\n+\n+An Intel(R) Ethernet Network Adapter using fiber-based connections, however,\n+will not attempt to auto-negotiate with its link partner since those adapters\n+operate only in full duplex and only at their native speed.\n+\n+\n+Enabling Wake on LAN* (WoL)\n+---------------------------\n+WoL is configured through the ethtool* utility.\n+\n+WoL will be enabled on the system during the next shut down or reboot. For\n+this driver version, in order to enable WoL, the e1000e driver must be loaded\n+prior to shutting down or suspending the system.\n+\n+NOTE: Wake on LAN is only supported on port A for the following devices:\n+- Intel(R) PRO/1000 PT Dual Port Network Connection\n+- Intel(R) PRO/1000 PT Dual Port Server Connection\n+- Intel(R) PRO/1000 PT Dual Port Server Adapter\n+- Intel(R) PRO/1000 PF Dual Port Server Adapter\n+- Intel(R) PRO/1000 PT Quad Port Server Adapter\n+- Intel(R) Gigabit PT Quad Port Server ExpressModule\n+\n+\n+Support\n+=======\n+For general information, go to the Intel support website at:\n+\n+https://www.intel.com/support/\n+\n+or the Intel Wired Networking project hosted by Sourceforge at:\n+\n+https://sourceforge.net/projects/e1000\n+\n+If an issue is identified with the released source code on a supported kernel\n+with a supported adapter, email the specific information related to the issue\n+to e1000-devel@lists.sf.net.\ndiff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt\ndeleted file mode 100644\nindex 12089547baed..000000000000\n--- a/Documentation/networking/e1000e.txt\n+++ /dev/null\n@@ -1,312 +0,0 @@\n-Linux* Driver for Intel(R) Ethernet Network Connection\n-======================================================\n-\n-Intel Gigabit Linux driver.\n-Copyright(c) 1999 - 2013 Intel Corporation.\n-\n-Contents\n-========\n-\n-- Identifying Your Adapter\n-- Command Line Parameters\n-- Additional Configurations\n-- Support\n-\n-Identifying Your Adapter\n-========================\n-\n-The e1000e driver supports all PCI Express Intel(R) Gigabit Network\n-Connections, except those that are 82575, 82576 and 82580-based*.\n-\n-* NOTE: The Intel(R) PRO/1000 P Dual Port Server Adapter is supported by\n- the e1000 driver, not the e1000e driver due to the 82546 part being used\n- behind a PCI Express bridge.\n-\n-For more information on how to identify your adapter, go to the Adapter &\n-Driver ID Guide at:\n-\n- http://support.intel.com/support/go/network/adapter/idguide.htm\n-\n-For the latest Intel network drivers for Linux, refer to the following\n-website. In the search field, enter your adapter name or type, or use the\n-networking link on the left to search for your adapter:\n-\n- http://support.intel.com/support/go/network/adapter/home.htm\n-\n-Command Line Parameters\n-=======================\n-\n-The default value for each parameter is generally the recommended setting,\n-unless otherwise noted.\n-\n-NOTES: For more information about the InterruptThrottleRate,\n- RxIntDelay, TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay\n- parameters, see the application note at:\n- http://www.intel.com/design/network/applnots/ap450.htm\n-\n-InterruptThrottleRate\n----------------------\n-Valid Range: 0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,\n- 4=simplified balancing)\n-Default Value: 3\n-\n-The driver can limit the amount of interrupts per second that the adapter\n-will generate for incoming packets. It does this by writing a value to the\n-adapter that is based on the maximum amount of interrupts that the adapter\n-will generate per second.\n-\n-Setting InterruptThrottleRate to a value greater or equal to 100\n-will program the adapter to send out a maximum of that many interrupts\n-per second, even if more packets have come in. This reduces interrupt\n-load on the system and can lower CPU utilization under heavy load,\n-but will increase latency as packets are not processed as quickly.\n-\n-The default behaviour of the driver previously assumed a static\n-InterruptThrottleRate value of 8000, providing a good fallback value for\n-all traffic types, but lacking in small packet performance and latency.\n-The hardware can handle many more small packets per second however, and\n-for this reason an adaptive interrupt moderation algorithm was implemented.\n-\n-The driver has two adaptive modes (setting 1 or 3) in which\n-it dynamically adjusts the InterruptThrottleRate value based on the traffic\n-that it receives. After determining the type of incoming traffic in the last\n-timeframe, it will adjust the InterruptThrottleRate to an appropriate value\n-for that traffic.\n-\n-The algorithm classifies the incoming traffic every interval into\n-classes. Once the class is determined, the InterruptThrottleRate value is\n-adjusted to suit that traffic type the best. There are three classes defined:\n-\"Bulk traffic\", for large amounts of packets of normal size; \"Low latency\",\n-for small amounts of traffic and/or a significant percentage of small\n-packets; and \"Lowest latency\", for almost completely small packets or\n-minimal traffic.\n-\n-In dynamic conservative mode, the InterruptThrottleRate value is set to 4000\n-for traffic that falls in class \"Bulk traffic\". If traffic falls in the \"Low\n-latency\" or \"Lowest latency\" class, the InterruptThrottleRate is increased\n-stepwise to 20000. This default mode is suitable for most applications.\n-\n-For situations where low latency is vital such as cluster or\n-grid computing, the algorithm can reduce latency even more when\n-InterruptThrottleRate is set to mode 1. In this mode, which operates\n-the same as mode 3, the InterruptThrottleRate will be increased stepwise to\n-70000 for traffic in class \"Lowest latency\".\n-\n-In simplified mode the interrupt rate is based on the ratio of TX and\n-RX traffic. If the bytes per second rate is approximately equal, the\n-interrupt rate will drop as low as 2000 interrupts per second. If the\n-traffic is mostly transmit or mostly receive, the interrupt rate could\n-be as high as 8000.\n-\n-Setting InterruptThrottleRate to 0 turns off any interrupt moderation\n-and may improve small packet latency, but is generally not suitable\n-for bulk throughput traffic.\n-\n-NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and\n- RxAbsIntDelay parameters. In other words, minimizing the receive\n- and/or transmit absolute delays does not force the controller to\n- generate more interrupts than what the Interrupt Throttle Rate\n- allows.\n-\n-NOTE: When e1000e is loaded with default settings and multiple adapters\n- are in use simultaneously, the CPU utilization may increase non-\n- linearly. In order to limit the CPU utilization without impacting\n- the overall throughput, we recommend that you load the driver as\n- follows:\n-\n- modprobe e1000e InterruptThrottleRate=3000,3000,3000\n-\n- This sets the InterruptThrottleRate to 3000 interrupts/sec for\n- the first, second, and third instances of the driver. The range\n- of 2000 to 3000 interrupts per second works on a majority of\n- systems and is a good starting point, but the optimal value will\n- be platform-specific. If CPU utilization is not a concern, use\n- RX_POLLING (NAPI) and default driver settings.\n-\n-RxIntDelay\n-----------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 0\n-\n-This value delays the generation of receive interrupts in units of 1.024\n-microseconds. Receive interrupt reduction can improve CPU efficiency if\n-properly tuned for specific network traffic. Increasing this value adds\n-extra latency to frame reception and can end up decreasing the throughput\n-of TCP traffic. If the system is reporting dropped receives, this value\n-may be set too high, causing the driver to run out of available receive\n-descriptors.\n-\n-CAUTION: When setting RxIntDelay to a value other than 0, adapters may\n- hang (stop transmitting) under certain network conditions. If\n- this occurs a NETDEV WATCHDOG message is logged in the system\n- event log. In addition, the controller is automatically reset,\n- restoring the network connection. To eliminate the potential\n- for the hang ensure that RxIntDelay is set to 0.\n-\n-RxAbsIntDelay\n--------------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 8\n-\n-This value, in units of 1.024 microseconds, limits the delay in which a\n-receive interrupt is generated. Useful only if RxIntDelay is non-zero,\n-this value ensures that an interrupt is generated after the initial\n-packet is received within the set amount of time. Proper tuning,\n-along with RxIntDelay, may improve traffic throughput in specific network\n-conditions.\n-\n-TxIntDelay\n-----------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 8\n-\n-This value delays the generation of transmit interrupts in units of\n-1.024 microseconds. Transmit interrupt reduction can improve CPU\n-efficiency if properly tuned for specific network traffic. If the\n-system is reporting dropped transmits, this value may be set too high\n-causing the driver to run out of available transmit descriptors.\n-\n-TxAbsIntDelay\n--------------\n-Valid Range: 0-65535 (0=off)\n-Default Value: 32\n-\n-This value, in units of 1.024 microseconds, limits the delay in which a\n-transmit interrupt is generated. Useful only if TxIntDelay is non-zero,\n-this value ensures that an interrupt is generated after the initial\n-packet is sent on the wire within the set amount of time. Proper tuning,\n-along with TxIntDelay, may improve traffic throughput in specific\n-network conditions.\n-\n-Copybreak\n----------\n-Valid Range: 0-xxxxxxx (0=off)\n-Default Value: 256\n-\n-Driver copies all packets below or equaling this size to a fresh RX\n-buffer before handing it up the stack.\n-\n-This parameter is different than other parameters, in that it is a\n-single (not 1,1,1 etc.) parameter applied to all driver instances and\n-it is also available during runtime at\n-/sys/module/e1000e/parameters/copybreak\n-\n-SmartPowerDownEnable\n---------------------\n-Valid Range: 0-1\n-Default Value: 0 (disabled)\n-\n-Allows PHY to turn off in lower power states. The user can set this parameter\n-in supported chipsets.\n-\n-KumeranLockLoss\n----------------\n-Valid Range: 0-1\n-Default Value: 1 (enabled)\n-\n-This workaround skips resetting the PHY at shutdown for the initial\n-silicon releases of ICH8 systems.\n-\n-IntMode\n--------\n-Valid Range: 0-2 (0=legacy, 1=MSI, 2=MSI-X)\n-Default Value: 2\n-\n-Allows changing the interrupt mode at module load time, without requiring a\n-recompile. If the driver load fails to enable a specific interrupt mode, the\n-driver will try other interrupt modes, from least to most compatible. The\n-interrupt order is MSI-X, MSI, Legacy. If specifying MSI (IntMode=1)\n-interrupts, only MSI and Legacy will be attempted.\n-\n-CrcStripping\n-------------\n-Valid Range: 0-1\n-Default Value: 1 (enabled)\n-\n-Strip the CRC from received packets before sending up the network stack. If\n-you have a machine with a BMC enabled but cannot receive IPMI traffic after\n-loading or enabling the driver, try disabling this feature.\n-\n-WriteProtectNVM\n----------------\n-Valid Range: 0,1\n-Default Value: 1\n-\n-If set to 1, configure the hardware to ignore all write/erase cycles to the\n-GbE region in the ICHx NVM (in order to prevent accidental corruption of the\n-NVM). This feature can be disabled by setting the parameter to 0 during initial\n-driver load.\n-NOTE: The machine must be power cycled (full off/on) when enabling NVM writes\n-via setting the parameter to zero. Once the NVM has been locked (via the\n-parameter at 1 when the driver loads) it cannot be unlocked except via power\n-cycle.\n-\n-Additional Configurations\n-=========================\n-\n- Jumbo Frames\n- ------------\n- Jumbo Frames support is enabled by changing the MTU to a value larger than\n- the default of 1500. Use the ifconfig command to increase the MTU size.\n- For example:\n-\n- ifconfig eth<x> mtu 9000 up\n-\n- This setting is not saved across reboots.\n-\n- Notes:\n-\n- - The maximum MTU setting for Jumbo Frames is 9216. This value coincides\n- with the maximum Jumbo Frames size of 9234 bytes.\n-\n- - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in\n- poor performance or loss of link.\n-\n- - Some adapters limit Jumbo Frames sized packets to a maximum of\n- 4096 bytes and some adapters do not support Jumbo Frames.\n-\n- - Jumbo Frames cannot be configured on an 82579-based Network device, if\n- MACSec is enabled on the system.\n-\n- ethtool\n- -------\n- The driver utilizes the ethtool interface for driver configuration and\n- diagnostics, as well as displaying statistical information. We\n- strongly recommend downloading the latest version of ethtool at:\n-\n- https://kernel.org/pub/software/network/ethtool/\n-\n- NOTE: When validating enable/disable tests on some parts (82578, for example)\n- you need to add a few seconds between tests when working with ethtool.\n-\n- Speed and Duplex\n- ----------------\n- Speed and Duplex are configured through the ethtool* utility. For\n- instructions, refer to the ethtool man page.\n-\n- Enabling Wake on LAN* (WoL)\n- ---------------------------\n- WoL is configured through the ethtool* utility. For instructions on\n- enabling WoL with ethtool, refer to the ethtool man page.\n-\n- WoL will be enabled on the system during the next shut down or reboot.\n- For this driver version, in order to enable WoL, the e1000e driver must be\n- loaded when shutting down or rebooting the system.\n-\n- In most cases Wake On LAN is only supported on port A for multiple port\n- adapters. To verify if a port supports Wake on Lan run ethtool eth<X>.\n-\n-Support\n-=======\n-\n-For general information, go to the Intel support website at:\n-\n- www.intel.com/support/\n-\n-or the Intel Wired Networking project hosted by Sourceforge at:\n-\n- http://sourceforge.net/projects/e1000\n-\n-If an issue is identified with the released source code on the supported\n-kernel with a supported adapter, email the specific information related\n-to the issue to e1000-devel@lists.sf.net\ndiff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst\nindex 779c1f141d94..fd315630487c 100644\n--- a/Documentation/networking/index.rst\n+++ b/Documentation/networking/index.rst\n@@ -14,6 +14,7 @@ Contents:\n dpaa2/index\n e100\n e1000\n+ e1000e\n fm10k\n ixgb\n kapi\ndiff --git a/MAINTAINERS b/MAINTAINERS\nindex be1adcd6477c..89a1a53ea768 100644\n--- a/MAINTAINERS\n+++ b/MAINTAINERS\n@@ -7277,7 +7277,7 @@ T:\tgit git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git\n S:\tSupported\n F:\tDocumentation/networking/e100.rst\n F:\tDocumentation/networking/e1000.rst\n-F:\tDocumentation/networking/e1000e.txt\n+F:\tDocumentation/networking/e1000e.rst\n F:\tDocumentation/networking/fm10k.rst\n F:\tDocumentation/networking/igb.txt\n F:\tDocumentation/networking/igbvf.txt\ndiff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig\nindex ca168b1903ed..21f8ec992276 100644\n--- a/drivers/net/ethernet/intel/Kconfig\n+++ b/drivers/net/ethernet/intel/Kconfig\n@@ -68,6 +68,9 @@ config E1000E\n \n \t <http://support.intel.com>\n \n+\t More specific information on configuring the driver is in\n+\t <file:Documentation/networking/e1000e.rst>.\n+\n \t To compile this driver as a module, choose M here. The module\n \t will be called e1000e.\n \n", "prefixes": [ "v3" ] }