1# 2# This file and its contents are supplied under the terms of the 3# Common Development and Distribution License ("CDDL"), version 1.0. 4# You may only use this file in accordance with the terms of version 5# 1.0 of the CDDL. 6# 7# A full copy of the text of the CDDL should have accompanied this 8# source. A copy of the CDDL is also available via the Internet at 9# http://www.illumos.org/license/CDDL. 10# 11 12# 13# Copyright (c) 2013 Joyent, Inc. All rights reserved. 14# 15 16Historically e1000g and igb were maintained by two different teams at Sun and 17thus while they used identical common code from Intel, they each only ever used 18portions of it and were not kept in sync with one another. To help make 19maintenance and the adding of new devices easier in illumos, we have gone 20through and made it so that igb and e1000g rely on the same set of common code; 21however, this code is not in its own module, each has its own copy of the code 22compiled into it for various reasons which will be laid out below. 23 24As part of the interface with the common code, the driver is required to define 25an e1000_osdep.h. Currently each version of the driver defines its *own* version 26of this header file in their own driver specific directory. However, the code 27that implements this is different in each directory, specifically e1000g_osdep.c 28and igb_osdep.c. It's important that they have different names and not be called 29the same thing due to how the uts makefiles work. 30 31Deviations from the common FreeBSD code: 32 33We have a few differences from the common version of the FreeBSD code that exist 34so that we can both gather firmware information and that have workarounds for 35older chipsets. While, we would like to get that to be synced up and common, it 36is not currently. 37 38Energy Efficient Ethernet (EEE) is not enabled by default. This technology was 39introduced with the I350 family of parts in the igb driver. However, there have 40been issues seen with it in the wild and thus we opt to disable it by default 41until tests have proven that there are no longer problems. 42 43To help make that easier, we've documented here what these extra definitions 44are. DO NOT just blindly copy over new common code. There is more work that 45needs to be done in terms of changed interfaces and expectations for the 46drivers. 47 48# e1000_defines.h 49 50In e1000_defines.h we add the following three definitions which are not 51currently present. These definitions allow us to attach firware revisions and 52other information to the devinfo tree. 53 54#define NVM_VERSION 0x0005 55#define NVM_OEM_OFFSET_0 6 56#define NVM_OEM_OFFSET_1 7 57 58# Workarounds for the 82541 and 82547 59 60There are various workarounds in place for the 82541 and 82547 due to errata 61that exist for these devices. This has traditionally been a part of the common 62code. Until this can get merged into the common code completely, we've spearted 63out the changes that are the actual C functions into 64uts/common/io/e1000g/e1000g_workarounds.c. However, this alone is not 65sufficient. You must make sure that in e1000_hw.h that the struc 66e1000_dev_spec_82541 actually looks like the following: 67 68struct e1000_dev_spec_82541 { 69 enum e1000_dsp_config dsp_config; 70 enum e1000_ffe_config ffe_config; 71 u32 tx_fifo_head; 72 u32 tx_fifo_start; 73 u32 tx_fifo_size; 74 u16 spd_default; 75 bool phy_init_script; 76 bool ttl_workaround; 77}; 78 79# EEE 80 81By default we disable all support for EEE. To cause this to happen you must 82make the following change in e1000_82575.c's init_mac_params. 83 84From: 85 394 /* Enable EEE default settings for EEE supported devices */ 86 395 if (mac->type >= e1000_i350) 87 396 dev_spec->eee_disable = FALSE; 88To: 89 394 /* Enable EEE default settings for EEE supported devices */ 90 395 if (mac->type >= e1000_i350) 91 396 dev_spec->eee_disable = TRUE; 92 93Future work: 94 95The next step here is to take the osdep portions and merge them. That would 96allow us to build one common misc module e1000api that both igb and e1000g 97depend on rather than building separate copies of the common code into each 98driver. Another potential option which may prove to have less value is to take 99all of the gld and ddi logic and have one driver export that leaving e1000g and 100igb as small stubs which depend on that. Note however, that the latter is not 101how our upstream is currently structuring their igb and em (FreeBSD's e1000g) 102drivers. 103