2016-12-20 14:38:26 +01:00
#
# Solarflare device configuration
#
config NET_VENDOR_SOLARFLARE
bool "Solarflare devices"
default y
---help---
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 12:55:59 +01:00
config SFC
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
tristate "Solarflare SFC9000/SFC9100-family support"
2012-11-16 12:47:39 +00:00
depends on PCI
2009-04-29 08:05:08 +00:00
select MDIO
2008-04-27 12:55:59 +01:00
select CRC32
2008-05-30 22:27:04 +01:00
select I2C
select I2C_ALGOBIT
2016-11-11 00:10:07 -05:00
imply PTP_1588_CLOCK
2011-05-13 00:17:42 -07:00
---help---
2013-09-05 17:53:57 +01:00
This driver supports 10/40-gigabit Ethernet cards based on
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
the Solarflare SFC9000-family and SFC9100-family controllers.
2008-04-27 12:55:59 +01:00
To compile this driver as a module, choose M here. The module
will be called sfc.
2008-11-04 20:34:28 +00:00
config SFC_MTD
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
bool "Solarflare SFC9000/SFC9100-family MTD support"
2008-11-20 04:17:42 -08:00
depends on SFC && MTD && !(SFC=y && MTD=m)
2008-11-04 20:34:28 +00:00
default y
2011-05-13 00:17:42 -07:00
---help---
2012-01-06 22:47:17 +00: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-06 20:25:39 +00:00
config SFC_MCDI_MON
2013-08-29 19:19:29 +01:00
bool "Solarflare SFC9000/SFC9100-family hwmon support"
2012-01-06 20:25:39 +00:00
depends on SFC && HWMON && !(SFC=y && HWMON=m)
default y
2013-03-15 12:59:30 +01:00
---help---
2012-01-06 20:25:39 +00: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 00:48:07 +00:00
config SFC_SRIOV
bool "Solarflare SFC9000-family SR-IOV support"
depends on SFC && PCI_IOV
default y
---help---
This enables support for the SFC9000 I/O Virtualization
features, allowing accelerated network performance in
virtualized environments.
2015-05-27 13:13:54 +01:00
config SFC_MCDI_LOGGING
bool "Solarflare SFC9000/SFC9100-family MCDI logging support"
depends on SFC
default y
---help---
This enables support for tracing of MCDI (Management-Controller-to-
Driver-Interface) commands and responses, allowing debugging of
2015-05-27 13:14:01 +01:00
driver/firmware interaction. The tracing is actually enabled by
a sysfs file 'mcdi_logging' under the PCI device.
2016-12-20 14:38:26 +01:00
source "drivers/net/ethernet/sfc/falcon/Kconfig"
endif # NET_VENDOR_SOLARFLARE
