conf: Generate fdt_static_dtb.h in OBJDIR

Though the kernel build expects ${.OBJDIR} to be equal to ${.CURDIR}
that may not always be the case. Correctly generate fdt_static_dtb.h in
${.OBJDIR}, wh

conf: Generate fdt_static_dtb.h in OBJDIR

Though the kernel build expects ${.OBJDIR} to be equal to ${.CURDIR}
that may not always be the case. Correctly generate fdt_static_dtb.h in
${.OBJDIR}, which is conceptually more correct anyway.

Obtained from: Juniper Networks, Inc.

show more ...

snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver.

Add a sound(4) bridge device driver for the RME HDSP 9632 and HDSP 9652
sound cards. These cards require a nowadays rare PCI 32bit (not PC

snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver.

Add a sound(4) bridge device driver for the RME HDSP 9632 and HDSP 9652
sound cards. These cards require a nowadays rare PCI 32bit (not PCIe)
slot, but still see use due to their value and wealth of features.
The HDSP 9632 is mostly comparable to the newer HDSPe AIO, while the
HDSP 9652 is similar to the HDSPe RayDAT. These HDSPe PCIe cards are
supported by the snd_hdspe(4) driver which was taken as a starting point
for development of snd_hdsp(4).

Implementation is kept separately due to substantial differences in
hardware configuration and to allow easy removal in case PCI 32bit
support would be phased out in the future.

The snd_hdsp(4) kernel module is not enabled by default, and can be
loaded at runtime with kldload(8) or during boot via loader.conf(5).
Basic operation was tested with both cards, not including all optional
cable connectors and expansion boards. Features should be roughly on par
with the snd_hdspe(4) supported cards.

Reviewed by: christos, br
Differential Revision: https://reviews.freebsd.org/D45112

show more ...

Remove lingering geom_bde references.

tpm: Refactor TIS and add a SPI attachment

Summary:
Though mostly used in x86 devices, TPM can be used on others, with a
direct SPI attachment. Refactor the TPM 2.0 driver set to use an
attachment

tpm: Refactor TIS and add a SPI attachment

Summary:
Though mostly used in x86 devices, TPM can be used on others, with a
direct SPI attachment. Refactor the TPM 2.0 driver set to use an
attachment interface, and implement a SPI bus interface.

Test Plan:
Tested on a Raspberry Pi 4, with a GeeekPi TPM2.0 module (SLB9670
TPM) using security/tpm2-tools tpm2_getcaps for very light testing against the
spibus attachment.

Reviewed by: kd
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D45069

show more ...

nvmft: The in-kernel NVMe over Fabrics controller

This is the server (target in SCSI terms) for NVMe over Fabrics.
Userland is responsible for accepting a new queue pair and receiving
the initial Co

nvmft: The in-kernel NVMe over Fabrics controller

This is the server (target in SCSI terms) for NVMe over Fabrics.
Userland is responsible for accepting a new queue pair and receiving
the initial Connect command before handing the queue pair off via an
ioctl to this CTL frontend.

This frontend exposes CTL LUNs as NVMe namespaces to remote hosts.
Users can ask LUNS to CTL that can be shared via either iSCSI or
NVMeoF.

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44726

show more ...

ctl: Support for NVMe commands

- Add support for queueing and executing NVMe admin and NVM commands
via ctl_run and ctl_queue. This requires fixing a few places that
were SCSI-specific to add N

ctl: Support for NVMe commands

- Add support for queueing and executing NVMe admin and NVM commands
via ctl_run and ctl_queue. This requires fixing a few places that
were SCSI-specific to add NVME logic.

- NVMe has much simpler command ordering requirements than SCSI. In
particular, the HBA is not required to enforce any specific ordering
for requests with overlapping LBAs. The host is required to manage
that ordering. However, fused commands (currently only COMPARE and
WRITE NVM commands can be fused) are required to be executed
atomically.

To support fused commands, make the second half of a fused command
block on the first half, and have commands submitted after a fused
command pair block on the second half.

- Add handlers and command tables for admin and NVM commands that
operate on individual namespaces and will be passed down from an
NVMe over Fabrics controller to a CTL LUN.

Reviewed by: ken, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44720

show more ...

ctl: Support NVMe requests in debug trace functions

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44719

nvmf: The in-kernel NVMe over Fabrics host

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

nvmf: The in-kernel NVMe over Fabrics host

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

show more ...

nvmf_tcp: Add a TCP transport for NVMe over Fabrics

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 i

nvmf_tcp: Add a TCP transport for NVMe over Fabrics

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

show more ...

glabel: Add support for Linux swap

Reviewed by: imp, kib
Pull Request: https://github.com/freebsd/freebsd-src/pull/1205

sound: Retire unit.*

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

sound: Retire unit.*

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

show more ...

accf_tls: accept filter that waits for TLS handshake header

glabel: Remove support for old reiserfs

Reviewed by: imp, emaste
Pull Request: https://github.com/freebsd/freebsd-src/pull/1101

Add support for i2c-tiny-usb: usb to iic bridge

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1123

files: Sort the VirtIO device entries

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

efidev: Allow for optionally including efidev and efirtc into the kernel

Require both "efirt" and "efidev" in order to build in efidev
Require both "efirt" and "efirtc" in order to build in efirtc

efidev: Allow for optionally including efidev and efirtc into the kernel

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

show more ...

sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)

Currently the snd_clone framework creates device nodes on-demand for
every channel, through the dsp_clone() callback, and is responsible for
rou

sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)

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

show more ...

vtscmi: Add a virtio-scmi driver

Add a new virtio backend to support SCMI VirtIO devices (type 32) as
defined by the VirtIO specification since version v1.2.

https://docs.oasis-open.org/virtio/virt

vtscmi: Add a virtio-scmi driver

Add a new virtio backend to support SCMI VirtIO devices (type 32) as
defined by the VirtIO specification since version v1.2.

https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.pdf

Reviewed by: andrew, bryanv
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43047

show more ...

iser: Add kernel build glue

'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://

iser: Add kernel build glue

'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

show more ...

Revert "sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)"

This reverts commit dc831e93bad63f9faea09f1806a7733a40bff316.

After several reports in the mailing lists, this commit breaks
pulseaudi

Revert "sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)"

This reverts commit dc831e93bad63f9faea09f1806a7733a40bff316.

After several reports in the mailing lists, this commit breaks
pulseaudio. Revert until the issue is resolved.

show more ...

sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)

Currently the snd_clone framework creates device nodes on-demand for
every channel, through the dsp_clone() callback, and is responsible for
rou

sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)

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

show more ...

build: Do not pass -fno-sanitize-memory-param-retval to subr_coverage.c

In the absence of -fsanitize=kernel-memory, the presence of this flag
results in a -Wunused-command-line-argument warning.

MF

build: Do not pass -fno-sanitize-memory-param-retval to subr_coverage.c

In the absence of -fsanitize=kernel-memory, the presence of this flag
results in a -Wunused-command-line-argument warning.

MFC after: 1 week

show more ...

ddb: Add CTF-based pretty printing

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 wit

ddb: Add CTF-based pretty printing

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)

show more ...

Update to bring the rack stack with all its fixes in.

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 w

Update to bring the rack stack with all its fixes in.

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

show more ...

conf: deduplicate dwmmc config logic

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/emergi

conf: deduplicate dwmmc config logic

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

show more ...