2019-05-19 20:07:45 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2011-04-07 22:42:33 +08:00
|
|
|
#
|
|
|
|
|
# Intel network device configuration
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
config NET_VENDOR_INTEL
|
|
|
|
|
bool "Intel devices"
|
2011-08-23 16:29:52 +08:00
|
|
|
default y
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2015-06-22 04:28:02 +08:00
|
|
|
If you have a network (Ethernet) card belonging to this class, say Y.
|
2011-04-07 22:42:33 +08: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 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 22:25:07 +08:00
|
|
|
Use the above information and the Adapter & Driver ID Guide that
|
|
|
|
|
can be located at:
|
2011-04-07 22:42:33 +08:00
|
|
|
|
2016-04-05 22:25:07 +08:00
|
|
|
<http://support.intel.com>
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
to identify the adapter.
|
|
|
|
|
|
|
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/e100.rst>.
|
2011-04-07 22:42:33 +08: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 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 22:25:07 +08:00
|
|
|
to the Adapter & Driver ID Guide that can be located at:
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
|
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/e1000.rst>.
|
2011-04-07 22:42:33 +08: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-13 02:33:58 +08:00
|
|
|
depends on PTP_1588_CLOCK_OPTIONAL
|
2011-04-07 22:42:33 +08:00
|
|
|
select CRC32
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 22:25:07 +08:00
|
|
|
identify your adapter, go to the Adapter & Driver ID Guide that
|
|
|
|
|
can be located at:
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
2018-10-11 03:16:13 +08:00
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/e1000e.rst>.
|
2018-10-11 03:16:13 +08:00
|
|
|
|
2011-04-07 22:42:33 +08:00
|
|
|
To compile this driver as a module, choose M here. The module
|
|
|
|
|
will be called e1000e.
|
|
|
|
|
|
2016-02-22 19:15:26 +08:00
|
|
|
config E1000E_HWTS
|
|
|
|
|
bool "Support HW cross-timestamp on PCH devices"
|
|
|
|
|
default y
|
|
|
|
|
depends on E1000E && X86
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2016-02-22 19: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 22:42:33 +08: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-13 02:33:58 +08:00
|
|
|
depends on PTP_1588_CLOCK_OPTIONAL
|
2012-12-07 11:00:30 +08:00
|
|
|
select I2C
|
|
|
|
|
select I2C_ALGOBIT
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 22:25:07 +08:00
|
|
|
to the Adapter & Driver ID Guide that can be located at:
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
|
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/igb.rst>.
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here. The module
|
|
|
|
|
will be called igb.
|
|
|
|
|
|
2012-12-07 11:01:42 +08: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 00:50:22 +08:00
|
|
|
help
|
2012-12-07 11:01:42 +08: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 22:42:33 +08:00
|
|
|
config IGB_DCA
|
|
|
|
|
bool "Direct Cache Access (DCA) Support"
|
|
|
|
|
default y
|
|
|
|
|
depends on IGB && DCA && !(IGB=y && DCA=m)
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 22:25:07 +08:00
|
|
|
Driver ID Guide that can be located at:
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
|
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/igbvf.rst>.
|
2011-04-07 22:42:33 +08: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 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 22:25:07 +08:00
|
|
|
to the Adapter & Driver ID Guide that can be located at:
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
|
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/ixgb.rst>.
|
2011-04-07 22:42:33 +08: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 20:47:39 +08: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-13 02:33:58 +08:00
|
|
|
depends on PTP_1588_CLOCK_OPTIONAL
|
2011-04-07 22:42:33 +08:00
|
|
|
select MDIO
|
2019-01-05 02:48:02 +08:00
|
|
|
select PHYLIB
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 22:25:07 +08:00
|
|
|
to the Adapter & Driver ID Guide that can be located at:
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
2018-10-11 03:16:13 +08:00
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst>.
|
2018-10-11 03:16:13 +08:00
|
|
|
|
2011-04-07 22:42:33 +08:00
|
|
|
To compile this driver as a module, choose M here. The module
|
|
|
|
|
will be called ixgbe.
|
|
|
|
|
|
2012-04-12 08:33:31 +08: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 00:50:22 +08:00
|
|
|
help
|
2012-04-12 08:33:31 +08: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 22:42:33 +08:00
|
|
|
config IXGBE_DCA
|
|
|
|
|
bool "Direct Cache Access (DCA) Support"
|
|
|
|
|
default y
|
|
|
|
|
depends on IXGBE && DCA && !(IXGBE=y && DCA=m)
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08: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 00:50:22 +08:00
|
|
|
help
|
2011-04-07 22:42:33 +08:00
|
|
|
Say Y here if you want to use Data Center Bridging (DCB) in the
|
|
|
|
|
driver.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2018-10-19 06:39:43 +08: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 00:50:22 +08:00
|
|
|
help
|
2018-10-19 06:39:43 +08:00
|
|
|
Enable support for IPSec offload in ixgbe.ko
|
|
|
|
|
|
2011-04-07 22:42:33 +08:00
|
|
|
config IXGBEVF
|
2013-11-22 13:58:15 +08:00
|
|
|
tristate "Intel(R) 10GbE PCI Express Virtual Function Ethernet support"
|
2011-04-07 22:42:33 +08:00
|
|
|
depends on PCI_MSI
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2013-11-22 13:58:15 +08: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 22:25:07 +08:00
|
|
|
adapter, go to the Adapter & Driver ID Guide that can be located at:
|
2011-04-07 22:42:33 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
|
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst>.
|
2011-04-07 22:42:33 +08: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-19 06:39:43 +08: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 00:50:22 +08:00
|
|
|
help
|
2018-10-19 06:39:43 +08:00
|
|
|
Enable support for IPSec offload in ixgbevf.ko
|
|
|
|
|
|
2013-09-11 16:40:23 +08: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-13 02:33:58 +08:00
|
|
|
depends on PTP_1588_CLOCK_OPTIONAL
|
2013-09-11 16:40:23 +08:00
|
|
|
depends on PCI
|
2021-05-22 01:11:20 +08:00
|
|
|
select AUXILIARY_BUS
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2013-09-11 16:40:23 +08: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 22:25:07 +08:00
|
|
|
to the Adapter & Driver ID Guide that can be located at:
|
2013-09-11 16:40:23 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
2018-10-11 03:16:13 +08:00
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/i40e.rst>.
|
2018-10-11 03:16:13 +08:00
|
|
|
|
2013-09-11 16:40:23 +08:00
|
|
|
To compile this driver as a module, choose M here. The module
|
|
|
|
|
will be called i40e.
|
|
|
|
|
|
2014-01-18 07:36:38 +08:00
|
|
|
config I40E_DCB
|
|
|
|
|
bool "Data Center Bridging (DCB) Support"
|
|
|
|
|
default n
|
|
|
|
|
depends on I40E && DCB
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2014-01-18 07:36:38 +08:00
|
|
|
Say Y here if you want to use Data Center Bridging (DCB) in the
|
|
|
|
|
driver.
|
|
|
|
|
|
2013-12-28 15:32:18 +08:00
|
|
|
If unsure, say N.
|
|
|
|
|
|
2018-09-15 08:37:44 +08: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 14:13:16 +08:00
|
|
|
config I40EVF
|
2017-05-12 02:23:20 +08:00
|
|
|
tristate "Intel(R) Ethernet Adaptive Virtual Function support"
|
2018-09-15 08:37:44 +08:00
|
|
|
select IAVF
|
2013-12-21 14:13:16 +08:00
|
|
|
depends on PCI_MSI
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2017-05-12 02:23:20 +08:00
|
|
|
This driver supports virtual functions for Intel XL710,
|
2018-09-15 08:37:44 +08:00
|
|
|
X710, X722, XXV710, and all devices advertising support for
|
|
|
|
|
Intel Ethernet Adaptive Virtual Function devices. For more
|
2017-05-12 02:23:20 +08:00
|
|
|
information on how to identify your adapter, go to the Adapter
|
|
|
|
|
& Driver ID Guide that can be located at:
|
2013-12-21 14:13:16 +08:00
|
|
|
|
2018-09-15 08:37:44 +08:00
|
|
|
<https://support.intel.com>
|
|
|
|
|
|
|
|
|
|
This driver was formerly named i40evf.
|
2013-12-21 14:13:16 +08:00
|
|
|
|
2018-10-11 03:16:13 +08:00
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/iavf.rst>.
|
2018-10-11 03:16:13 +08:00
|
|
|
|
2013-12-21 14:13:16 +08:00
|
|
|
To compile this driver as a module, choose M here. The module
|
2018-09-15 08:37:44 +08:00
|
|
|
will be called iavf. MSI-X interrupt support is required
|
2013-12-21 14:13:16 +08:00
|
|
|
for this driver to work correctly.
|
|
|
|
|
|
2018-03-20 22:58:05 +08: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-13 02:33:58 +08:00
|
|
|
depends on PTP_1588_CLOCK_OPTIONAL
|
2023-02-25 05:32:41 +08:00
|
|
|
depends on GNSS || GNSS = n
|
2021-05-20 22:37:51 +08: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-04-01 05:16:57 +08:00
|
|
|
select DIMLIB
|
2020-03-12 09:58:15 +08: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-24 08:22:03 +08:00
|
|
|
select PLDMFW
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2018-03-20 22:58:05 +08: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-11 03:16:13 +08:00
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/ice.rst>.
|
2018-10-11 03:16:13 +08:00
|
|
|
|
2018-03-20 22:58:05 +08:00
|
|
|
To compile this driver as a module, choose M here. The module
|
|
|
|
|
will be called ice.
|
|
|
|
|
|
2021-08-20 08:08:48 +08: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-14 00:00:08 +08: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-21 07:46:05 +08: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-13 02:33:58 +08:00
|
|
|
depends on PTP_1588_CLOCK_OPTIONAL
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2014-09-21 07:46:05 +08:00
|
|
|
This driver supports Intel(R) FM10000 Ethernet Switch Host
|
|
|
|
|
Interface. For more information on how to identify your adapter,
|
2016-04-05 22:25:07 +08:00
|
|
|
go to the Adapter & Driver ID Guide that can be located at:
|
2014-09-21 07:46:05 +08:00
|
|
|
|
|
|
|
|
<http://support.intel.com>
|
|
|
|
|
|
2018-10-11 03:16:12 +08:00
|
|
|
More specific information on configuring the driver is in
|
2020-06-27 01:27:24 +08:00
|
|
|
<file:Documentation/networking/device_drivers/ethernet/intel/fm10k.rst>.
|
2018-10-11 03:16:12 +08:00
|
|
|
|
2014-09-21 07:46:05 +08: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 15:17:08 +08:00
|
|
|
config IGC
|
|
|
|
|
tristate "Intel(R) Ethernet Controller I225-LM/I225-V support"
|
|
|
|
|
default n
|
|
|
|
|
depends on PCI
|
2021-09-18 05:05:47 +08:00
|
|
|
depends on PTP_1588_CLOCK_OPTIONAL
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2018-10-11 15:17:08 +08: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 22:42:33 +08:00
|
|
|
endif # NET_VENDOR_INTEL
|