* Makes the TX DMA stopping more similar to Linux code, and potentially
a bit faster. Also, output an error message when TX DMA idling fails.
Taken-From: Linux iwlwifi
Tested:
* AC3165, STA mode
Approved by: adrian (mentor)
Obtained from: DragonFlyBSD git 2ee486ddff973ac552ff787c17e8d83e8ae0f24c
Differential Revision: https://reviews.freebsd.org/D7325
When building a Tx Command for management frames, we are lacking
a check for action frames, for which we should set a different
pm_timeout. This cause the fw to stay awake for 100TU after each
such frame is transmitted, resulting an excessive power consumption.
Taken-From: Linux iwlwifi (git b084a35663c3f1f7)
Approved by: adrian (mentor)
Obtained from: Linux git b084a35663c3f1f7de1c45c4ae3006864c940fe7
Obtained from: DragonFlyBSD git ba00f0e3ae873d6f0d5743e22c3ebc49c44dfdac
Differential Revision: https://reviews.freebsd.org/D7324
The PROT_REQUIRE flag in should be set for data frames above a certain
length, but we were setting it for !data frames above a certain length,
which makes no sense at all.
Taken-From: OpenBSD, Linux iwlwifi
Approved by: adrian (mentor)
Obtained from: DragonFlyBSD git 8cc03924a36c572c2908e659e624f44636dc2b33
Differential Revision: https://reviews.freebsd.org/D7323
AIO write requests for a TOE socket on a Chelsio T4+ adapter can now
DMA directly from the user-supplied buffer. This is implemented by
wiring the pages backing the user-supplied buffer and queueing special
mbufs backed by raw VM pages to the socket buffer. The TOE code
recognizes these special mbufs and builds a sglist from the VM page
array associated with the mbuf when queueing a work request to the TOE.
Because these mbufs do not have an associated virtual address, m_data
is not valid. Thus, the AIO handler does not invoke sosend() directly
for these mbufs but instead inlines portions of sosend_generic() and
tcp_usr_send().
An aiotx_buffer structure is used to describe the user buffer (e.g.
it holds the array of VM pages and a reference to the AIO job). The
special mbufs reference this structure via m_ext. Note that a single
job might be split across multiple mbufs (e.g. if it is larger than
the socket buffer size). The 'ext_arg2' member of each mbuf gives an
offset relative to the backing aiotx_buffer. The AIO job associated
with an aiotx_buffer structure is completed when the last reference to
the structure is released.
Zero-copy aio_write()'s for connections associated with a given
adapter can be enabled/disabled at runtime via the
'dev.t[45]nex.N.toe.tx_zcopy' sysctl.
MFC after: 1 month
Relnotes: yes
Sponsored by: Chelsio Communications
So that they can use suitable MP synchronization mechanism.
While I'm here change the bufring init/read/write function names.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7313
returning EAGAIN if they aren't available when the user tries to program
a filter. Do this after validating the filter so that the driver
doesn't bring up the queues if it doesn't have to.
The hardware delivers ns16550-compatible status bits, which is what the
usb_serial code expects, so no need for translation, no need for a local
variable to hold a temporary lsr result.
Note that keyboards are stored in an array and are not freed (just
"unregistered" by clearing some fields) so a race would be limited to
obtaining stale information about an unregistered keyboard.
Reported by: CTurt
MFC after: 3 days
It only contains bufring related bits for a while.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7281
Calling it earlier increases the window when MSIX info may change.
This change does not solve the problem completely, but seems logical.
Complete solution should probably include link reset in case of MSIX
remap to trigger new negotiation, but we have no way to get notified
about that now.
Split implementation of nvram2env to generic (MI) & MIPS-based code:
- removed includes like "*siba*", because they are unused
- added nvram2env_mips.c file with MIPS-specific code, code moved from nvram2env.c
- added header file to shared defines/structures/function prototypes between MI and MIPS code
Also this fix allows to implement own nvram2env drivers.
Reviewed by: ray, adrian (mentor)
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6513
vesa_init_done isn't a reliable guard for the mutex init. If
vesa_configure() doesn't find valid VESA info it will not set
vesa_init_done, but the lock will remain initialized. Revert r303076
and use MTX_SYSINIT to deterministically init the lock.
Reviewed by: royger
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D7290
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
If a driver sends an malformed or disallowed work request, the firmware
responds with a work request error. Previously the driver treated this is
as an unexpected message and panicked. Now it decodes the error message
to aid in debugging.
Reviewed by: np (older version)
MFC after: 1 month
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D6950
Binary state node is added, so that userland programs do not have
to parse human readable state string.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7268
warnings for some kernel events, mostly intended for the use of
obsoleted or otherwise undersired interfaces.
This is an abstracted and race-expelled code from compat pty driver.
Requested and reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D7270
* Add acpi_if.h to the SRC list in the uart module
* Only include new acpi headers when they are needed
Obtained from: ABT Systems Ltd
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
the uart class to use in a similar way as the fdt driver.
Obtained from: ABT Systems Ltd
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7248
This avoids unnecessary access to the vmbus_softc struct on sending path.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7257
Clear unused (undocumented) CAM bytes while setting a key;
without that, hardware does weird things when A-MSDU bit in QoS header
is set.
Tested with RTL8188CUS (AP) -> RTL8188EU (STA) (A-MSDU transmit).
Reported by: many
Obtained from: https://github.com/s3erios/urtwm
MFC after: 5 days
and ACPI. As such pull out what will be the common parts of the FDT cpu
detection to a new function that can be shared between them.
Reviewed by: manu
Obtained from: ABT Systems Ltd
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7262
Fix the following panic seen when migrating a FreeBSD guest on Xen:
panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:541
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001d2fa4f0
vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570
kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0
__mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa630
vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfffffe001d2fa680
vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0
isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0
bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame
[...]
This is caused because vga_sub_configure (which is called if the VGA adapter
is attached after VESA tried to initialize), points to vesa_configure, which
doesn't initialize the VESA mutex. In order to fix it, make sure
vga_sub_configure points to vesa_load, so that all the needed vesa
components are properly initialized.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
PR: 209203
Reviewed by: dumbbell
Differential revision: https://reviews.freebsd.org/D7196
