This is the client (initiator in SCSI terms) for NVMe over Fabrics.
Userland is responsible for creating a set of queue pairs and then
handing them off via an ioctl to this driver, e.g. via the 'connect'
command from nvmecontrol(8). An nvmeX new-bus device is created
at the top-level to represent the remote controller similar to PCI
nvmeX devices for PCI-express controllers.
As with nvme(4), namespace devices named /dev/nvmeXnsY are created and
pass through commands can be submitted to either the namespace devices
or the controller device. For example, 'nvmecontrol identify nvmeX'
works for a remote Fabrics controller the same as for a PCI-express
controller.
nvmf exports remote namespaces via nda(4) devices using the new NVMF
CAM transport. nvmf does not support nvd(4), only nda(4).
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44714
Structurally this is very similar to the TCP transport for iSCSI
(icl_soft.c). One key difference is that NVMeoF transports use a more
abstract interface working with NVMe commands rather than transport
PDUs. Thus, the data transfer for a given command is managed entirely
in the transport backend.
Similar to icl_soft.c, separate kthreads are used to handle transmit
and receive for each queue pair. On the transmit side, when a capsule
is transmitted by an upper layer, it is placed on a queue for
processing by the transmit thread. The transmit thread converts
command response capsules into suitable TCP PDUs where each PDU is
described by an mbuf chain that is then queued to the backing socket's
send buffer. Command capsules can embed data along with the NVMe
command.
On the receive side, a socket upcall notifies the receive kthread when
more data arrives. Once enough data has arrived for a PDU, the PDU is
handled synchronously in the kthread. PDUs such as R2T or data
related PDUs are handled internally, with callbacks invoked if a data
transfer encounters an error, or once the data transfer has completed.
Received capsule PDUs invoke the upper layer's capsule_received
callback.
struct nvmf_tcp_command_buffer manages a TCP command buffer for data
transfers that do not use in-capsule-data as described in the NVMeoF
spec. Data related PDUs such as R2T, C2H, and H2C are associated with
a command buffer except in the case of the send_controller_data
transport method which simply constructs one or more C2H PDUs from the
caller's mbuf chain.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44712
Convert existing FreeBSD vmware_hvcall function to take a channel
and parameter arguments.
Added vmware_guestrpc_cmd() to send GuestRPC commands to the VMware
hypervisor. The sbuf argument is used for both the command to send
and to store the data to return to the caller.
The following KPIs can be used to get and set FreeBSD-specific guest
information in key/value pairs:
* vmware_guestrpc_set_guestinfo
- set a value into the guestinfo.fbsd.<keyword> key
* vmware_guestrpc_get_guestinfo
- get the value stored in the guestinfo.fbsd.<keyword> key
Add VMware devices to x86 NOTES
Reviewed by: jhb
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D44528
scmi_virtio.c depends on virtio. Check for this before including it in
the kernel.
Reported by: Isaac Cilia Attard (via cperciva)
Sponsored by: Arm Ltd
The unit.* code is largely obsolete and imposes limits that are no
longer needed nowadays.
- Capping the maximum allowed soundcards in a given machine. By default,
the limit is 512 (snd_max_u() in unit.c), and the maximum possible is
2048 (SND_UNIT_UMAX in unit.h). It can also be tuned through the
hw.snd.maxunit loader(8) tunable. Even though these limits are large
enough that they should never cause problems, there is no need for
this limit to exist in the first place.
- Capping the available device/channel types. By default, this is 32
(snd_max_d() in unit.c). However, these types are pre-defined in
pcm/sound.h (see SND_DEV_*), so the cap is unnecessary when we know
that their number is constant.
- Capping the number of channels per-device. By default, the limit 1024
(snd_max_c() in unit.c). This is probably the most problematic of the
limits mentioned, because this limit can never be reached, as the
maximum is hard-capped at either hw.snd.maxautovchans (16 by default),
or SND_MAXHWCHAN and SND_MAXVCHANS.
These limtits are encoded in masks (see SND_U_MASK, SND_D_MASK,
SND_C_MASK in unit.h) and are used to construct a bitfield of the form
[dsp_unit, type, channel_unit] in snd_mkunit() which is assigned to
pcm_channel->unit.
This patch gets rid of everything unit.*-related and makes a slightly
different use of the "unit" field to only contain the channel unit
number. The channel type is stored in a new pcm_channel->type field, and
the DSP unit number need not be stored at all, since we can fetch it
from device_get_unit(pcm_channel->dev). This change has the effect that
we no longer need to impose caps on the number of soundcards,
device/channel types and per-device channels. As a result the code is
noticeably simplified and more readable.
Apart from the fact that the hw.snd.maxunit loader(8) tunable is also
retired as a side-effect of this patch, sound(4)'s behavior remains the
same.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D44912
This commit broke "make makeman" checks in github CI due to a lack of
option description files. The split between VIMAGE and VIMAGE_SUPPORT
is not clearly justified and the code is broken because there is no
opt_vimage.h (it's in opt_global.h).
This reverts commit 22ca6db50f.
The new sys/conf/std.debug contains the list of debugging options
enabled by default in -CURRENT, so they don't need to be listed
individually in every kernel config.
The enabled options are the set of all debug options which were enabled
for the GENERIC kernel on any platform. This means some architectures
now have debugging options enabled in GENERIC which weren't previously
enabled:
- amd64: [1]
- arm64: [2]
- arm: [2]. [3]
- i386: [1], [2]
- powerpc: [1], [2], [3]
- riscv: [2]
[1] ALT_BREAK_TO_DEBUGGER is now enabled.
[2] BUF_TRACKING, FULL_BUF_TRACKING, and QUEUE_MACRO_DEBUG_TRASH are now
enabled.
[3] DEADLKRES is now enabled.
While here, move the documentation for the (commented out) K*SAN options
for amd64 from GENERIC to NOTES.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1124
This avoids requiring both 'device hyperv' and 'options HYPERV' for
kernel configs. Instead, just 'device hyperv' can now be used
matching the kernel configuration used for amd64.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44783
Require both "efirt" and "efidev" in order to build in efidev
Require both "efirt" and "efirtc" in order to build in efirtc
Update FIRECRACKER, GENERIC, and NOTES for amd64
Update NOTES and std.arm for arm64
Reviewed by: imp
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D44745
Currently the snd_clone framework creates device nodes on-demand for
every channel, through the dsp_clone() callback, and is responsible for
routing audio to the appropriate channel(s). This patch gets rid of the
whole snd_clone framework (including any related sysctls) and instead
uses DEVFS_CDEVPRIV(9) to handle device opening, channel allocation and
audio routing. This results in a significant reduction in code size as
well as complexity.
Behavior that is preserved:
- hw.snd.basename_clone.
- Exclusive access of an audio device (i.e VCHANs disabled).
- Multiple processes can read from/write to the device.
- A device can only be opened as many times as the maximum allowed
channel number (see SND_MAXHWCHAN in pcm/sound.h).
- OSSv4 compatibility aliases are preserved.
Behavior changes:
Only one /dev/dspX device node is created (on attach) for each audio
device, as opposed to the current /dev/dspX.Y devices created by
snd_clone. According to the sound(4) man page, devices are not meant to
be opened through /dev/dspX.Y anyway, so it is best if we do not create
device nodes for them in the first place. As a result of this, modify
dsp_oss_audioinfo() to print /dev/dspX in the "ai->devnode", instead of
/dev/dspX.Y.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
Reviewed by: dev_submerge.ch, bapt, markj
Differential Revision: https://reviews.freebsd.org/D44411
To silence a linker warning about _start being missing. This blob
contains code executed at EL2 and is only meant to be entered via
exception handlers.
Reviewed by: bz, emaste
Fixes: 47e073941f ("Import the kernel parts of bhyve/arm64")
Differential Revision: https://reviews.freebsd.org/D44735
Add an SCMI transport driver based on the virtio-scmi backend.
Reviewed by: andrew, bryanv
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43048
Using the SCMI transport interface add a new SMC transport to the
SCMI stack.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43040
Add a new SCMI interface file to allow for multiple kind of transports
and move the mailbox transport to its own file, using the new interface.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43039
While here, adjust the sample setting for NVME_USE_NVD to use a
non-default setting as is typical in entries in NOTES.
Discussed with: imp
Reviewed by: manu
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44691
- Add typical comments after device entries (copied from amd64
GENERIC)
- Add an entry for 'device ada'. Normally this is pulled in via
'device sd', but is documented in ada(4) and can be used to include
ATA/SATA disk support in a kernel without SCSI disk support.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44689
'device iser' is documented in iser(4) but not supported. Hook it up
to the build.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44687
Default to VIMAGE as yes.
Add VIMAGE to __DEFAULT_DEPENDENT_OPTIONS (to define VIMAGE_SUPPORT)
Only output VIMAGE to opt_global.h when VIMAGE support is wanted.
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D39636
When debugging network issues one common clue is an unexpectedly
incrementing error counter. This is helpful, in that it gives us an
idea of what might be going wrong, but often these counters may be
incremented in different functions.
Add a static probe point for them so that we can use dtrace to get
futher information (e.g. a stack trace).
For example:
dtrace -n 'mib:ip:count: { printf("%d", arg0); stack(); }'
This can be disabled by setting the following kernel option:
options KDTRACE_NO_MIB_SDT
Reviewed by: gallatin, tuexen (previous version), gnn (previous version)
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43504
Instead of compiling the whole sys/arm64/arm64/vfp.c file without
-mgeneral-regs-only, which might have unwanted side effects, add
".arch_extension fp" / ".arch_extension nofp" pairs to the inline
assembly.
PR: 276104
Suggested by: andrew
MFC after: 1 month
Apparently clang 18 has become more strict about using floating point
registers in inline assembly when -mgeneral-regs-only is used. This
causes sys/arm64/arm64/vfp.c to fail to compile, with "error:
instruction requires: fp-armv8", and "error: expected readable system
register".
To fix it, similar to other files compiled for arm64, disable
-mgeneral-regs-only for this particular file.
PR: 276104
MFC after: 1 month
Currently the snd_clone framework creates device nodes on-demand for
every channel, through the dsp_clone() callback, and is responsible for
routing audio to the appropriate channel(s). This patch gets rid of the
whole snd_clone framework (including any related sysctls) and instead
uses DEVFS_CDEVPRIV(9) to handle device opening, channel allocation and
audio routing. This results in a significant reduction in code size as
well as complexity.
Behavior that is preserved:
- hw.snd.basename_clone.
- Exclusive access of an audio device (i.e VCHANs disabled).
- Multiple processes can read from/write to the device.
- A device can only be opened as many times as the maximum allowed
channel number (see SND_MAXHWCHAN in pcm/sound.h).
- OSSv4 compatibility aliases are preserved.
Behavior changes:
Only one /dev/dspX device node is created (on attach) for each audio
device, as opposed to the current /dev/dspX.Y devices created by
snd_clone. According to the sound(4) man page, devices are not meant to
be opened through /dev/dspX.Y anyway, so it is best if we do not create
device nodes for them in the first place. As a result of this, modify
dsp_oss_audioinfo() to print /dev/dspX in the "ai->devnode", instead of
/dev/dspX.Y.
Sponsored by: The FreeBSD Foundation
MFC after: 2 months
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D44411
Move the code from the arm specific to the iicbus controller directory.
Split up between general logic and bus attachment code.
Add support for ACPI attachment in addition to FDT.
MFC after: 7 days
Tested by: bz (LS1088a FDT), Pierre-Luc Drouin (Honeycomb, ACPI)
Based on: D24917 by Val Packett (initial early version)
Differential Revision: https://reviews.freebsd.org/D44020
gcc12 and gcc13 appear to include Wswitch with Wall, while
clang doesn't. For switch() statements on enum, this forces
the use of at least a default: clause, in adherance with style(9).
Reviewed By: emaste
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D44092
Add basic CTF support and a CTF-powered pretty-printer to ddb.
The db_ctf.* files expose a basic interface for fetching type
data for ELF symbols, interacting with the CTF string table,
and translating type identifiers to type data.
The db_pprint.c file uses those interfaces to implement
a pretty-printer for all kernel ELF symbols.
The pretty-printer works with symbol names and arbitrary addresses:
pprint struct thread 0xffffffff8194ad90
Pretty-printing currently only works after the root filesystem
gets mounted because the CTF info is not available during
early boot.
Differential Revision: https://reviews.freebsd.org/D37899
Approved by: markj (mentor)
This brings the rack stack up to the current level used at NF. Many fixes
and improvements have been added. I also add in a fix to BBR to deal with
the changes that have been in hpts for a while i.e. only one call no matter
if mbuf queue or tcp_output.
It basically does little except BBlogs and is a placemark for future work on
doing path capacity measurements.
With a bit of a struggle with git I finally got rack_pcm.c into place (apologies
for not noticing this error). The LINT kernel is running on my box now .. sigh.
Reviewed by: tuexen, glebius
Sponsored by: Netflix Inc.
Differential Revision:https://reviews.freebsd.org/D43986
Bring the keeping of .gnu.attributes to all architectures. Also discard
.note.GNU-stack on all archtiectures. Plus delete obsolete comment that
was removed from i386 in 2010.
Sponsored by: Netflix
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44069
The core of this driver is supported by multiple architectures. Move the
config entries to the MI conf/files.
This hardware is found on several available/emerging RISC-V SoCs, so we
will soon need it on this architecture.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44104
Move the core dwc(4) file entries to the MI conf/files.
Platform-specific versions e.g. rk_dwc are retained in their current
position. On arm64 this necessitates adding an additional 'device dwc'
option.
This hardware is found on several available/emerging RISC-V SoCs, so we
will soon need it on this architecture.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44103
Enabling 11n for ath(4) so far was handled by a kernel option, which
was only enabled for certain kernel configurations.
In order to allow loading ath(4) as a module with 11n support on
all platforms, remove the kernel option and unconditionally enable
11n in ath(4).
Reported by: pkubaj
Discussed with: adrian in D43549.
Reviewed by: adrian, imp
Differential Revision: https://reviews.freebsd.org/D43964
To support virtual machines on arm64 add the vmm code. This is based on
earlier work by Mihai Carabas and Alexandru Elisei at University
Politehnica of Bucharest, with further work by myself and Mark Johnston.
All AArch64 CPUs should work, however only the GICv3 interrupt
controller is supported. There is initial support to allow the GICv2
to be supported in the future. Only pure Armv8.0 virtualisation is
supported, the Virtualization Host Extensions are not currently used.
With a separate userspace patch and U-Boot port FreeBSD guests are able
to boot to multiuser mode, and the hypervisor can be tested with the
kvm unit tests. Linux partially boots, but hangs before entering
userspace. Other operating systems are untested.
Sponsored by: Arm Ltd
Sponsored by: Innovate UK
Sponsored by: The FreeBSD Foundation
Sponsored by: University Politehnica of Bucharest
Differential Revision: https://reviews.freebsd.org/D37428
This is intended to be used with the upcoming ice 1.39.13-k
driver update, but is still backwards compatible with
previous versions of the driver.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
MFC after: 3 days
Sponsored by: Intel Corporation
This patch introduces support for the RISC-V APLIC interrupt controller
[1]. Currently, it is only supports direct mode, i.e. without an IMSIC
and functionally replacing the legacy RISC-V PLIC. Work on IMSIC support
is in progress.
[1] https://github.com/riscv/riscv-aia/releases/tag/1.0
Reviewed by: mhorne
Discussed with: jrtc27
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D43293
gcc 12 defaults to emitting DWARF 5, but this is not yet supported by
our libdwarf and thus by ctfconvert.
Reviewed by: emaste, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43837
If one wants to have puc working as a module we need the bus
in the kernel otherwise we won't be able to find any child to attach.
Reviewed by: imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43846
The presence of -fno-sanitize-memory-param-retval without an
accompanying -fsanitize=kernel-memory triggers a compiler error.
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
As a separate commit, now move locore-v6.S to locore.S. This makes git
annotate work, at least back to 2014 when Ian created locore-v6.S. svn
didn't save enough metadata for the converter to allow it to go back
further.
Sponsored by: Netflix
Use locore-v6.S directly, rather than indirectly via including
locore.S. This loses acle-compat.h inclusion, but that's only needed for
gcc 4.8 and earlier. Since we don't support anything that old, there's
no need for it here.
Sponsored by: Netflix
Currently there are a few output sections left as implicitly using
:kernel :dynamic before :kernel on its own is used again, which means
they end up in both the PT_LOAD and the PT_DYNAMIC segments, an unusual
situation which the new libelf-based kldxref initially treated as
invalid. Thus, hoist the :kernel to the very next section to ensure only
.dynamic is in PT_DYNAMIC, as is more normal.
Whilst here, sync ldscript.powerpc64le with ldscript.powerpc64 to pick
up various fixes that were presumably made between the start of the
powerpc64le port and it being committed and got missed.
Reviewed by: jhibbits, jhb
Differential Revision: https://reviews.freebsd.org/D43066
Currently the local interrupt controller implementation is based on
pre-INTRNG arm/arm64 code, using hand-rolled event code rather than
INTRNG. This then interacts weirdly with the PLIC, and other future
interrupt controllers like the APLIC and IMSICs in the upcoming AIA
specification, since they become the root PIC despite not being the
logical root. Instead, use a real newbus device for it and register
it as the root PIC.
This also adapts the IPI code to make use of the newly-added INTRNG
generic IPI handling framework, adding a new sbi_ipi as the PIC. In
future there will be alternative devices for sending IPIs that will
register with higher priorities, such as the proposed AIA IMSIC and
ACLINT SSWI.
Reviewed by: mhorne
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D35901
This patch provides UDP encapsulation of ESP packets over IPv6.
Ports the IPv4 code to IPv6 and adds support for IPv6 in udpencap.c
As required by the RFC and unlike in IPv4 encapsulation,
UDP checksums are calculated.
Co-authored-by: Aurelien Cazuc <aurelien.cazuc.external@stormshield.eu>
Sponsored-by: Stormshield
Sponsored-by: Wiktel
Sponsored-by: Klara, Inc.
pflow is a pseudo device to export flow accounting data over UDP.
It's compatible with netflow version 5 and IPFIX (10).
The data is extracted from the pf state table. States are exported once
they are removed.
Reviewed by: melifaro
Obtained from: OpenBSD
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43106
Some, particularly KASAN, may insert redzones around global symbols,
resulting in incorrect offset definitions because genassym.sh (ab)uses
symbol sizes to assign semantic meaning.
(Ideally I would be able to define this pattern in one place, but I
haven't found a way to define a GENSYM_CFLAGS that actually works for
all of the consumers (kern.post.mk, kmod.mk, sys/conf/files*).)
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
The option was introduced in LLVM 16.
Fixes: b6c653c974 ("kmsan: Set -fno-sanitize-memory-param-retval for now")
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43196
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43195
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43194
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: dab, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43193
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43192
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43191
dwc3 is big enough to have its own subdirectory.
While here only make it depend on kernel option dwc3 and rk_dwc3
without any SOC options.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43190
No need to keep it under sys/arm64/rockchip/clk
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43189
No need to keep it under sys/arm/allwinner/clkng
It's easier to find which controller we support by looking under one directory.
It will also be shared with Allwinner RiscV SoC.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43188
No need to keep it under sys/arm/allwinner
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43187
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43186
No need to keep it under sys/arm/allwinner
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43185
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
While here remove the condition on SOC option, device rk_i2c is enough as all
Rockchip SoC that we support have this controller.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43184
Version : 1.27.5.0
Date : 10/10/2023
=====================
Fixes
-----
BASE:
- Fixed handling the Remote Fault with AN, causing the link failure.
=====================
Obtained from: Chelsio Communications
MFC after: 2 weeks
Sponsored by: Chelsio Communications
For the same reason as the original https://reviews.freebsd.org/D9659:
-flto=<N>, -flto=full, and -flto=thin also produce the GIMPLE/bitcode
which is not supported by genassym, so filter those out as well.
Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/898
Surprisingly, kldxref does not currently support arm, and unhelpfully
this means it silently does nothing rather than give an error, so the
linker.hints entry added to the METALOG for -DNO_ROOT builds (and
pkgbase ones) refers to a file that doesn't exist. Ideally it would be
supported (and ideally the METALOG handling would be less fragile, but
without integrating it into kldxref the only real option would be to
just run find(1) to get the list of linker.hints files, which feels a
little backwards), but for now just paper over this by skipping the
build step on arm.
Reported by: bapt
Fixes: ff7c12c1f1 ("Make kldxref a bootstrap tool and use unconditionally")
Now that kldxref is a generic cross tool and can be built on non-FreeBSD
we can bootstrap it during the build and thus remove the condition for
whether it exists. We also need to make sure to add it to the METALOG
for -DNO_ROOT builds.
Reviewed by: brooks, imp
Differential Revision: https://reviews.freebsd.org/D43051
[Why]
`linux_compat.c` is already too long. I will need to add `struct kset`
in a follow-up commit, so let's move the existing `struct kobject` code
to its own file.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D43019
Compiling the BBR or RACK stack into the kernel requires HPTS to be
compiled into the kernel.
Reviewed by: glebius, rscheff
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D42998
Put same copyright header as tcp_hpts.c has, since all this code
was developed by Randall Stewart <rrs@FreeBSD.org> as a part of
the HPTS work. Also copy Mellanox copyright from tcp_lro.c as
Hans Petter Selasky also participated in restructuring the code.
Reviewed by: imp, tuexen, rrs
Differential Revision: https://reviews.freebsd.org/D42854
OpenSSL itself keeps only a single copy of this header. Do the same in
sys/crypto/openssl to avoid the extra maintenance burden. This requires
adjusting the include paths for generated asm files.
No functional change intended.
Reported by: jrtc27
Reviewed by: jhb
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D42866
OpenSSL provides implementations of several AES modes which use
bitslicing and can be accelerated on CPUs which support the NEON
extension. This patch adds arm platform support to ossl(4) and provides
an AES-CBC implementation, though bsaes_cbc_encrypt() only implements
decryption. The real goal is to provide an accelerated AES-GCM
implementation; this will be added in a subsequent patch.
Initially derived from https://reviews.freebsd.org/D37420.
Reviewed by: jhb
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D41304
