This commit brings back the driver from FreeBSD commit
f187d6dfbf plus subsequent fixes from
upstream.
Relative to upstream this commit includes a few other small fixes such
as additional INET and INET6 #ifdef's, #include cleanups, and updates
for recent API changes in main.
Reviewed by: pauamma, gbe, kevans, emaste
Obtained from: git@git.zx2c4.com:wireguard-freebsd @ 3cc22b2
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36909
When flushing the UART, we need to drain manually if LSR_TEMT is
*not* asserted, aka. if the transmit FIFO is not empty.
Reported by: void <void@f-m.fm>
Fixes: c4b68e7e53 "ns8250: Check if flush via FCR succeeded"
Differential Revision: https://reviews.freebsd.org/D37185
- We depend on header polution to include sys/malloc.h. Include it
directly.
- Only define FDT-specific fuctions when building a FDT kernel.
Sponsored by: Innovate UK
This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
guest on Hyper-V. With this patch, it should be able to build
the ARM64 image and install it on Hyper-V.
Reviewed by: emaste, andrew, whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36744
psci_attach is way too late to provide the intended semantics for
psci_present. psci calls can be made immediately after psci_init(),
called way earlier at SI_SUB_CPU + SI_ORDER_FIRST, and we need it to
be valid as early as we can possibly call a psci function.
This fixes booting RPi3+4 with the in-review spintable patch;
rpi3-psci-monitor patches the FDT to add a PSCI node, but it doesn't
patch each cpus' enable-method. Because of this, we would stall the
boot while enabling CPU 1 as we saw a valid looking enable-method and
"no" functional PSCI and attempted to use the spintable rather than
simply not starting secondary APs.
Fixes: 2218070b2c ("psci: finish psci_present implementation")
Reported by: karels
Refactor the code to put split the MSR values for x86 and arm64
Hyper-V. Code not yet built. This is one of several patches for
the arm64 Hyper-V enablement.
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37103
2782ed8f6c fixed the standalone module
build. REmove the now duplicate includes for opt_acpi.h and
opt_platform.h. Als remove the if_mdio.h again in both the Makefile
and the implementation file as it is not (currently) used.
X-MFC with: ba7319e909
MFC after: 70 days
New driver to ACPI generic event device, defined in ACPI spec.
Some ACPI power button may not work without this.
In qemu arm64 with "virt" machine, with ACPI firmware,
enable devd check devd message by
and invoke following command in qemu monitor
(qemu) system_powerdown
and make sure some power button input event appear.
(setting sysctl hw.acpi.power_button_state=S5 is not work,
because ACPI tree does not have \_S5 object.)
Reviewed by: andrew, hrs
Differential Revision: https://reviews.freebsd.org/D37032
This is the second part of the ARM64 Hyper-V enablement.
These changes here are mostly with Make, release changes and also
changes required in vmbus.c hyperv.c and common files in hyperv.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36467
In ARM64 gen2 Hyper-V, use IRQ resource from vmbus_res, which is owning
the IRQ for current device tree. It allows the MMIO resource to be
successfully allocated for vmbus from parent acpi_syscontainer.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37064
This add BUS_GET_DEVICE_PATH interface,
which shows device tree of openfirm/fdt.
In qemu-system-arm64 with "virt" machine with device-tree firmware,
% devctl getpath OFW cpu0
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37031
The emulated UART in the Firecracker VMM (aka the implementation in the
rust-vmm/vm-superio project) includes FIFOs but does not implement the
FCR register, which is used by ns8250_flush to flush the FIFOs.
Check the LSR to see if there is still data in the FIFOs and call
ns8250_drain if necessary.
Discussed with: emaste, imp, jrtc27
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36979
We assume that bus addresses from busdma are the same thing as
"physical" addresses in the Virtio specification; this seems to
be true for the platforms on which Virtio is currently supported.
For block devices which are limited to a single data segment per
I/O, we request PAGE_SIZE alignment from busdma; this is necessary
in order to support unaligned I/Os from userland, which may cross
a boundary between two non-physically-contiguous pages. On devices
which support more data segments per I/O, we retain the existing
behaviour of limiting I/Os to (max data segs - 1) * PAGE_SIZE.
Reviewed by: bryanv
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36667
Most virtio_blk requests are launched from vtblk_startio; prior to this
commit, if vtblk_request_execute failed (e.g. due to a lack of space on
the virtio queue) vtblk_startio would requeue the request to be
reattempted later.
Add a flag "vbr_requeue_on_error" to requests and perform the requeuing
from inside vtblk_request_execute instead.
No functional change intended.
Reviewed by: bryanv, imp
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36665
The error, if any, now gets stashed in the request structure. (Step 1
of reworking this driver to use busdma.)
No functional change intended.
Reviewed by: bryanv, imp
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36664
The Virtio MMIO bus driver was added in 2014 with support for devices
exposed via FDT; in 2018 support was added to discover Virtio MMIO
devices via ACPI tables, as in QEMU. The Firecracker VMM eschews both
FDT and ACPI, instead presenting device information via kernel command
line arguments of the form virtio_mmio.device=<parameters>.
These command line parameters get converted into kernel environment
variables; this adds support for parsing those variables and attaching
virtio_mmio children to nexus.
There is a case to be made that it would be cleaner to have a new
"cmdlinebus" attached to nexus and virtio_mmio children attached to
that. A future commit might do that.
Discussed with: imp, jrtc27
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36189
Issue Description:
The RequestCredits field of IOCFacts got changed between the Phase23
firmware to Phase24 firmware. So as part of firmware update operation,
driver has to free the resources & pools which are created with the Phase23
Firmware's IOCFacts data (i.e. during driver load time) and has to
reallocate the resources and pools using Phase24's IOCFacts data. Here
driver has freed the interrupts but missed to reallocate the interrupts and
hence config page read operation is getting timed out and controller is
going for recursive reinit (controller reset) operations and leading to
kernel panic.
Fix:
Reallocate the interrupts if the interrupts are disabled as part of
firmware update/downgrade operation.
Submitted by: Sreekanth Ready <sreekanth.reddy@broadcom.com>
Tested by: ken
MFC after: 3 days
DPAA2 is a hardware-level networking architecture found in some NXP
SoCs which contain hardware blocks including Management Complex
(MC, a command interface to manipulate DPAA2 objects), Wire Rate I/O
processor (WRIOP, packets distribution, queuing, drop decisions),
Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer
pools) and the others.
The Management Complex runs NXP-supplied firmware which provides DPAA2
objects as an abstraction layer over those blocks to simplify an
access to the underlying hardware. Each DPAA2 object has its own
driver (to perform an initialization at least) and will be visible
as a separate device in the device tree.
Two new drivers (dpaa2_mc and dpaa2_rc) act like firmware buses in
order to form a hierarchy of the DPAA2 devices:
acpiX (or simplebusX)
dpaa2_mcX
dpaa2_rcX
dpaa2_mcp0
...
dpaa2_mcpN
dpaa2_bpX
dpaa2_macX
dpaa2_io0
...
dpaa2_ioM
dpaa2_niX
dpaa2_mc is suppossed to be a root of the hierarchy, comes in ACPI
and FDT flavours and implements helper interfaces to allocate and
assign bus resources, MSI and "managed" DPAA2 devices (NXP treats some
of the objects as resources for the other DPAA2 objects to let them
function properly). Almost all of the DPAA2 objects are assigned to
the resource containers (dpaa2_rc) to implement isolation.
The initial implementation focuses on the DPAA2 network interface
to be operational. It is the most complex object in terms of
dependencies which uses I/O objects to transmit/receive packets.
Approved by: bz (mentor)
Tested by: manu, bz
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D36638
It can be static within uart_tty.c. It is an open question whether there
remains any real benefit to having uart instances share a swi thread.
Reviewed by: imp, markj, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36938
When a transaction is on the outstanding list, it needs to have a valid
timeout value, so set it to infinity before placing it on the
list. Place before we put it on the list, even though the list is
protected by the qpair lock.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D36920
