sys: Import snapshot of Aquantia ACQ107 vendor driver
Obtained from https://github.com/Aquantia/aqtion-freebsd commit
c61d27b1d94af72c642deefa0595884481ea7377.
This is not using a vendor branch. The formerly-upstream repo is
abandoned and I do not believe it will receive updates. This initial
import serves as a snapshot of the vendor code, but from here we will
iterate on it in the tree as our own code.
Bug fixes, code cleanup, and build infrastructure will follow.
NetBSD and OpenBSD have derivatives of this driver (with additional
hardware support). We can look to changes in those drivers, and the
Linux driver, to add support here.
Reviewed by: adrian
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53813
[2 lines not shown]
if_bnxt: Add support for HWRM passthrough with multiple DMA buffers
Added support for HWRM passthrough commands with multiple DMA buffers.
Also, changed the mgmt_lock to sleepable exclusive lock.
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56686
(cherry picked from commit 9d87ca8b9f60bdec0bbc1733920df250a08beb0c)
bnxt_en: add bnxt_sriov.c to sys/conf/files for built-in kernel builds
The SR-IOV series added bnxt_sriov.c and listed it in sys/modules/bnxt/bnxt_en/Makefile,
but kernels that build bnxt into the image only compile sources named in sys/conf/files.
Add bnxt_sriov.c next to the other bnxt_en entries so built-in bnxt (including LINT)
links the SR-IOV implementation and avoids undefined symbols referenced from if_bnxt.c.
Fixes: f2f831b2c151 ("bnxt_en: Add core SR-IOV infrastructure")
MFC after: 1 month
Reviewed by: ssaxena
Differential Revision: https://reviews.freebsd.org/D56688
(cherry picked from commit c21c63fb565f1bc7f9564dbf12068c864f8891d8)
if_bnxt: add few source files to version control
Commits- f85e66e655c9 ("if_bnxt/bnxt_re: add support for driver snapdump")
and 03839879a2dd ("if_bnxt: Add Firmware crashdump collection support")
missed to add few files under version control, those files are
added now:
sys/dev/bnxt/bnxt_en/bnxt_log.c
sys/dev/bnxt/bnxt_en/bnxt_log.h
sys/dev/bnxt/bnxt_en/bnxt_log_data.c
sys/dev/bnxt/bnxt_en/bnxt_log_data.h
sys/dev/bnxt/bnxt_en/bnxt_coredump.c
sys/dev/bnxt/bnxt_en/bnxt_coredump.h
bnxt_coredump.c entry is added in sys/conf/files as well.
Fixes: f85e66e655c9 ("if_bnxt/bnxt_re: add support for driver snapdump")
Fixes: 03839879a2dd ("if_bnxt: Add Firmware crashdump collection support")
(cherry picked from commit 9931dc5bf3831146c08a381c42ecbfcedb8ac7f1)
if_bnxt: add bnxt logger module files to sys/conf/files for built-in kernel builds
The bnxt snapdump and coredump support patches added bnxt_log/{_data}.c. and listed it in
sys/modules/bnxt/bnxt_en/Makefile, but missed to add these files in sys/conf/files.
Fix up the issue by adding bnxt_log/{_data}.c in sys/conf/files.
Fixes: f85e66e655c9 ("if_bnxt/bnxt_re: add support for driver snapdump")
(cherry picked from commit 03676cafa882c471a29436aae76c8751d451dd07)
if_bnxt: Fix the Unknown command 0x80000000 ioctl command error
With the latest niccli version, user will observe below
Unknown command command error when try to list the devices.
if_bnxt: Unknown command 0x80000000
Here, niccli is issuing command opcode as 0x80000000 but
driver is expecting 0x20000000 command opcode.
So, replaced _IOW(0,0,0) with the _IOC(IOC_IN,0,0,0).
Fixes: d53d7b4 ("bnxt: Fix up ioctl opcodes to support IOC_VOID along with IOC_IN")
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56685
(cherry picked from commit 3987058a3a943c461c27dbebf10dad555b1bb2fa)
if_bnxt: Add Firmware crashdump collection support
This patch adds support for DDR-based firmware coredump memory handling.
It detects firmware coredump capability, allocates host DDR (DMA) memory
for crash dumps, and programs the firmware with the allocated memory during
attach. The allocated memory is released during driver detach.
Also, This patch adds functions to retrieve crash dump data from host DDR
memory. The implementation handles data copying from page tables and
checks dump availability. Main function bnxt_get_coredump() copies
stored crash dump data from DDR memory to the application buffer.
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56684
(cherry picked from commit 03839879a2dd2505eab80b99211b0637ebdc9d32)
if_bnxt/bnxt_re: add support for driver snapdump
Add a logging module which helps to log and collect the driver`s
various events and state of device data structures.
APIs help modules like l2, RoCE etc. to register and
add logs into thg buffers. A segment header is added to the
data available in buffers.
The final log messages are arranged in following fashion
|SegHeader0|Data0|SegHeader1|Data1|
Logging module provides two different kinds of buffers:
a) A large contiguous memory chunk is used to form circular buffers.
Module need to provide a number of buffers while registering to
the logging module.Please note that, since memory for the
buffers remains with the module as long as it is registered, memory
footprints of the driver could be higher so the modules should
allocate an appropriate number of buffers. Also, due to limited
[23 lines not shown]
bnxt: Fix up ioctl opcodes to support IOC_VOID along with IOC_IN
The driver and applications currently use hard-coded numeric ioctl command
opcodes. These opcodes are interpreted as having the IOC_IN direction (data
copied from the user application to the driver), regardless of the actual packet
size. Consequently, when the packet size is zero and the direction is set to
IOC_IN, the kernel fails these ioctls if COMPAT is disabled.
While the driver and applications should ideally set the direction correctly—
for example, using IOC_VOID when the packet size is zero—the driver will now
be updated to define ioctl opcodes using the _IOC macro to support both
IOC_VOID and IOC_IN. This change ensures backward compatibility with older
applications that exclusively use IOC_IN.
Reviewed by: gallatin
Differential Revision: https://reviews.freebsd.org/D54601
MFC after: 3 days
(cherry picked from commit d53d7b466016408229491cfd2f8bdc742ff642e3)
bnxt: Fix build / load error for bnxt(4) in kernels without PCI_IOV
This change removes the hard-forcing of PCI_IOV and adds shims to
allow the driver to compile and work when the kernel is missing
PCI_IOV support.
Fixes: 7c450d1127c7
Reviewed by: sumit.saxena_broadcom.com
Differential Revision: https://reviews.freebsd.org/D57300
Sponsored by: Netflix
(cherry picked from commit 3118f1b99f23431235c202d9aadbe3d183bcc259)
bnxt_en: Address review comments for core SR-IOV support
This patch addresses the code review comments provided for:
https://reviews.freebsd.org/D56197
* P7 VF PCI ID: rename NETXTREME_E_P7_VF to E_P7_VF (P7/Thor2 line drops the
Netxtreme name in product strings; other VF device IDs are unchanged).
* Use the return value of bnxt_vf_parse_schema() in bnxt_iov_vf_add() to
decide when to call bnxt_set_vf_admin_mac(); make parse_schema() return
bool and remove the has_admin_mac field.
* In bnxt_free_vf_resources(), fix indentation after dma_free_coherent() so
the NULL assignment is clearly separate from the call.
* In bnxt_hwrm_func_vf_resource_free(), use first_vf_id/last_vf_id in the
HWRM_FUNC_VF_RESC_FREE loop.
MFC after: 1 month
Reviewed by: ssaxena
Differential Revision: https://reviews.freebsd.org/D56644
(cherry picked from commit 7c450d1127c7f08361f848c0ac57189910da8d3b)
bnxt_en: VF ring reservation, HWRM registration, and PF-only operation guards
VFs require separate HWRM commands for ring reservation and async
completion ring setup, so a common PF/VF dispatcher is introduced and
the async CR path is extended to handle both. The PF must populate the
VF request forwarding bitmap during driver registration so the firmware
correctly forwards VF-originated HWRM commands. VF reservation strategy
and min-guaranteed capability flags are now parsed for correct resource
partitioning, and PF-only operations (DCB, NVM, package version sysctl)
are guarded against VF invocation.
The short command buffer allocation is also reordered before the function
reset to ensure extended HWRM messages are available when needed, a
prerequisite uncovered during VF bring-up.
MFC after: 1 month
Reviewed by: ssaxena
Differential Revision: https://reviews.freebsd.org/D56232
(cherry picked from commit c972c5acbac472a5dc797856f39f478862b6c6ea)
bnxt_en: Re-enable SR-IOV after firmware reset
When the firmware undergoes a hot-reset and the driver re-opens the
device, previously active Virtual Functions lose their resource
configuration. bnxt_reenable_sriov() restores that configuration by
replaying bnxt_cfg_hw_sriov() with the saved resource parameters.
The function is called from bnxt_fw_reset_task() in the
BNXT_FW_RESET_STATE_OPENING state, guarded by #ifdef PCI_IOV.
Because bnxt_cfg_hw_sriov() is a no-op when active_vfs is zero the
call is safe on any PF regardless of whether VFs were ever created.
MFC after: 1 month
Reviewed by: ssaxena
Differential Revision: https://reviews.freebsd.org/D56201
(cherry picked from commit 8743209350cb4b7db6d367df99da0a7ae3bc5d39)
bnxt_en: Add per-VF trust, spoof-check and promiscuous controls
Expose per-VF policy knobs via the FreeBSD sysctl tree and enforce
them at the data-path level.
Trust (dev.bnxt.<unit>.vfN.trusted):
bnxt_set_vf_trust() sets/clears BNXT_VF_TRUST and sends
HWRM_FUNC_CFG with FLAGS_TRUSTED_VF_ENABLE/DISABLE.
bnxt_create_trusted_vf_sysctls() / bnxt_destroy_trusted_vf_sysctls()
manage the sysctl lifetime with VF creation/teardown.
Spoof-check (dev.bnxt.<unit>.vfN.spoofchk):
bnxt_set_vf_spoofchk() issues HWRM_FUNC_CFG with
SRC_MAC_ADDR_CHECK_ENABLE/DISABLE.
Promiscuous gating:
bnxt_is_trusted_vf() queries firmware via HWRM_FUNC_QCFG.
bnxt_promisc_ok() returns false for untrusted VFs, preventing them
from entering promiscuous mode. bnxt_promisc_set() is updated to
[11 lines not shown]
bnxt_en: Add VF forwarded HWRM request handling
Enable the Physical Function to proxy HWRM commands issued by Virtual
Functions through the firmware forwarded-request mechanism.
When a VF issues a command that requires PF arbitration, the firmware
delivers a CMPL_BASE_TYPE_HWRM_FWD_REQ completion to the PF async ring.
* bnxt_process_async_msg() recognises CMPL_BASE_TYPE_HWRM_FWD_REQ,
identifies the originating VF by its firmware function ID, sets the
corresponding bit in pf.vf_event_bmap, and raises
BNXT_HWRM_EXEC_FWD_REQ_SP_EVENT to schedule deferred processing.
* bnxt_sp_task() dispatches to bnxt_hwrm_exec_fwd_req(), which iterates
over all pending VF bits and calls bnxt_vf_req_validate_snd() for each.
* bnxt_vf_req_validate_snd() inspects the encapsulated request type:
HWRM_FUNC_VF_CFG (MAC change) is handled by bnxt_vf_configure_mac()
which enforces trust/existing-MAC rules; HWRM_CFA_L2_FILTER_ALLOC is
[10 lines not shown]
[orc-rt] Mark ControllerAccess constructor as noexcept. (#229663)
ControllerAccess construction should not throw. Add the noexcept
specifier to the ControllerAccess constructor, in-tree subclass
constructors (InProcessControllerAccess and SocketSimpleRemoteCA) and to
the operations they depend upon.
bnxt_en: Add VF load path and PF/VF context differentiation
Teach the driver to distinguish a Physical Function from a Virtual
Function at probe time and configure each appropriately.
* Introduce bnxt_is_vf_device() to identify all known VF device IDs
(NetXtreme-C/E Gen1-3, Thor1/2, Hyper-V variants). Add corresponding
PVID entries to bnxt_vendor_info_array.
* Refactor the iflib shared context: rename bnxt_sctx_init to
bnxt_sctx_template, add a Thor2-specific bnxt_sctx_template_p7, and
build per-call PF/VF instances via bnxt_init_sctx_variants(); the VF
instance carries IFLIB_IS_VF. bnxt_register() selects the correct sctx.
* bnxt_attach_pre(): replace the hard-coded NPAR/VF switch with
bnxt_set_flags_by_devid(); on a VF call bnxt_approve_mac() to request
PF approval for the firmware-assigned MAC address.
* bnxt_hwrm_func_qcaps(): populate fw_fid and MAC for PF and VF contexts
[14 lines not shown]
bnxt: set hardware checksum only if required
The test condition in the bnxt driver for TCP/UDP transmit hardware checksum
offload is invalid: only the TCP / UDP csum bits should be tested
Only the relevant ipi_csum_flags bits are now tested
Reviewed by: tuexen
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D53941
(cherry picked from commit 2e94e1631ef517f5495e25d7fa22c95f7dca0dc6)
nd6: Fix regeneration of temp addresses in detached state
When an on-link prefix becomes detached, the kernel keeps
generating new RFC 8981 temporary addresses for that prefix.
Fix it by ignoring the detached addresses in regen_tmpaddr().
While here, change its return type to bool.
PR: 298533
Discussed with: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D60051
(cherry picked from commit 61f98a98250da7bd2c80c6d93d0032961d7f2fad)
raw ip: clear sin_port on bind(2)
Application may set sin_port to some value. Although this value is not
used by SOCK_RAW, it breaks a check that the address is available. A
perfect fix would be not use sockaddrs for ifaddrs, but that would be a
bigger change.
PR: 298366
Reviewed by: pouria, bnovkov, adrian
Differential Revision: https://reviews.freebsd.org/D59570
Fixes: 948ad32ae1e0811f45e1d38f26636fefed5051f0
(cherry picked from commit 465942e8cc8160b21e1a3d5e45fa3ddbb852f6db)
Fix statement with no effect in linuxkpi's xarray.h
When compiling the kernel with gcc 14, errors similar to the following
are emitted:
sys/dev/cxgbe/iw_cxgbe/ev.c: In function 'c4iw_ev_handler':
sys/compat/linuxkpi/common/include/linux/xarray.h:132:23: error: statement with no effect [-Werror=unused-value]
132 | flags == 0; \
sys/dev/cxgbe/iw_cxgbe/ev.c:274:17: note: in expansion of macro 'xa_unlock_irqrestore'
274 | xa_unlock_irqrestore(&dev->cqs, flag);
| ^~~~~~~~~~~~~~~~~~~~
sys/compat/linuxkpi/common/include/linux/xarray.h:132:23: error: statement with no effect [-Werror=unused-value]
132 | flags == 0; \
sys/dev/cxgbe/iw_cxgbe/ev.c:283:17: note: in expansion of macro 'xa_unlock_irqrestore'
283 | xa_unlock_irqrestore(&dev->cqs, flag);
| ^~~~~~~~~~~~~~~~~~~~
It looks like the intent of the "flags == 0" statement was to make the
'flags' macro argument not unused, but it still results in a warning.
[7 lines not shown]
