History log of /freebsd-current/sys/dev/cxgbe/t4_iov.c
Revision Date Author Comments
# 1389314d 30-May-2024 Kristof Provost <kp@FreeBSD.org>

cxgbe: handle vlan PF restrictions

Co-Authored-by: Navdeep Parhar <np@FreeBSD.org>
MFC after: 2 weeks
Sponsored by: Orange Business Services
Differential Revision: https://reviews.freebsd.org/D45428


# fdafd315 24-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix


# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# d2070e5f 15-Feb-2023 John Baldwin <jhb@FreeBSD.org>

cxgbe: Don't leak memory resource if t4iov attach fails.

Co-authored by: np
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D38580


# e8d1145d 19-Apr-2022 John Baldwin <jhb@FreeBSD.org>

cxgbe: Remove unused devclass arguments to *DRIVER_MODULE().

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D34964


# de0a3472 08-Nov-2020 Navdeep Parhar <np@FreeBSD.org>

cxgbe(4): Allow the PF driver to set a VF's MAC address.

The MAC address can be set with the optional mac-addr property in the VF
section of the iovctl.conf(5) used to instantiate the VFs.

MFC after: 2 weeks
Sponsored by: Chelsio Communications


# 5877e649 15-Nov-2019 Navdeep Parhar <np@FreeBSD.org>

cxgbev(4): Catch up with the pciids in the PF driver.

MFC after: 3 days
Sponsored by: Chelsio Communications


# 49c0beb6 05-May-2017 Navdeep Parhar <np@FreeBSD.org>

cxgbe(4): Update the VF device ids too. This should have been part
of r317820.

Reported by: jhb@
MFC after: 1 week
Sponsored by: Chelsio Communications


# 63febe64 04-May-2017 Navdeep Parhar <np@FreeBSD.org>

cxgbe(4): Update the list of PCIe devices claimed by the driver. At
this point any board with a T6 should just work.

Obtained from: Chelsio Communications
MFC after: 1 week
Sponsored by: Chelsio Communications


# 0ed5eff9 31-Jan-2017 John Baldwin <jhb@FreeBSD.org>

Fix a couple of issues with t4iov probe and attach.

- Check for Chelsio vendor ID in probe routines.
- Fail attach instead of faulting if pci_find_dbsf() doesn't find a
device.

PR: 216539
Reported by: asomers
Tested by: Dave Baukus <daveb@spectralogic.com>
MFC after: 3 days
Sponsored by: Chelsio Communications


# e6b81479 15-Sep-2016 Navdeep Parhar <np@FreeBSD.org>

cxgbe(4): Attach to cards with the Terminator 6 ASIC. T6 cards will
come up as 't6nex' nexus devices with 'cc' ports hanging off them.

The T6 firmware and configuration files will be added as soon as they
are released. For now the driver will try to work with whatever
firmware and configuration is on the card's flash.

Sponsored by: Chelsio Communications


# 83a202ca 15-Sep-2016 Navdeep Parhar <np@FreeBSD.org>

Whitespace nits.


# 1fedfdd5 12-Sep-2016 John Baldwin <jhb@FreeBSD.org>

Remove explicit device_verbose() from the t4iov driver detach routine
now that this case is handled generically.


# bc32f054 29-Aug-2016 John Baldwin <jhb@FreeBSD.org>

Use device_verbose() to undo device_quiet() when detaching from t[45]iovX.

The device quiet flag is not automatically reset on detach, so it is
inherited by other device drivers (e.g. when switching a device driver
over to ppt for PCI pass through). Cope with this behavior by explicitly
marking the device verbose during detach so that the next driver can make
its own decision.

Sponsored by: Chelsio Communications


# 847bfa8e 03-Aug-2016 John Baldwin <jhb@FreeBSD.org>

Use the port device name for the iov device for Chelsio T4/T5 cards.

Chelsio T4/T5 adapters are multifunction cards. The main driver uses
physical function 4 (PF4). However, VF devices for SR-IOV are only
supported on physical functions 0 through 3, where PF0 creates VFs tied
to port 0, etc. The t4iov/t5iov driver was previously added to
create VF devices for ports that are present on each adapter. This
change uses the recently added pci_iov_attach_name() function to
name the character device in /dev/iov after the associated port on
the card (e.g. /dev/iov/cxl0 is used to create VFs that share the
cxl0 port). With this in place, mark the t4iov/t5iov devices quiet
to prevent them from cluttering dmesg.

Reviewed by: rstone
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7402


# f91fca5b 22-Jul-2016 John Baldwin <jhb@FreeBSD.org>

Add a driver to create VF devices on Chelsio T4/T5 NICs.

Chelsio NICs are a bit unique compared to some other NICs in that they
expose different functionality on different physical functions. In
particular, PF4 is used to manage the NIC interfaces ('t4nex' and 't5nex').
However, PF4 is not able to create VF devices. Instead, VFs are only
supported by physical functions 0 through 3. This commit adds 't4iov'
and 't5iov' drivers that attach to PF0-3.

One extra wrinkle is that the iov devices cannot enable SR-IOV until the
firwmare has been initialized by the main PF4 driver. To handle this
case, a new t4_if kobj interface has been added to permit cross-calls
between the PF drivers. The PF4 driver notifies sibling drivers when it
is fully attached. It also requests sibling drivers to detach before it
detaches. Sibling drivers query the PF4 driver during their attach
routine to see if it is attached. If not, the sibling drivers defer
their attach actions until the PF4 driver informs them it is attached.

VF devices are associated with a single port on the NIC. VF devices
created from PF0 are associated with the first port on the NIC, VFs
from PF1 are associated with the second port, etc. VF devices can
only be created from a PF device that has an associated port. Thus,
on a 2-port card, VFs are only supported on PF0 and PF1.

Reviewed by: np (earlier versions)
MFC after: 1 month
Sponsored by: Chelsio Communications