2019-05-19 13:07:45 +01:00
# SPDX-License-Identifier: GPL-2.0-only
2011-04-07 07:42:33 -07:00
#
# Intel network device configuration
#
config NET_VENDOR_INTEL
bool "Intel devices"
2011-08-23 01:29:52 -07:00
default y
2020-06-14 01:50:22 +09:00
help
2015-06-21 16:28:02 -04:00
If you have a network (Ethernet) card belonging to this class, say Y.
2011-04-07 07:42:33 -07:00
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 MII
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
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).
2016-04-05 16:25:07 +02:00
Use the above information and the Adapter & Driver ID Guide that
can be located at:
2011-04-07 07:42:33 -07:00
2016-04-05 16:25:07 +02:00
<http://support.intel.com>
2011-04-07 07:42:33 -07:00
to identify the adapter.
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/e100.rst>.
2011-04-07 07:42:33 -07:00
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
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
2016-04-05 16:25:07 +02:00
to the Adapter & Driver ID Guide that can be located at:
2011-04-07 07:42:33 -07:00
<http://support.intel.com>
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/e1000.rst>.
2011-04-07 07:42:33 -07:00
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)
ethernet: fix PTP_1588_CLOCK dependencies
The 'imply' keyword does not do what most people think it does, it only
politely asks Kconfig to turn on another symbol, but does not prevent
it from being disabled manually or built as a loadable module when the
user is built-in. In the ICE driver, the latter now causes a link failure:
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_eth_ioctl':
ice_main.c:(.text+0x13b0): undefined reference to `ice_ptp_get_ts_config'
ice_main.c:(.text+0x13b0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_get_ts_config'
aarch64-linux-ld: ice_main.c:(.text+0x13bc): undefined reference to `ice_ptp_set_ts_config'
ice_main.c:(.text+0x13bc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_set_ts_config'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_prepare_for_reset':
ice_main.c:(.text+0x31fc): undefined reference to `ice_ptp_release'
ice_main.c:(.text+0x31fc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_release'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_rebuild':
This is a recurring problem in many drivers, and we have discussed
it several times befores, without reaching a consensus. I'm providing
a link to the previous email thread for reference, which discusses
some related problems.
To solve the dependency issue better than the 'imply' keyword, introduce a
separate Kconfig symbol "CONFIG_PTP_1588_CLOCK_OPTIONAL" that any driver
can depend on if it is able to use PTP support when available, but works
fine without it. Whenever CONFIG_PTP_1588_CLOCK=m, those drivers are
then prevented from being built-in, the same way as with a 'depends on
PTP_1588_CLOCK || !PTP_1588_CLOCK' dependency that does the same trick,
but that can be rather confusing when you first see it.
Since this should cover the dependencies correctly, the IS_REACHABLE()
hack in the header is no longer needed now, and can be turned back
into a normal IS_ENABLED() check. Any driver that gets the dependency
wrong will now cause a link time failure rather than being unable to use
PTP support when that is in a loadable module.
However, the two recently added ptp_get_vclocks_index() and
ptp_convert_timestamp() interfaces are only called from builtin code with
ethtool and socket timestamps, so keep the current behavior by stubbing
those out completely when PTP is in a loadable module. This should be
addressed properly in a follow-up.
As Richard suggested, we may want to actually turn PTP support into a
'bool' option later on, preventing it from being a loadable module
altogether, which would be one way to solve the problem with the ethtool
interface.
Fixes: 06c16d89d2cb ("ice: register 1588 PTP clock device object for E810 devices")
Link: https://lore.kernel.org/netdev/20210804121318.337276-1-arnd@kernel.org/
Link: https://lore.kernel.org/netdev/CAK8P3a06enZOf=XyZ+zcAwBczv41UuCTz+=0FMf2gBz1_cOnZQ@mail.gmail.com/
Link: https://lore.kernel.org/netdev/CAK8P3a3=eOxE-K25754+fB_-i_0BZzf9a9RfPTX3ppSwu9WZXw@mail.gmail.com/
Link: https://lore.kernel.org/netdev/20210726084540.3282344-1-arnd@kernel.org/
Acked-by: Shannon Nelson <snelson@pensando.io>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210812183509.1362782-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-12 20:33:58 +02:00
depends on PTP_1588_CLOCK_OPTIONAL
2011-04-07 07:42:33 -07:00
select CRC32
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
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
2016-04-05 16:25:07 +02:00
identify your adapter, go to the Adapter & Driver ID Guide that
can be located at:
2011-04-07 07:42:33 -07:00
<http://support.intel.com>
2018-10-10 12:16:13 -07:00
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/e1000e.rst>.
2018-10-10 12:16:13 -07:00
2011-04-07 07:42:33 -07:00
To compile this driver as a module, choose M here. The module
will be called e1000e.
2016-02-22 03:15:26 -08:00
config E1000E_HWTS
bool "Support HW cross-timestamp on PCH devices"
default y
depends on E1000E && X86
2020-06-14 01:50:22 +09:00
help
2016-02-22 03:15:26 -08:00
Say Y to enable hardware supported cross-timestamping on PCH
devices. The cross-timestamp is available through the PTP clock
driver precise cross-timestamp ioctl (PTP_SYS_OFFSET_PRECISE).
2011-04-07 07:42:33 -07:00
config IGB
tristate "Intel(R) 82575/82576 PCI-Express Gigabit Ethernet support"
depends on PCI
ethernet: fix PTP_1588_CLOCK dependencies
The 'imply' keyword does not do what most people think it does, it only
politely asks Kconfig to turn on another symbol, but does not prevent
it from being disabled manually or built as a loadable module when the
user is built-in. In the ICE driver, the latter now causes a link failure:
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_eth_ioctl':
ice_main.c:(.text+0x13b0): undefined reference to `ice_ptp_get_ts_config'
ice_main.c:(.text+0x13b0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_get_ts_config'
aarch64-linux-ld: ice_main.c:(.text+0x13bc): undefined reference to `ice_ptp_set_ts_config'
ice_main.c:(.text+0x13bc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_set_ts_config'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_prepare_for_reset':
ice_main.c:(.text+0x31fc): undefined reference to `ice_ptp_release'
ice_main.c:(.text+0x31fc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_release'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_rebuild':
This is a recurring problem in many drivers, and we have discussed
it several times befores, without reaching a consensus. I'm providing
a link to the previous email thread for reference, which discusses
some related problems.
To solve the dependency issue better than the 'imply' keyword, introduce a
separate Kconfig symbol "CONFIG_PTP_1588_CLOCK_OPTIONAL" that any driver
can depend on if it is able to use PTP support when available, but works
fine without it. Whenever CONFIG_PTP_1588_CLOCK=m, those drivers are
then prevented from being built-in, the same way as with a 'depends on
PTP_1588_CLOCK || !PTP_1588_CLOCK' dependency that does the same trick,
but that can be rather confusing when you first see it.
Since this should cover the dependencies correctly, the IS_REACHABLE()
hack in the header is no longer needed now, and can be turned back
into a normal IS_ENABLED() check. Any driver that gets the dependency
wrong will now cause a link time failure rather than being unable to use
PTP support when that is in a loadable module.
However, the two recently added ptp_get_vclocks_index() and
ptp_convert_timestamp() interfaces are only called from builtin code with
ethtool and socket timestamps, so keep the current behavior by stubbing
those out completely when PTP is in a loadable module. This should be
addressed properly in a follow-up.
As Richard suggested, we may want to actually turn PTP support into a
'bool' option later on, preventing it from being a loadable module
altogether, which would be one way to solve the problem with the ethtool
interface.
Fixes: 06c16d89d2cb ("ice: register 1588 PTP clock device object for E810 devices")
Link: https://lore.kernel.org/netdev/20210804121318.337276-1-arnd@kernel.org/
Link: https://lore.kernel.org/netdev/CAK8P3a06enZOf=XyZ+zcAwBczv41UuCTz+=0FMf2gBz1_cOnZQ@mail.gmail.com/
Link: https://lore.kernel.org/netdev/CAK8P3a3=eOxE-K25754+fB_-i_0BZzf9a9RfPTX3ppSwu9WZXw@mail.gmail.com/
Link: https://lore.kernel.org/netdev/20210726084540.3282344-1-arnd@kernel.org/
Acked-by: Shannon Nelson <snelson@pensando.io>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210812183509.1362782-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-12 20:33:58 +02:00
depends on PTP_1588_CLOCK_OPTIONAL
2012-12-07 03:00:30 +00:00
select I2C
select I2C_ALGOBIT
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
This driver supports Intel(R) 82575/82576 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
2016-04-05 16:25:07 +02:00
to the Adapter & Driver ID Guide that can be located at:
2011-04-07 07:42:33 -07:00
<http://support.intel.com>
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/igb.rst>.
2011-04-07 07:42:33 -07:00
To compile this driver as a module, choose M here. The module
will be called igb.
2012-12-07 03:01:42 +00:00
config IGB_HWMON
bool "Intel(R) PCI-Express Gigabit adapters HWMON support"
default y
depends on IGB && HWMON && !(IGB=y && HWMON=m)
2020-06-14 01:50:22 +09:00
help
2012-12-07 03:01:42 +00:00
Say Y if you want to expose thermal sensor data on Intel devices.
Some of our devices contain thermal sensors, both external and internal.
This data is available via the hwmon sysfs interface and exposes
the onboard sensors.
2011-04-07 07:42:33 -07:00
config IGB_DCA
bool "Direct Cache Access (DCA) Support"
default y
depends on IGB && DCA && !(IGB=y && DCA=m)
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
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 IGBVF
tristate "Intel(R) 82576 Virtual Function Ethernet support"
depends on PCI
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
This driver supports Intel(R) 82576 virtual functions. For more
information on how to identify your adapter, go to the Adapter &
2016-04-05 16:25:07 +02:00
Driver ID Guide that can be located at:
2011-04-07 07:42:33 -07:00
<http://support.intel.com>
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/igbvf.rst>.
2011-04-07 07:42:33 -07:00
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
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
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
2016-04-05 16:25:07 +02:00
to the Adapter & Driver ID Guide that can be located at:
2011-04-07 07:42:33 -07:00
<http://support.intel.com>
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/ixgb.rst>.
2011-04-07 07:42:33 -07:00
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"
2012-11-16 12:47:39 +00:00
depends on PCI
ethernet: fix PTP_1588_CLOCK dependencies
The 'imply' keyword does not do what most people think it does, it only
politely asks Kconfig to turn on another symbol, but does not prevent
it from being disabled manually or built as a loadable module when the
user is built-in. In the ICE driver, the latter now causes a link failure:
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_eth_ioctl':
ice_main.c:(.text+0x13b0): undefined reference to `ice_ptp_get_ts_config'
ice_main.c:(.text+0x13b0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_get_ts_config'
aarch64-linux-ld: ice_main.c:(.text+0x13bc): undefined reference to `ice_ptp_set_ts_config'
ice_main.c:(.text+0x13bc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_set_ts_config'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_prepare_for_reset':
ice_main.c:(.text+0x31fc): undefined reference to `ice_ptp_release'
ice_main.c:(.text+0x31fc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_release'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_rebuild':
This is a recurring problem in many drivers, and we have discussed
it several times befores, without reaching a consensus. I'm providing
a link to the previous email thread for reference, which discusses
some related problems.
To solve the dependency issue better than the 'imply' keyword, introduce a
separate Kconfig symbol "CONFIG_PTP_1588_CLOCK_OPTIONAL" that any driver
can depend on if it is able to use PTP support when available, but works
fine without it. Whenever CONFIG_PTP_1588_CLOCK=m, those drivers are
then prevented from being built-in, the same way as with a 'depends on
PTP_1588_CLOCK || !PTP_1588_CLOCK' dependency that does the same trick,
but that can be rather confusing when you first see it.
Since this should cover the dependencies correctly, the IS_REACHABLE()
hack in the header is no longer needed now, and can be turned back
into a normal IS_ENABLED() check. Any driver that gets the dependency
wrong will now cause a link time failure rather than being unable to use
PTP support when that is in a loadable module.
However, the two recently added ptp_get_vclocks_index() and
ptp_convert_timestamp() interfaces are only called from builtin code with
ethtool and socket timestamps, so keep the current behavior by stubbing
those out completely when PTP is in a loadable module. This should be
addressed properly in a follow-up.
As Richard suggested, we may want to actually turn PTP support into a
'bool' option later on, preventing it from being a loadable module
altogether, which would be one way to solve the problem with the ethtool
interface.
Fixes: 06c16d89d2cb ("ice: register 1588 PTP clock device object for E810 devices")
Link: https://lore.kernel.org/netdev/20210804121318.337276-1-arnd@kernel.org/
Link: https://lore.kernel.org/netdev/CAK8P3a06enZOf=XyZ+zcAwBczv41UuCTz+=0FMf2gBz1_cOnZQ@mail.gmail.com/
Link: https://lore.kernel.org/netdev/CAK8P3a3=eOxE-K25754+fB_-i_0BZzf9a9RfPTX3ppSwu9WZXw@mail.gmail.com/
Link: https://lore.kernel.org/netdev/20210726084540.3282344-1-arnd@kernel.org/
Acked-by: Shannon Nelson <snelson@pensando.io>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210812183509.1362782-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-12 20:33:58 +02:00
depends on PTP_1588_CLOCK_OPTIONAL
2011-04-07 07:42:33 -07:00
select MDIO
2019-01-04 10:48:02 -08:00
select PHYLIB
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
This driver supports Intel(R) 10GbE PCI Express family of
adapters. For more information on how to identify your adapter, go
2016-04-05 16:25:07 +02:00
to the Adapter & Driver ID Guide that can be located at:
2011-04-07 07:42:33 -07:00
<http://support.intel.com>
2018-10-10 12:16:13 -07:00
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst>.
2018-10-10 12:16:13 -07:00
2011-04-07 07:42:33 -07:00
To compile this driver as a module, choose M here. The module
will be called ixgbe.
2012-04-12 00:33:31 +00:00
config IXGBE_HWMON
bool "Intel(R) 10GbE PCI Express adapters HWMON support"
default y
depends on IXGBE && HWMON && !(IXGBE=y && HWMON=m)
2020-06-14 01:50:22 +09:00
help
2012-04-12 00:33:31 +00:00
Say Y if you want to expose the thermal sensor data on some of
our cards, via a hwmon sysfs interface.
2011-04-07 07:42:33 -07:00
config IXGBE_DCA
bool "Direct Cache Access (DCA) Support"
default y
depends on IXGBE && DCA && !(IXGBE=y && DCA=m)
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
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
2020-06-14 01:50:22 +09:00
help
2011-04-07 07:42:33 -07:00
Say Y here if you want to use Data Center Bridging (DCB) in the
driver.
If unsure, say N.
2018-10-18 15:39:43 -07:00
config IXGBE_IPSEC
bool "IPSec XFRM cryptography-offload acceleration"
depends on IXGBE
depends on XFRM_OFFLOAD
default y
select XFRM_ALGO
2020-06-14 01:50:22 +09:00
help
2018-10-18 15:39:43 -07:00
Enable support for IPSec offload in ixgbe.ko
2011-04-07 07:42:33 -07:00
config IXGBEVF
2013-11-22 05:58:15 +00:00
tristate "Intel(R) 10GbE PCI Express Virtual Function Ethernet support"
2011-04-07 07:42:33 -07:00
depends on PCI_MSI
2020-06-14 01:50:22 +09:00
help
2013-11-22 05:58:15 +00:00
This driver supports Intel(R) PCI Express virtual functions for the
Intel(R) ixgbe driver. For more information on how to identify your
2016-04-05 16:25:07 +02:00
adapter, go to the Adapter & Driver ID Guide that can be located at:
2011-04-07 07:42:33 -07:00
<http://support.intel.com>
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst>.
2011-04-07 07:42:33 -07:00
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.
2018-10-18 15:39:43 -07:00
config IXGBEVF_IPSEC
bool "IPSec XFRM cryptography-offload acceleration"
depends on IXGBEVF
depends on XFRM_OFFLOAD
default y
select XFRM_ALGO
2020-06-14 01:50:22 +09:00
help
2018-10-18 15:39:43 -07:00
Enable support for IPSec offload in ixgbevf.ko
2013-09-11 08:40:23 +00:00
config I40E
tristate "Intel(R) Ethernet Controller XL710 Family support"
ethernet: fix PTP_1588_CLOCK dependencies
The 'imply' keyword does not do what most people think it does, it only
politely asks Kconfig to turn on another symbol, but does not prevent
it from being disabled manually or built as a loadable module when the
user is built-in. In the ICE driver, the latter now causes a link failure:
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_eth_ioctl':
ice_main.c:(.text+0x13b0): undefined reference to `ice_ptp_get_ts_config'
ice_main.c:(.text+0x13b0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_get_ts_config'
aarch64-linux-ld: ice_main.c:(.text+0x13bc): undefined reference to `ice_ptp_set_ts_config'
ice_main.c:(.text+0x13bc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_set_ts_config'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_prepare_for_reset':
ice_main.c:(.text+0x31fc): undefined reference to `ice_ptp_release'
ice_main.c:(.text+0x31fc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_release'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_rebuild':
This is a recurring problem in many drivers, and we have discussed
it several times befores, without reaching a consensus. I'm providing
a link to the previous email thread for reference, which discusses
some related problems.
To solve the dependency issue better than the 'imply' keyword, introduce a
separate Kconfig symbol "CONFIG_PTP_1588_CLOCK_OPTIONAL" that any driver
can depend on if it is able to use PTP support when available, but works
fine without it. Whenever CONFIG_PTP_1588_CLOCK=m, those drivers are
then prevented from being built-in, the same way as with a 'depends on
PTP_1588_CLOCK || !PTP_1588_CLOCK' dependency that does the same trick,
but that can be rather confusing when you first see it.
Since this should cover the dependencies correctly, the IS_REACHABLE()
hack in the header is no longer needed now, and can be turned back
into a normal IS_ENABLED() check. Any driver that gets the dependency
wrong will now cause a link time failure rather than being unable to use
PTP support when that is in a loadable module.
However, the two recently added ptp_get_vclocks_index() and
ptp_convert_timestamp() interfaces are only called from builtin code with
ethtool and socket timestamps, so keep the current behavior by stubbing
those out completely when PTP is in a loadable module. This should be
addressed properly in a follow-up.
As Richard suggested, we may want to actually turn PTP support into a
'bool' option later on, preventing it from being a loadable module
altogether, which would be one way to solve the problem with the ethtool
interface.
Fixes: 06c16d89d2cb ("ice: register 1588 PTP clock device object for E810 devices")
Link: https://lore.kernel.org/netdev/20210804121318.337276-1-arnd@kernel.org/
Link: https://lore.kernel.org/netdev/CAK8P3a06enZOf=XyZ+zcAwBczv41UuCTz+=0FMf2gBz1_cOnZQ@mail.gmail.com/
Link: https://lore.kernel.org/netdev/CAK8P3a3=eOxE-K25754+fB_-i_0BZzf9a9RfPTX3ppSwu9WZXw@mail.gmail.com/
Link: https://lore.kernel.org/netdev/20210726084540.3282344-1-arnd@kernel.org/
Acked-by: Shannon Nelson <snelson@pensando.io>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210812183509.1362782-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-12 20:33:58 +02:00
depends on PTP_1588_CLOCK_OPTIONAL
2013-09-11 08:40:23 +00:00
depends on PCI
2021-05-21 10:11:20 -07:00
select AUXILIARY_BUS
2020-06-14 01:50:22 +09:00
help
2013-09-11 08:40:23 +00:00
This driver supports Intel(R) Ethernet Controller XL710 Family of
devices. For more information on how to identify your adapter, go
2016-04-05 16:25:07 +02:00
to the Adapter & Driver ID Guide that can be located at:
2013-09-11 08:40:23 +00:00
<http://support.intel.com>
2018-10-10 12:16:13 -07:00
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/i40e.rst>.
2018-10-10 12:16:13 -07:00
2013-09-11 08:40:23 +00:00
To compile this driver as a module, choose M here. The module
will be called i40e.
2014-01-17 15:36:38 -08:00
config I40E_DCB
bool "Data Center Bridging (DCB) Support"
default n
depends on I40E && DCB
2020-06-14 01:50:22 +09:00
help
2014-01-17 15:36:38 -08:00
Say Y here if you want to use Data Center Bridging (DCB) in the
driver.
2013-12-28 07:32:18 +00:00
If unsure, say N.
2018-09-14 17:37:44 -07:00
# this is here to allow seamless migration from I40EVF --> IAVF name
# so that CONFIG_IAVF symbol will always mirror the state of CONFIG_I40EVF
config IAVF
tristate
2013-12-21 06:13:16 +00:00
config I40EVF
2017-05-11 11:23:20 -07:00
tristate "Intel(R) Ethernet Adaptive Virtual Function support"
2018-09-14 17:37:44 -07:00
select IAVF
2013-12-21 06:13:16 +00:00
depends on PCI_MSI
2020-06-14 01:50:22 +09:00
help
2017-05-11 11:23:20 -07:00
This driver supports virtual functions for Intel XL710,
2018-09-14 17:37:44 -07:00
X710, X722, XXV710, and all devices advertising support for
Intel Ethernet Adaptive Virtual Function devices. For more
2017-05-11 11:23:20 -07:00
information on how to identify your adapter, go to the Adapter
& Driver ID Guide that can be located at:
2013-12-21 06:13:16 +00:00
2018-09-14 17:37:44 -07:00
<https://support.intel.com>
This driver was formerly named i40evf.
2013-12-21 06:13:16 +00:00
2018-10-10 12:16:13 -07:00
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/iavf.rst>.
2018-10-10 12:16:13 -07:00
2013-12-21 06:13:16 +00:00
To compile this driver as a module, choose M here. The module
2018-09-14 17:37:44 -07:00
will be called iavf. MSI-X interrupt support is required
2013-12-21 06:13:16 +00:00
for this driver to work correctly.
2018-03-20 07:58:05 -07:00
config ICE
tristate "Intel(R) Ethernet Connection E800 Series Support"
default n
depends on PCI_MSI
ethernet: fix PTP_1588_CLOCK dependencies
The 'imply' keyword does not do what most people think it does, it only
politely asks Kconfig to turn on another symbol, but does not prevent
it from being disabled manually or built as a loadable module when the
user is built-in. In the ICE driver, the latter now causes a link failure:
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_eth_ioctl':
ice_main.c:(.text+0x13b0): undefined reference to `ice_ptp_get_ts_config'
ice_main.c:(.text+0x13b0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_get_ts_config'
aarch64-linux-ld: ice_main.c:(.text+0x13bc): undefined reference to `ice_ptp_set_ts_config'
ice_main.c:(.text+0x13bc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_set_ts_config'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_prepare_for_reset':
ice_main.c:(.text+0x31fc): undefined reference to `ice_ptp_release'
ice_main.c:(.text+0x31fc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_release'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_rebuild':
This is a recurring problem in many drivers, and we have discussed
it several times befores, without reaching a consensus. I'm providing
a link to the previous email thread for reference, which discusses
some related problems.
To solve the dependency issue better than the 'imply' keyword, introduce a
separate Kconfig symbol "CONFIG_PTP_1588_CLOCK_OPTIONAL" that any driver
can depend on if it is able to use PTP support when available, but works
fine without it. Whenever CONFIG_PTP_1588_CLOCK=m, those drivers are
then prevented from being built-in, the same way as with a 'depends on
PTP_1588_CLOCK || !PTP_1588_CLOCK' dependency that does the same trick,
but that can be rather confusing when you first see it.
Since this should cover the dependencies correctly, the IS_REACHABLE()
hack in the header is no longer needed now, and can be turned back
into a normal IS_ENABLED() check. Any driver that gets the dependency
wrong will now cause a link time failure rather than being unable to use
PTP support when that is in a loadable module.
However, the two recently added ptp_get_vclocks_index() and
ptp_convert_timestamp() interfaces are only called from builtin code with
ethtool and socket timestamps, so keep the current behavior by stubbing
those out completely when PTP is in a loadable module. This should be
addressed properly in a follow-up.
As Richard suggested, we may want to actually turn PTP support into a
'bool' option later on, preventing it from being a loadable module
altogether, which would be one way to solve the problem with the ethtool
interface.
Fixes: 06c16d89d2cb ("ice: register 1588 PTP clock device object for E810 devices")
Link: https://lore.kernel.org/netdev/20210804121318.337276-1-arnd@kernel.org/
Link: https://lore.kernel.org/netdev/CAK8P3a06enZOf=XyZ+zcAwBczv41UuCTz+=0FMf2gBz1_cOnZQ@mail.gmail.com/
Link: https://lore.kernel.org/netdev/CAK8P3a3=eOxE-K25754+fB_-i_0BZzf9a9RfPTX3ppSwu9WZXw@mail.gmail.com/
Link: https://lore.kernel.org/netdev/20210726084540.3282344-1-arnd@kernel.org/
Acked-by: Shannon Nelson <snelson@pensando.io>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210812183509.1362782-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-12 20:33:58 +02:00
depends on PTP_1588_CLOCK_OPTIONAL
2021-05-20 09:37:51 -05:00
select AUXILIARY_BUS
ice: replace custom AIM algorithm with kernel's DIM library
The ice driver has support for adaptive interrupt moderation, an
algorithm for tuning the interrupt rate dynamically. This algorithm
is based on various assumptions about ring size, socket buffer size,
link speed, SKB overhead, ethernet frame overhead and more.
The Linux kernel has support for a dynamic interrupt moderation
algorithm known as "dimlib". Replace the custom driver-specific
implementation of dynamic interrupt moderation with the kernel's
algorithm.
The Intel hardware has a different hardware implementation than the
originators of the dimlib code had to work with, which requires the
driver to use a slightly different set of inputs for the actual
moderation values, while getting all the advice from dimlib of
better/worse, shift left or right.
The change made for this implementation is to use a pair of values
for each of the 5 "slots" that the dimlib moderation expects, and
the driver will program those pairs when dimlib recommends a slot to
use. The currently implementation uses two tables, one for receive
and one for transmit, and the pairs of values in each slot set the
maximum delay of an interrupt and a maximum number of interrupts per
second (both expressed in microseconds).
There are two separate kinds of bugs fixed by using DIMLIB, one is
UDP single stream send was too slow, and the other is that 8K
ping-pong was going to the most aggressive moderation and has much
too high latency.
The overall result of using DIMLIB is that we meet or exceed our
performance expectations set based on the old algorithm.
Co-developed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-31 14:16:57 -07:00
select DIMLIB
2020-03-11 18:58:15 -07:00
select NET_DEVLINK
ice: implement device flash update via devlink
Use the newly added pldmfw library to implement device flash update for
the Intel ice networking device driver. This support uses the devlink
flash update interface.
The main parts of the flash include the Option ROM, the netlist module,
and the main NVM data. The PLDM firmware file contains modules for each
of these components.
Using the pldmfw library, the provided firmware file will be scanned for
the three major components, "fw.undi" for the Option ROM, "fw.mgmt" for
the main NVM module containing the primary device firmware, and
"fw.netlist" containing the netlist module.
The flash is separated into two banks, the active bank containing the
running firmware, and the inactive bank which we use for update. Each
module is updated in a staged process. First, the inactive bank is
erased, preparing the device for update. Second, the contents of the
component are copied to the inactive portion of the flash. After all
components are updated, the driver signals the device to switch the
active bank during the next EMP reset (which would usually occur during
the next reboot).
Although the firmware AdminQ interface does report an immediate status
for each command, the NVM erase and NVM write commands receive status
asynchronously. The driver must not continue writing until previous
erase and write commands have finished. The real status of the NVM
commands is returned over the receive AdminQ. Implement a simple
interface that uses a wait queue so that the main update thread can
sleep until the completion status is reported by firmware. For erasing
the inactive banks, this can take quite a while in practice.
To help visualize the process to the devlink application and other
applications based on the devlink netlink interface, status is reported
via the devlink_flash_update_status_notify. While we do report status
after each 4k block when writing, there is no real status we can report
during erasing. We simply must wait for the complete module erasure to
finish.
With this implementation, basic flash update for the ice hardware is
supported.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-23 17:22:03 -07:00
select PLDMFW
2020-06-14 01:50:22 +09:00
help
2018-03-20 07:58:05 -07:00
This driver supports Intel(R) Ethernet Connection E800 Series of
devices. For more information on how to identify your adapter, go
to the Adapter & Driver ID Guide that can be located at:
<http://support.intel.com>
2018-10-10 12:16:13 -07:00
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/ice.rst>.
2018-10-10 12:16:13 -07:00
2018-03-20 07:58:05 -07:00
To compile this driver as a module, choose M here. The module
will be called ice.
2021-08-19 17:08:48 -07:00
config ICE_SWITCHDEV
bool "Switchdev Support"
default y
depends on ICE && NET_SWITCHDEV
help
Switchdev support provides internal SRIOV packet steering and switching.
To enable it on running kernel use devlink tool:
#devlink dev eswitch set pci/0000:XX:XX.X mode switchdev
Say Y here if you want to use Switchdev in the driver.
If unsure, say N.
2021-10-13 09:00:08 -07:00
config ICE_HWTS
bool "Support HW cross-timestamp on platforms with PTM support"
default y
depends on ICE && X86
help
Say Y to enable hardware supported cross-timestamping on platforms
with PCIe PTM support. The cross-timestamp is available through
the PTP clock driver precise cross-timestamp ioctl
(PTP_SYS_OFFSET_PRECISE).
2014-09-20 19:46:05 -04:00
config FM10K
tristate "Intel(R) FM10000 Ethernet Switch Host Interface Support"
default n
depends on PCI_MSI
ethernet: fix PTP_1588_CLOCK dependencies
The 'imply' keyword does not do what most people think it does, it only
politely asks Kconfig to turn on another symbol, but does not prevent
it from being disabled manually or built as a loadable module when the
user is built-in. In the ICE driver, the latter now causes a link failure:
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_eth_ioctl':
ice_main.c:(.text+0x13b0): undefined reference to `ice_ptp_get_ts_config'
ice_main.c:(.text+0x13b0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_get_ts_config'
aarch64-linux-ld: ice_main.c:(.text+0x13bc): undefined reference to `ice_ptp_set_ts_config'
ice_main.c:(.text+0x13bc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_set_ts_config'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_prepare_for_reset':
ice_main.c:(.text+0x31fc): undefined reference to `ice_ptp_release'
ice_main.c:(.text+0x31fc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `ice_ptp_release'
aarch64-linux-ld: drivers/net/ethernet/intel/ice/ice_main.o: in function `ice_rebuild':
This is a recurring problem in many drivers, and we have discussed
it several times befores, without reaching a consensus. I'm providing
a link to the previous email thread for reference, which discusses
some related problems.
To solve the dependency issue better than the 'imply' keyword, introduce a
separate Kconfig symbol "CONFIG_PTP_1588_CLOCK_OPTIONAL" that any driver
can depend on if it is able to use PTP support when available, but works
fine without it. Whenever CONFIG_PTP_1588_CLOCK=m, those drivers are
then prevented from being built-in, the same way as with a 'depends on
PTP_1588_CLOCK || !PTP_1588_CLOCK' dependency that does the same trick,
but that can be rather confusing when you first see it.
Since this should cover the dependencies correctly, the IS_REACHABLE()
hack in the header is no longer needed now, and can be turned back
into a normal IS_ENABLED() check. Any driver that gets the dependency
wrong will now cause a link time failure rather than being unable to use
PTP support when that is in a loadable module.
However, the two recently added ptp_get_vclocks_index() and
ptp_convert_timestamp() interfaces are only called from builtin code with
ethtool and socket timestamps, so keep the current behavior by stubbing
those out completely when PTP is in a loadable module. This should be
addressed properly in a follow-up.
As Richard suggested, we may want to actually turn PTP support into a
'bool' option later on, preventing it from being a loadable module
altogether, which would be one way to solve the problem with the ethtool
interface.
Fixes: 06c16d89d2cb ("ice: register 1588 PTP clock device object for E810 devices")
Link: https://lore.kernel.org/netdev/20210804121318.337276-1-arnd@kernel.org/
Link: https://lore.kernel.org/netdev/CAK8P3a06enZOf=XyZ+zcAwBczv41UuCTz+=0FMf2gBz1_cOnZQ@mail.gmail.com/
Link: https://lore.kernel.org/netdev/CAK8P3a3=eOxE-K25754+fB_-i_0BZzf9a9RfPTX3ppSwu9WZXw@mail.gmail.com/
Link: https://lore.kernel.org/netdev/20210726084540.3282344-1-arnd@kernel.org/
Acked-by: Shannon Nelson <snelson@pensando.io>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210812183509.1362782-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-12 20:33:58 +02:00
depends on PTP_1588_CLOCK_OPTIONAL
2020-06-14 01:50:22 +09:00
help
2014-09-20 19:46:05 -04:00
This driver supports Intel(R) FM10000 Ethernet Switch Host
Interface. For more information on how to identify your adapter,
2016-04-05 16:25:07 +02:00
go to the Adapter & Driver ID Guide that can be located at:
2014-09-20 19:46:05 -04:00
<http://support.intel.com>
2018-10-10 12:16:12 -07:00
More specific information on configuring the driver is in
2020-06-26 10:27:24 -07:00
<file:Documentation/networking/device_drivers/ethernet/intel/fm10k.rst>.
2018-10-10 12:16:12 -07:00
2014-09-20 19:46:05 -04:00
To compile this driver as a module, choose M here. The module
will be called fm10k. MSI-X interrupt support is required
2018-10-11 10:17:08 +03:00
config IGC
tristate "Intel(R) Ethernet Controller I225-LM/I225-V support"
default n
depends on PCI
2021-09-17 14:05:47 -07:00
depends on PTP_1588_CLOCK_OPTIONAL
2020-06-14 01:50:22 +09:00
help
2018-10-11 10:17:08 +03:00
This driver supports Intel(R) Ethernet Controller I225-LM/I225-V
family of adapters.
For more information on how to identify your adapter, go
to the Adapter & Driver ID Guide that can be located at:
<http://support.intel.com>
To compile this driver as a module, choose M here. The module
will be called igc.
2011-04-07 07:42:33 -07:00
endif # NET_VENDOR_INTEL
