linux/drivers/net/ethernet/intel/Kconfig

259 lines
7.9 KiB
Plaintext
Raw Normal View History

#
# Intel network device configuration
#
config NET_VENDOR_INTEL
bool "Intel devices"
default y
depends on PCI || PCI_MSI || ISA || ISA_DMA_API || ARM || \
ARCH_ACORN || MCA || MCA_LEGACY || SNI_RM || SUN3 || \
GSC || BVME6000 || MVME16x || \
(ARM && ARCH_IXP4XX && IXP4XX_NPE && IXP4XX_QMGR) || \
EXPERIMENTAL
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
Note that the answer to this question doesn't directly affect the
kernel: saying N will just cause the configurator to skip all
the questions about Intel cards. If you say Y, you will be asked for
your specific card in the following questions.
if NET_VENDOR_INTEL
config E100
tristate "Intel(R) PRO/100+ support"
depends on PCI
select NET_CORE
select MII
---help---
This driver supports Intel(R) PRO/100 family of adapters.
To verify that your adapter is supported, find the board ID number
on the adapter. Look for a label that has a barcode and a number
in the format 123456-001 (six digits hyphen three digits).
Use the above information and the Adapter & Driver ID Guide at:
<http://support.intel.com/support/network/adapter/pro100/21397.htm>
to identify the adapter.
For the latest Intel PRO/100 network driver for Linux, see:
<http://www.intel.com/p/en_US/support/highlights/network/pro100plus>
More specific information on configuring the driver is in
<file:Documentation/networking/e100.txt>.
To compile this driver as a module, choose M here. The module
will be called e100.
config E1000
tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
depends on PCI
---help---
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
to the Adapter & Driver ID Guide at:
<http://support.intel.com/support/network/adapter/pro100/21397.htm>
For general information and support, go to the Intel support
website at:
<http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/e1000.txt>.
To compile this driver as a module, choose M here. The module
will be called e1000.
config E1000E
tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
depends on PCI && (!SPARC32 || BROKEN)
select CRC32
---help---
This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
ethernet family of adapters. For PCI or PCI-X e1000 adapters,
use the regular e1000 driver For more information on how to
identify your adapter, go to the Adapter & Driver ID Guide at:
<http://support.intel.com/support/network/adapter/pro100/21397.htm>
For general information and support, go to the Intel support
website at:
<http://support.intel.com>
To compile this driver as a module, choose M here. The module
will be called e1000e.
config IGB
tristate "Intel(R) 82575/82576 PCI-Express Gigabit Ethernet support"
depends on PCI
---help---
This driver supports Intel(R) 82575/82576 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
to the Adapter & Driver ID Guide at:
<http://support.intel.com/support/network/adapter/pro100/21397.htm>
For general information and support, go to the Intel support
website at:
<http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/e1000.txt>.
To compile this driver as a module, choose M here. The module
will be called igb.
config IGB_DCA
bool "Direct Cache Access (DCA) Support"
default y
depends on IGB && DCA && !(IGB=y && DCA=m)
---help---
Say Y here if you want to use Direct Cache Access (DCA) in the
driver. DCA is a method for warming the CPU cache before data
is used, with the intent of lessening the impact of cache misses.
config IGB_PTP
bool "PTP Hardware Clock (PHC)"
default n
depends on IGB
select PTP_1588_CLOCK
---help---
Say Y here if you want to use PTP Hardware Clock (PHC) in the
driver. Only the basic clock operations have been implemented.
Every timestamp and clock read operations must consult the
overflow counter to form a correct time value.
config IGBVF
tristate "Intel(R) 82576 Virtual Function Ethernet support"
depends on PCI
---help---
This driver supports Intel(R) 82576 virtual functions. For more
information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
<http://support.intel.com/support/network/adapter/pro100/21397.htm>
For general information and support, go to the Intel support
website at:
<http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/e1000.txt>.
To compile this driver as a module, choose M here. The module
will be called igbvf.
config IXGB
tristate "Intel(R) PRO/10GbE support"
depends on PCI
---help---
This driver supports Intel(R) PRO/10GbE family of adapters for
PCI-X type cards. For PCI-E type cards, use the "ixgbe" driver
instead. For more information on how to identify your adapter, go
to the Adapter & Driver ID Guide at:
<http://support.intel.com/support/network/adapter/pro100/21397.htm>
For general information and support, go to the Intel support
website at:
<http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/ixgb.txt>.
To compile this driver as a module, choose M here. The module
will be called ixgb.
config IXGBE
tristate "Intel(R) 10GbE PCI Express adapters support"
depends on PCI && INET
select MDIO
---help---
This driver supports Intel(R) 10GbE PCI Express family of
adapters. For more information on how to identify your adapter, go
to the Adapter & Driver ID Guide at:
<http://support.intel.com/support/network/adapter/pro100/21397.htm>
For general information and support, go to the Intel support
website at:
<http://support.intel.com>
To compile this driver as a module, choose M here. The module
will be called ixgbe.
config IXGBE_HWMON
bool "Intel(R) 10GbE PCI Express adapters HWMON support"
default y
depends on IXGBE && HWMON && !(IXGBE=y && HWMON=m)
---help---
Say Y if you want to expose the thermal sensor data on some of
our cards, via a hwmon sysfs interface.
config IXGBE_DCA
bool "Direct Cache Access (DCA) Support"
default y
depends on IXGBE && DCA && !(IXGBE=y && DCA=m)
---help---
Say Y here if you want to use Direct Cache Access (DCA) in the
driver. DCA is a method for warming the CPU cache before data
is used, with the intent of lessening the impact of cache misses.
config IXGBE_DCB
bool "Data Center Bridging (DCB) Support"
default n
depends on IXGBE && DCB
---help---
Say Y here if you want to use Data Center Bridging (DCB) in the
driver.
If unsure, say N.
ixgbe: Hardware Timestamping + PTP Hardware Clock (PHC) This patch enables hardware timestamping for use with PTP software by extracting a ns counter from an arbitrary fixed point cycles counter. The hardware generates SYSTIME registers using the DMA tick which changes based on the current link speed. These SYSTIME registers are converted to ns using the cyclecounter and timecounter structures provided by the kernel. Using the SO_TIMESTAMPING api, software can enable and access timestamps for PTP packets. The SO_TIMESTAMPING API has space for 3 different kinds of timestamps, SYS, RAW, and SOF. SYS hardware timestamps are hardware ns values that are then scaled to the software clock. RAW hardware timestamps are the direct raw value of the ns counter. SOF software timestamps are the software timestamp calculated as close as possible to the software transmit, but are not offloaded to the hardware. This patch only supports the RAW hardware timestamps due to inefficiency of the SYS design. This patch also enables the PHC subsystem features for atomically adjusting the cycle register, and adjusting the clock frequency in parts per billion. This frequency adjustment works by slightly adjusting the value added to the cycle registers each DMA tick. This causes the hardware registers to overflow rapidly (approximately once every 34 seconds, when at 10gig link). To solve this, the timecounter structure is used, along with a timer set for every 25 seconds. This allows for detecting register overflow and converting the cycle counter registers into ns values needed for providing useful timestamps to the network stack. Only the basic required clock functions are supported at this time, although the hardware supports some ancillary features and these could easily be enabled in the future. Note that use of this hardware timestamping requires modifying daemon software to use the SO_TIMESTAMPING API for timestamps, and the ptp_clock PHC framework for accessing the clock. The timestamps have no relation to the system time at all, so software must use the posix clock generated by the PHC framework instead. Signed-off-by: Jacob E Keller <jacob.e.keller@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-05-01 13:24:58 +08:00
config IXGBE_PTP
bool "PTP Clock Support"
default n
depends on IXGBE
select PTP_1588_CLOCK
ixgbe: Hardware Timestamping + PTP Hardware Clock (PHC) This patch enables hardware timestamping for use with PTP software by extracting a ns counter from an arbitrary fixed point cycles counter. The hardware generates SYSTIME registers using the DMA tick which changes based on the current link speed. These SYSTIME registers are converted to ns using the cyclecounter and timecounter structures provided by the kernel. Using the SO_TIMESTAMPING api, software can enable and access timestamps for PTP packets. The SO_TIMESTAMPING API has space for 3 different kinds of timestamps, SYS, RAW, and SOF. SYS hardware timestamps are hardware ns values that are then scaled to the software clock. RAW hardware timestamps are the direct raw value of the ns counter. SOF software timestamps are the software timestamp calculated as close as possible to the software transmit, but are not offloaded to the hardware. This patch only supports the RAW hardware timestamps due to inefficiency of the SYS design. This patch also enables the PHC subsystem features for atomically adjusting the cycle register, and adjusting the clock frequency in parts per billion. This frequency adjustment works by slightly adjusting the value added to the cycle registers each DMA tick. This causes the hardware registers to overflow rapidly (approximately once every 34 seconds, when at 10gig link). To solve this, the timecounter structure is used, along with a timer set for every 25 seconds. This allows for detecting register overflow and converting the cycle counter registers into ns values needed for providing useful timestamps to the network stack. Only the basic required clock functions are supported at this time, although the hardware supports some ancillary features and these could easily be enabled in the future. Note that use of this hardware timestamping requires modifying daemon software to use the SO_TIMESTAMPING API for timestamps, and the ptp_clock PHC framework for accessing the clock. The timestamps have no relation to the system time at all, so software must use the posix clock generated by the PHC framework instead. Signed-off-by: Jacob E Keller <jacob.e.keller@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-05-01 13:24:58 +08:00
---help---
Say Y here if you want support for 1588 Timestamping with a
PHC device, using the PTP 1588 Clock support. This is
required to enable timestamping support for the device.
If unsure, say N.
config IXGBEVF
tristate "Intel(R) 82599 Virtual Function Ethernet support"
depends on PCI_MSI
---help---
This driver supports Intel(R) 82599 virtual functions. For more
information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
<http://support.intel.com/support/network/sb/CS-008441.htm>
For general information and support, go to the Intel support
website at:
<http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/ixgbevf.txt>.
To compile this driver as a module, choose M here. The module
will be called ixgbevf. MSI-X interrupt support is required
for this driver to work correctly.
endif # NET_VENDOR_INTEL