2019-05-19 20:07:45 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2016-12-20 21:38:26 +08:00
|
|
|
#
|
|
|
|
# Solarflare device configuration
|
|
|
|
#
|
|
|
|
|
|
|
|
config NET_VENDOR_SOLARFLARE
|
|
|
|
bool "Solarflare devices"
|
|
|
|
default y
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2016-12-20 21:38:26 +08:00
|
|
|
If you have a network (Ethernet) card belonging to this class, say Y.
|
|
|
|
|
|
|
|
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 Solarflare devices. If you say Y, you will be asked
|
|
|
|
for your specific card in the following questions.
|
|
|
|
|
|
|
|
if NET_VENDOR_SOLARFLARE
|
|
|
|
|
2008-04-27 19:55:59 +08:00
|
|
|
config SFC
|
2022-05-04 15:49:53 +08:00
|
|
|
tristate "Solarflare SFC9100/EF100-family 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
|
2009-04-29 16:05:08 +08:00
|
|
|
select MDIO
|
2008-04-27 19:55:59 +08:00
|
|
|
select CRC32
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2013-09-06 00:53:57 +08:00
|
|
|
This driver supports 10/40-gigabit Ethernet cards based on
|
2022-05-04 15:49:53 +08:00
|
|
|
the Solarflare SFC9100-family controllers.
|
2008-04-27 19:55:59 +08:00
|
|
|
|
2020-07-27 19:55:55 +08:00
|
|
|
It also supports 10/25/40/100-gigabit Ethernet cards based
|
|
|
|
on the Solarflare EF100 networking IP in Xilinx FPGAs.
|
|
|
|
|
2008-04-27 19:55:59 +08:00
|
|
|
To compile this driver as a module, choose M here. The module
|
|
|
|
will be called sfc.
|
2008-11-05 04:34:28 +08:00
|
|
|
config SFC_MTD
|
2022-05-12 00:19:24 +08:00
|
|
|
bool "Solarflare SFC9100-family MTD support"
|
2008-11-20 20:17:42 +08:00
|
|
|
depends on SFC && MTD && !(SFC=y && MTD=m)
|
2008-11-05 04:34:28 +08:00
|
|
|
default y
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2012-01-07 06:47:17 +08:00
|
|
|
This exposes the on-board flash and/or EEPROM as MTD devices
|
|
|
|
(e.g. /dev/mtd1). This is required to update the firmware or
|
|
|
|
the boot configuration under Linux.
|
2012-01-07 04:25:39 +08:00
|
|
|
config SFC_MCDI_MON
|
2022-05-12 00:19:49 +08:00
|
|
|
bool "Solarflare SFC9100-family hwmon support"
|
2012-01-07 04:25:39 +08:00
|
|
|
depends on SFC && HWMON && !(SFC=y && HWMON=m)
|
|
|
|
default y
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2012-01-07 04:25:39 +08:00
|
|
|
This exposes the on-board firmware-managed sensors as a
|
|
|
|
hardware monitor device.
|
sfc: Add SR-IOV back-end support for SFC9000 family
On the SFC9000 family, each port has 1024 Virtual Interfaces (VIs),
each with an RX queue, a TX queue, an event queue and a mailbox
register. These may be assigned to up to 127 SR-IOV virtual functions
per port, with up to 64 VIs per VF.
We allocate an extra channel (IRQ and event queue only) to receive
requests from VF drivers.
There is a per-port limit of 4 concurrent RX queue flushes, and queue
flushes may be initiated by the MC in response to a Function Level
Reset (FLR) of a VF. Therefore, when SR-IOV is in use, we submit all
flush requests via the MC.
The RSS indirection table is shared with VFs, so the number of RX
queues used in the PF is limited to the number of VIs per VF.
This is almost entirely the work of Steve Hodgson, formerly
shodgson@solarflare.com.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
2012-02-14 08:48:07 +08:00
|
|
|
config SFC_SRIOV
|
2022-05-12 00:19:36 +08:00
|
|
|
bool "Solarflare SFC9100-family SR-IOV support"
|
sfc: Add SR-IOV back-end support for SFC9000 family
On the SFC9000 family, each port has 1024 Virtual Interfaces (VIs),
each with an RX queue, a TX queue, an event queue and a mailbox
register. These may be assigned to up to 127 SR-IOV virtual functions
per port, with up to 64 VIs per VF.
We allocate an extra channel (IRQ and event queue only) to receive
requests from VF drivers.
There is a per-port limit of 4 concurrent RX queue flushes, and queue
flushes may be initiated by the MC in response to a Function Level
Reset (FLR) of a VF. Therefore, when SR-IOV is in use, we submit all
flush requests via the MC.
The RSS indirection table is shared with VFs, so the number of RX
queues used in the PF is limited to the number of VIs per VF.
This is almost entirely the work of Steve Hodgson, formerly
shodgson@solarflare.com.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
2012-02-14 08:48:07 +08:00
|
|
|
depends on SFC && PCI_IOV
|
|
|
|
default y
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2022-05-04 15:49:53 +08:00
|
|
|
This enables support for the Single Root I/O Virtualization
|
sfc: Add SR-IOV back-end support for SFC9000 family
On the SFC9000 family, each port has 1024 Virtual Interfaces (VIs),
each with an RX queue, a TX queue, an event queue and a mailbox
register. These may be assigned to up to 127 SR-IOV virtual functions
per port, with up to 64 VIs per VF.
We allocate an extra channel (IRQ and event queue only) to receive
requests from VF drivers.
There is a per-port limit of 4 concurrent RX queue flushes, and queue
flushes may be initiated by the MC in response to a Function Level
Reset (FLR) of a VF. Therefore, when SR-IOV is in use, we submit all
flush requests via the MC.
The RSS indirection table is shared with VFs, so the number of RX
queues used in the PF is limited to the number of VIs per VF.
This is almost entirely the work of Steve Hodgson, formerly
shodgson@solarflare.com.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
2012-02-14 08:48:07 +08:00
|
|
|
features, allowing accelerated network performance in
|
|
|
|
virtualized environments.
|
2015-05-27 20:13:54 +08:00
|
|
|
config SFC_MCDI_LOGGING
|
2022-05-12 00:20:01 +08:00
|
|
|
bool "Solarflare SFC9100-family MCDI logging support"
|
2015-05-27 20:13:54 +08:00
|
|
|
depends on SFC
|
|
|
|
default y
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2015-05-27 20:13:54 +08:00
|
|
|
This enables support for tracing of MCDI (Management-Controller-to-
|
|
|
|
Driver-Interface) commands and responses, allowing debugging of
|
2015-05-27 20:14:01 +08:00
|
|
|
driver/firmware interaction. The tracing is actually enabled by
|
|
|
|
a sysfs file 'mcdi_logging' under the PCI device.
|
2016-12-20 21:38:26 +08:00
|
|
|
|
|
|
|
source "drivers/net/ethernet/sfc/falcon/Kconfig"
|
2022-05-09 23:33:23 +08:00
|
|
|
source "drivers/net/ethernet/sfc/siena/Kconfig"
|
2016-12-20 21:38:26 +08:00
|
|
|
|
|
|
|
endif # NET_VENDOR_SOLARFLARE
|